Posts in category: Microsoft AI

Transcript

GRETCHEN HUIZINGA: Welcome to Abstracts, a Microsoft Research Podcast that puts the spotlight on world-class research in brief. I’m Dr. Gretchen Huizinga. In this series, members of the research community at Microsoft give us a quick snapshot—or a podcast abstract—of their new and noteworthy papers.  

Today, I’m talking to Dr. Lev Tankelevitch, a senior behavioral science researcher from Microsoft Research. Dr. Tankelevitch is coauthor of a paper called “The Metacognitive Demands and Opportunities of Generative AI,” and you can read this paper now on arXiv. Lev, thanks for joining us on Abstracts! 

LEV TANKELEVITCH: Thanks for having me. 

HUIZINGA: So in just a couple sentences—a metacognitive elevator pitch, if you will—tell us about the issue or problem your paper addresses and, more importantly, why we should care about it. 

TANKELEVITCH: Sure. So as generative AI has, sort of, rolled out over the last year or two, we’ve seen some user studies come out, and as we read these studies, we noticed there are a lot of challenges that people face with these tools. So people really struggle with, you know, writing prompts for systems like Copilot or ChatGPT. For example, they don’t even know really where to start, or they don’t know how to convert an idea they have in their head into, like, clear instructions for these systems. If they’re, sort of, working in a field that maybe they’re less familiar with, like a new programming language, and they get an output from these systems, they’re not really sure if it’s right or not. And then, sort of, more broadly, they don’t really know how to fit these systems into their workflows. And so we’ve noticed all these challenges, sort of, arise, and some of them relate to, sort of, the unique features of generative AI, and some relate to the design of these systems. But basically, we started to, sort of, look at these challenges, and try to understand what’s going on—how can we make sense of them in a more coherent way and actually build systems that really augment people and their capabilities rather than, sort of, posing these challenges? 

HUIZINGA: Right. So let’s talk a little bit about the related research that you’re building on here and what unique insights or directions your paper adds to the literature. 

TANKELEVITCH: So as I mentioned, we were reading all these different user studies that were, sort of, testing different prototypes or existing systems like ChatGPT or GitHub Copilot, and we noticed different patterns emerging, and we noticed that the same kinds of challenges were cropping up. But there weren’t any, sort of, clear coherent explanations that tied all these things together. And in general, I’d say that human-computer interaction research, which is where a lot of these papers are coming out from, it’s really about building prototypes, testing them quickly, exploring things in an open-ended way. And so we thought that there was an opportunity to step back and to try to see how we can understand these patterns from a more theory-driven perspective. And so, with that in mind, one perspective that became clearly relevant to this problem is that of metacognition, which is this idea of “thinking about thinking” or how we, sort of, monitor our cognition or our thinking and then control our cognition and thinking. And so we thought there was really an opportunity here to take this set of theories and research findings from psychology and cognitive science on metacognition and see how they can apply to understanding these usability challenges of generative AI systems. 

HUIZINGA: Yeah. Well, this paper isn’t a traditional report on empirical research as many of the papers on this podcast are. So how would you characterize the approach you chose and why?

TANKELEVITCH: So the way that we got into this, working on this project, it was, it was quite organic. So we were looking at these user studies, and we noticed these challenges emerging, and we really tried to figure out how we can make sense of them. And so it occurred to us that metacognition is really quite relevant. And so what we did was we then dove into the metacognition research from psychology and cognitive science to really understand what are the latest theories, what are the latest research findings, how could we understand what’s known about that from that perspective, from that, sort of, fundamental research, and then go back to the user studies that we saw in human-computer interaction and see how those ideas can apply there. And so we did this, sort of, in an iterative way until we realized that we really have something to work with here. We can really apply a somewhat coherent framework onto these, sort of, disparate set of findings not only to understand these usability challenges but then also to actually propose directions for new design and research explorations to build better systems that support people’s metacognition. 

HUIZINGA: So, Lev, given the purpose of your paper, what are the major takeaways for your readers, and how did you present them in the paper? 

TANKELEVITCH: So I think the key, sort of, fundamental point is that the perspective of metacognition is really valuable for understanding the usability challenges of generative AI and potentially designing new systems that support metacognition. And so one analogy that we thought was really useful here is of a manager delegating tasks to a team. And so a manager has to determine, you know, what is their goal in their work? What are the different subgoals that that goal breaks down into? How can you communicate those goals clearly to a team, right? Then how do you assess your team’s outputs? And then how do you actually adjust your strategy accordingly as the team works in an iterative fashion? And then at a higher level, you have to really know how to—actually what to delegate to your team and how you might want to delegate that. And so we realized that working with generative AI really parallels these different aspects of what a manager does, right. So when people have to write a prompt initially, they really have to have self-awareness of their task goals. What are you actually trying to achieve? How does that translate into different subtasks? And how do you verbalize that to a system in a way that system understands? You might then get an output and you need to iterate on that output. So then you need to really think about, what is your level of confidence in your prompting ability? So is your prompting the main reason why the output isn’t maybe as satisfactory as you want, or is it something to do with the system? Then you actually might get the output [you’re] happy with, but you’re not really sure if you should fully rely on it because maybe it’s an area that is outside of your domain of expertise. And so then you need to maintain an appropriate level of confidence, right? Either to verify that output further or decide not to rely on it, for example. And then at a, sort of, broader level, this is about the question of task delegation. So this requires having self-awareness of the applicability of generative AI to your workflows and maintaining an appropriate level of confidence in completing tasks manually or relying on generative AI. For example, whether it’s worth it for you to actually learn how to work with generative AI more effectively. And then finally, it requires, sort of, metacognitive flexibility to adapt your workflows as you work with these tools. So are there some tasks where the way that you’re working with them is, sort of, slowing you down in specific ways? So being able to recognize that and then change your strategies as necessary really requires metacognitive flexibility. So that was, sort of, one key half of our findings.  

And then beyond that we really thought about how we can use this perspective of metacognition to design better systems. And so one, sort of, general direction is really about supporting people’s metacognition. So we know from research from cognitive science and psychology that we can actually design interventions to improve people’s metacognition in a lasting and effective way. And so similarly, we can design systems that support people’s metacognition. For example, systems that support people in planning their tasks as they actually craft prompts. We can support people in actually reflecting on their confidence in their prompting ability or in assessing the output that they see. And so this relates a little bit to AI acting as a coach for you, which is an idea that the Microsoft Research New York City team came up with. So this is Jake Hofman, David Rothschild, and Dan Goldstein. And so, in this way, generative AI systems can really help you reflect as a coach and understand whether you have the right level of confidence in assessing output or crafting prompts and so on. And then similarly, at a higher level, they can help you manage your workflows, so helping you reflect on whether generative AI is really working for you in certain tasks or whether you can adapt your strategy in certain ways. And likewise, this relates also to explanations about AI, so how you can actually design systems that are explainable to users in a way that helps them achieve their goals? And explainability can be thought about as a way to actually reduce the metacognitive demand because you’re, sort of, explaining things in a way to people that they don’t have to keep in their mind and have to think about, and that, sort of, improves their confidence. It can help them improve their confidence or calibrate their confidence in their ability to assess outputs. 

HUIZINGA: Talk for a minute about real-world impact of this research. And by that, I mean, who does it help most and how? Who’s your main audience for this right now?

TANKELEVITCH: In a sense, this is very broadly applicable. It’s really about designing systems that people can interact with in any domain and in any context. But I think, given how generative AI has rolled out in the world today, I mean, a lot of the focus has been on productivity and workflows. And so this is a really well-defined, clear area where there is an opportunity to actually help people achieve more and stay in control and actually be more intentional and be more aligned with their goals. And so this is, this is an approach where not only can we go beyond, sort of, automating specific tasks but actually use these systems to help people clarify their goals and track with them in a more effective way. And so knowledge workers are an obvious, sort of, use case or an obvious area where this is really relevant because they work in a complex system where a lot of the work is, sort of, diffused and spread across collaborations and artifacts and softwares and different ways of working. And so a lot of things are, sort of, lost or made difficult by that complexity. And so systems, um, that are flexible and help people actually reflect on what they want to achieve can really have a big impact here. 

HUIZINGA: Mm-hmm. Are you a little bit upstream of that even now in the sense that this is a “research direction” kind of paper. I noticed that as I read it, I felt like this was how researchers can begin to think about what they’re doing and how that will help downstream from that. 

TANKELEVITCH: Yes. That’s exactly right. So this is really about, we hope, unlocking a new direction of research and design where we take this perspective of metacognition—of how we can help people think more clearly and, sort of, monitor and control their own cognition—and design systems to help them do that. And in the paper, there’s a whole list of different questions, both fundamental research questions to understand in more depth how metacognition plays a role in human-AI interaction when people work with generative AI systems but also how we can then actually design new interventions or new systems that actually support people’s metacognition. And so there’s a lot of work to do in this, and we hope that, sort of, inspires a lot of further research, and we’re certainly planning to do a lot more follow-up research. 

HUIZINGA: Yeah. So I always ask, if there was just one thing that you wanted our listeners to take away from this work, a sort of golden nugget, what would it be? 

TANKELEVITCH: I mean, I’d say that if we really want generative AI to be about augmenting human agency, then I think we need to focus on understanding how people think and behave in their real-world context and design for that. And so I think specifically, the real potential of generative AI here, as I was saying, is not just to automate a bunch of tasks but really to help people clarify their intentions and goals and act in line with them. And so, in a way, it’s kind of about building tools for thought, which was the real vision of the early pioneers of computing. And so I hope that this, kind of, goes back to that original idea.

HUIZINGA: You mentioned this short list of open research questions in the field, along with a list of suggested interventions. You’ve, sort of, curated that for your readers at the end of the paper. But give our audience a little overview of that and how those questions inform your own research agenda coming up next. 

TANKELEVITCH: Sure. So on the, sort of, fundamental research side of things, there are a lot of questions around how, for example, self-confidence that people have plays a role in their interactions with generative AI systems. So this could be self-confidence in their ability to prompt these systems. And so that is one interesting research question. What is the role of confidence and calibrating one’s confidence in prompting? And then similarly, on the, sort of, output evaluation side, when you get an output from generative AI, how do you calibrate your confidence in assessing that output, right, especially if it’s in an area where maybe you’re less familiar with? And so there’s these interesting, nuanced questions around self-confidence that are really interesting, and we’re actually exploring this in a new study. This is part of the AI, Cognition, and [the] Economy pilot project. So this is a collaboration that we’re running with Dr. Clara Colombatto, who’s a researcher in University of Waterloo and University College London, and we’re essentially designing a study where we’re trying to understand people’s confidence in themselves, in their planning ability, and in working with AI systems to do planning together, and how that influences their reliance on the output of generative AI systems. 

HUIZINGA: Well, Lev Tankelevitch, thank you for joining us today, and to our listeners, thanks for tuning in. If you want to read the full paper on metacognition and generative AI, you can find a link at aka.ms/abstracts, or you can read it on arXiv. Also, Lev will be speaking about this work at the upcoming Microsoft Research Forum, and you can register for this series of events at researchforum.microsoft.com. See you next time on Abstracts! 

Transcript

NICOLE FORSGREN: Assume that something can be figured out and that it’s not hard. I didn’t find out until the end of college that computers were hard. And so if it’s hard, that’s OK. It might mean that you should just spin it on its head and try to take another look.

JOHANNES GEHRKE: Microsoft Research works at the cutting edge. But how much do we know about the people behind the science and technology that we create? This is What’s Your Story, and I’m Johannes Gehrke. In my 10 years with Microsoft, across product and research, I’ve been continuously excited and inspired by the people I work with, and I’m curious about how they became the talented and passionate people they are today. So I sat down with some of them. Now, I’m sharing their stories with you. In this podcast series, you’ll hear from them about how they grew up, the critical choices that shaped their lives, and their advice to others looking to carve a similar path.

In this episode, I’m talking with Partner Research Manager Nicole Forsgren. A leading expert in the field of DevOps and the lead of Developer Experience Lab, Nicole oversees Microsoft Research efforts to better understand and enhance the developer experience through the study of their productivity, community, and well-being. Prior to joining Microsoft, Nicole was a successful software engineer at IBM, a college professor, and a co-founder and CEO of a startup that was later acquired by Google. Here’s my conversation with Nicole, beginning with her childhood in Idaho.

GEHRKE: We’ve talked a little bit beforehand, but you’ve had this amazing career in tech. How did you actually … tell us a bit about how you grew up, and how did you end up in tech?

NICOLE FORSGREN: Yeah, it’s, you know, it’s, kind of, this ridiculous story. I grew up in a little farm town and ended up going to college and thought I would just be there a year or two because …

GEHRKE: Little farm town in?

FORSGREN: In Idaho.

GEHRKE: In Idaho?

FORSGREN: Yeah. So across the street from a potato field. My grandpa was a potato farmer. And where I’m from, girls—a lot of girls—go to college but not usually for very long. You kind of go to school to get married. And so I was majoring in psych and family science.

GEHRKE: So in high school, you didn’t know anything about or you weren’t excited about tech yet or anything?

FORSGREN: I don’t think I knew much about it, right.

GEHRKE: OK.

FORSGREN: So, I mean, we had a computer at home. My dad was a civil engineer. But I had only ever used it to write papers. I knew WordPerfect because back then WordPerfect was, kind of, the thing.

GEHRKE: Yeah, right. So it was a PC?

FORSGREN: It was a PC. It had, you know, reveal codes, which …

GEHRKE: It was DOS, just not Windows yet, right, or was it Windows?

FORSGREN: I think it was DOS back then. Yeah. And that was …

GEHRKE: And so connector interfaces and everything?

FORSGREN: Yeah,we had all the interfaces. And we had a typing class in high school, but that, that was it. And then I went on to college, and a couple of months into my freshman year, my dad, who I was really close with … so I grew up as a tomboy. I was always mountain biking up in the mountains. I was always just, like, dirty and, kind of, just playing around. I was very much a tomboy. Two days after Thanksgiving, he was in a snowmobile accident and in a coma, and suddenly, I sat back and I realized that, you know, all the things that I thought I was going to be able to rely on, like, you know, if I ever needed to fall back on my family or my dad or pay for things, for some reason, like, that was what stood out to me for some reason. You know, I was in college on a volleyball scholarship, and, like, I was paying for things and it was OK. But for some reason, that was what stood out at me—because I was the oldest of four children. The youngest was 11 years younger than me. So I was like, if anything happens, I think I just felt that responsibility, was that I was going to need to have money. And one of the girls on the practice team, I think in just a totally random comment, said that she could make money in her degree.

GEHRKE: Because you hadn’t chosen that as the …

FORSGREN: Yeah, it just, sort of, came … ooh, because when we went to college, it was, I was going to get married and so then I wouldn’t need money, right. Because I didn’t choose a degree for that. I want to say it was within a couple of days of my dad’s accident—so he was still in a coma; he was still hurt—and it was a very side comment she had made. And I remember hearing it, kind of, in the back, and I, kind of, perked up, and I was like, “What do you mean you can make money with your degree?” She said, “Oh, yeah, when I graduate”—with a two-year degree—”I can make $40,000 a year.”

GEHRKE: So she wasn’t at … was she at your university, or she was at a different …?

FORSGREN: So I went to a JC first because we don’t really go to college. And I was like, oh, $40,000. And I remember thinking, well, if I stay in psych and family science, to be able to make that kind of money, I would need to be a high school teacher, which requires a master’s degree. And so I talked to her just a little bit, and I said, “Well, what’s your degree?” She said computer information systems. I said, “Well, do you like it?” She said, “Yeah, it’s really cool. It’s computers.” I said, “Oh, and what can you make again?” She said about $40,000. I was like, “Cool.” And I just remember looking up that degree and going into finding, you know, I just found the counselors in that degree and telling them I wanted to change my major.

GEHRKE: Oh, wow, that’s a huge decision. I mean, first of all, did your father recover?

FORSGREN: So he ended up coming out of his coma within a couple of months, but he was brain damaged for the next few years. And he passed just after I graduated from college.

GEHRKE: I’m sorry to hear that. But then … so you went ahead and changed your major and went into …?

FORSGREN: I changed my major—without ever having a computer class …

GEHRKE: Right.

FORSGREN: … to CIS, which is, now I know, computers and business. That summer, I applied for an internship and got it. [LAUGHS]

GEHRKE: After your freshman year?

FORSGREN: After my freshman year.

GEHRKE: Wow. What kind of internship? Where was it?

FORSGREN: It was in mainframes for computer hospital systems. And so I showed up, and they thought I was full time, which I was not. I just interviewed well apparently. And so they threw me the manual and the documentation.

GEHRKE: What kind of mainframe was it? Do you remember what kind of machine it was?

FORSGREN: Yeah, it was AS/400s, and it was programing RPG and CLI, and it was for …

GEHRKE: Beautiful languages. [LAUGHS]

FORSGREN: They were. I loved it. And it was Siemens, um—SMS MedSeries 4 was the company, later acquired by Siemens. And it was a wonderful team, and I spent the first week reading the documentation and proofreading the documentation [LAUGHS], and then I just, kind of, dove in.

GEHRKE: So proofreading? You mean you discovered a bunch of bugs?

FORSGREN: There were a lot of typos, a couple of bugs, right. Because I just, kind of, had to figure it out as I went.

GEHRKE: Wow. So it’s not like somebody did preparing with you at the beginning? You were just handed the manual, and then you went with it?

FORSGREN: I was just handed the manual, and then I went with it. I had to …

GEHRKE: Wow, it’s an amazing self-starter.

FORSGREN: … figure out one or two things, and then I just dove in, and then I went back that next year and had my first RPG class. [LAUGHS]

GEHRKE: Wow. They were teaching RPG in college?

FORSGREN: Yeah. So this was … my freshman year was ’97-’98, and then my sophomore year was ’98-’99, so it was a JC, and they were, kind of, gearing up one or two classes in anticipation of the Y2K bug.

GEHRKE: Right.

FORSGREN: And so mainframes …

GEHRKE: Oh, I remember that. Yes …

FORSGREN: …and financial and hospital systems …

GEHRKE: Everybody thought the world was ending or at least some people were thinking the world would end.

FORSGREN: They were so worried about it. And so they had brought back one or two mainframe languages to help with the Y2K crisis. And so that summer, I did hospital systems. The next summer, I did, um, it was a company called Assist Cayenta, and it was, like, it was financial systems and ordering systems. That’s how I started my career, in, like, it was a version of mainframes.

GEHRKE: And then did you get that high-paying job afterwards?

FORSGREN: Yeah. So I had a full-time offer, but by then, I decided to go for my four-year degree. Transferred to Utah State, which was within a few hours from home. I still had to, kind of, stay closer to home because the family, and I wanted to, you know, make sure I was close for my dad. But then I did a six-month internship at IBM. I was a software engineer, and then they hired me full time when, again, I was a software engineer, so …

GEHRKE: But you basically finished the two-year college, then went to Utah State. Finished a four-year degree.

FORSGREN: Finished a four-year degree. Again, there I was … they called it business information systems—now it’s management information systems—at Utah State. It was a very technical degree, so I was doing network engineering. I was doing databases. I was doing, you know, C++. All my programing classes were all in the computer science department. When I got hired at IBM, they hired me as a software engineer. I was working on large-scale enterprise storage systems.

GEHRKE: Which language did you program in then?

FORSGREN: There, I was doing some C++. I was doing a little bit of C. I was doing some Java, and I was doing a little bit of their firmware.

GEHRKE: Wow.

FORSGREN: And then I eventually ended up managing some of their systems, so I did some Bash, and then eventually, I even got a hardware patent, so I—it was kind of everything! 

GEHRKE: Wow. So what is the patent about?

FORSGREN: It’s a way to, kind of, further obfuscate for cold boot attacks. This really, kind of, fantastic article came out showing that if you take compressed air and turn the can upside down, you can freeze some of the bits in chips.

GEHRKE: Right.

FORSGREN: And then if you rip the chip out, you can read what’s on the chip.

GEHRKE: Oh, wow.

FORSGREN: Because it freezes all the elect—

GEHRKE: Super interesting.

FORSGREN: … all the electrons on the chip. And we were like, well, this is ridiculous because it’s only frozen for 2 to 5 seconds. But then if you rip it out and you drop it in, like, liquid nitrogen, then you can read it for 2 to 5 minutes.

GEHRKE: Right.

FORSGREN: Like, well, again, this is ridiculous. But if you’ve entered in a password, then it’s stored in plaintext. Well, it’s not ridiculous if you get your way into a lab—and at the time, I was working in a large lab—because you’ve entered in the password for one computer, one of the servers, one of the stored servers, and you’ve destroyed the, you know, you’ve broken the disk for that one server, but the password is going to be the same for every single server in the lab.

GEHRKE: OK.

FORSGREN: And so we realized that this is a serious, you know, problem that’s a threat vector for a lab. And it’s pretty easy to get into labs, right. Like, you can just, you can follow anybody in. And so we wrote a patent that kind of further obfuscates and it hides where passwords are stored through malloc() calls.

GEHRKE: I see, so … I see. So the location of the password was then somewhat obfuscated and not so easy to find.

FORSGREN: Well, so the location of passwords but also additional plaintext strings and other strings are obfuscated through, kind of, throughout the pieces of, like, different areas of chips.

GEHRKE: This was motivated by the hardware but then implemented in software?

FORSGREN: Yeah.

GEHRKE: OK, wow, that’s super interesting.

FORSGREN: So part of hardware and part of software.

GEHRKE: I mean, just imagine this career, right, in … I guess in high school you’re playing volleyball?

FORSGREN: In high school and college, I was playing volleyball. Ended up getting hurt, so I didn’t play volleyball longer.

GEHRKE: OK. But then switched to, you know …

FORSGREN: Switched to tech.

GEHRKE: MIS, and …

FORSGREN: Yeah, switched to MIS.

GEHRKE: Patent.

FORSGREN: Patent—and shoutout to, you know, my coauthors on the patent, Ben Donie, Andreas Koster. They were great because we all just, kind of, ended up brainstorming one day. And it was this, kind of, windy path, but it was, I think, it was interesting because at the time, you know, I originally went into tech because I thought I would really need money but ended up falling in love with it, right. I’ve had a lot of fun along the way.

GEHRKE: So what did you fall in love with with tech? What really gets you going on tech?

FORSGREN: I love the fact that there are hard, interesting problems that you can solve lots of different ways. And if I can’t solve it initially and if I can’t solve it the first time, I can just kind of spin it around or pivot it in different ways and then just solve it again.

GEHRKE: So it’s this notion that you have this not only hard problems—because in math, you have lots of hard problems, as well—but here there’s the experimentation with it and the trial and error or …?

FORSGREN: The experimentation and the fact that it’s applied and the fact that I can build something and watch it work. Math I liked. And math, up to a point, I was pretty good at math, and I could kind of see how the equations were supposed to work. Computers and programs helped because I could really see how it was working.

GEHRKE: Yeah, I think that, I mean, I can so much relate to this because that’s how I fell in love with computing, because you have this machine here and it basically can do everything, right. And I mean, we will get later to AI. What we see with the current AI systems, right, you can see that, you know, it can be nearly intelligent or it is intelligent, right. And so it’s just amazing to have that kind of machine below you or with you to help you and to be able to train it and program it. And so, you were at IBM …

FORSGREN: So I was at IBM.

GEHRKE: … and now you’re at MSR (Microsoft Research).

FORSGREN: And now I’m at MSR.

GEHRKE: So what’s the bridge in between?

FORSGREN: Oh, so also, kind of, a windy path, but it’s interesting because as I look back, I guess it makes sense to me. So then I had an opportunity to go get a PhD, and I actually started doing, kind of, large data, like, NL, you know, natural language. You know, how do we want to think about, you know, analyzing sentiment analysis, analyzing, you know, those types of, you know, big questions like when are people lying, when are people not lying, machine learning problems. But I was also working at IBM at the time. Because I, like, continued to like, you know, working on systems and working on large problems. So I was doing both at the same time, and I ended up doing usability study … completely randomly. And …

GEHRKE: What was the study on? What did you study?

FORSGREN: So we did a usability study for sysadmins. And it was interesting because at the time, IBM was trying to build, like, a GUI for large-scale sysadmins. And so Todd Eischeid and I did the usability study. We wrote up the findings for IBM; we shared them. And, you know, we found that in some cases, they would use this frontend user interface and it was fine. And in some cases, they were like, “I don’t know,” right, “like I could click this button, but it really makes me nervous.” And we’re like, “It’s OK. It’s a sandbox. This is fake. You can click the button. I’m curious to see what the next step is.” And they were like, “It’s just so risky.” And it struck me as being, sort of, interesting because, like, there were just cases where risk and complexity really interfered with our ability to trust a system or to trust a GUI. And so we wrote this up and we shared it, and IBM was like, eh, you know, we used user-centered guidelines; we used, you know, user-centered design guidelines. We were like, but the same guidelines can’t work for complex systems and complex distributed systems that can work for laptops. And …

GEHRKE: Because in one way, I affect this one machine here, but in the other way, I affect this row of machines, and I know how many this actually is.

FORSGREN: Right. And they really wanted to see the command line interface and the backend data, and they really wanted to verify. And so you really had this difference between not just risk and complexity but also expertise. You know, there were some cases where you could hide complexity and other cases where it just wasn’t appropriate, right. And, you know, simultaneously, I’m working on these really, really large projects with IBM, and people are just, kind of, burning out. And I thought, you know, there has to be something to this, right. And there were kind of rumors as I was going to tech conferences still of, you know, this new-fangled way to make software and, kind of, reduce burden. And so I just pivoted. I changed my research project to start studying what now we know of as DevOps.

GEHRKE: Maybe we will get to this in a little bit, but I’m so impressed by, you know, you go to college, do A. Something happens. You do B, and don’t look back. Same thing here, right? You’re a successful developer at IBM. You have this event which says, wow, I should study this intensively, and you go and get a PhD, right. I mean, it’s just super impressive. How do you do that?

FORSGREN: It’s, I will say, it’s not always super straightforward, [LAUGHTER] but there are times when I, kind of, sit and I’m like, I’m getting one or two signals. I really want to take a half-step back and say, here’s an opportunity. Should I take the opportunity, or should I not? There have been one or two times where I’m not sure, you know, but there have been times where I’m like, I need to jump, and I can reevaluate in six months or a year, but I’m going to take this now. And I will say about 90 percent of the time I have been absolutely on.

GEHRKE: I find this so fascinating because we all are faced with different opportunities and chances in our lives. How do you evaluate this? Do you have, like, a checklist? Do you go back and ruminate and meditate on the mountain? Or what’s your method?

FORSGREN: I actually have a spreadsheet. [LAUGHS]

GEHRKE: OK.

FORSGREN: But I don’t always follow it. So what I like to do is identify, like, what are my criteria, which is, you know, what things are important to me.

GEHRKE: Yup.

FORSGREN: You know, some of my big moves—what’s important to me in the city? And then for each of those criteria … or when I am considering a new job—what things are important, and then how important are they?

GEHRKE: And you put, like, a risk score behind it or, like, a score?

FORSGREN: Either a risk score or an importance score. And then I’ll just, kind of, multiply it out. And, now, then I will go back and I’ll like …

GEHRKE: That sounds so amazingly systematic.

FORSGREN: … and then I’ll nudge all the numbers, and then sometimes, I’ll still change my mind because there’s something about your gut that says, I don’t know. But by identifying all those things first, it helps me think through it. Now, the spreadsheet, like, I’ve shared with folks, and it’s really interesting because just the exercise of saying what things are important to me for this decision and how important are they sometimes … not even doing like the math, right. Because it’s not real math. Let’s be real. Or it’s, like, very simplified math. Just identifying those things, sometimes just that exercise, people are like, “Oh, I know what my decision is now.”

GEHRKE: I think often just even thinking about this with that clarity, right, creates the resulting clarity then and think about all the factors.

FORSGREN: Right. And there have been times where I’ve completely changed what I thought I would do and, like, I can give an example. After I left academia, I was at a startup, and then following that, I started, like, my cute little baby startup company. I thought for sure I was going to go to a large consulting firm. I mean, I had them ranked. I thought I knew my choices, and I was like, no, let’s, let me think. Let me identify what order I should go in. And, like, it didn’t matter how I, kind of, rearranged all the numbers, starting my own company was at the top.

GEHRKE: Well, let’s go to that in your career.

FORSGREN: Yeah, so let’s, let’s catch up.

GEHRKE: Exactly, so you decide to go do your PhD?

FORSGREN: So I finished the PhD. I stay in academia for a while because I really like the research that I’m doing. It’s really interesting. I think I’m, kind of, on to something, and academia is a good place to do this, right. So I was a professor at Pepperdine for a few years. I go to Utah State for a few years. Again, like, what’s this opportunity? Pepperdine was a lovely place. The faculty were incredible. Malibu is gorgeous. Utah State, my alma mater, comes along, and they’re like, we would like to hire you, and we’ll create an opportunity for a new position. So I took that pivot. And now it’s a joint appointment to create an analytics program in the MIS department. I was also an accounting professor, because I have a master’s in accounting, so it was, kind of, this, like, perfect situation. I was there for, you know, two, three years, and I’m doing really, really well. A really strong path to tenure. Letter from the provost saying that things are looking really well. And I’m like, this is good, but it’s not great.

GEHRKE: You had a spreadsheet that said that basically or [LAUGHS] …

FORSGREN: This was in my gut.

GEHRKE: This is just “I had a feeling.”

FORSGREN: In my gut, I’m like, I’m doing really well. My research is going really well. We just hit the Wall Street Journal because we find early signal that DevOps—like now it’s being called DevOps—shows organizational impact. And so a few folks in industry were coming to me and they said, you know, “This is super relevant. You’re really changing how we’re doing things.” This was still, kind of, earlyish in this research program, and they said, “What if we create an opportunity for you where you could spend half of your time doing research and half of your time helping our company improve our engineering practices,” and I was like, I think I might do this. You know, at that point, I just decided to go for it, and it was a little company here in Seattle called Chef Software.

GEHRKE: It was actually here in Seattle?

FORSGREN: I was here in Seattle.

GEHRKE: Chef Software?

FORSGREN: Yeah,they did configuration management software. And also, that was a really interesting tie because—or, kind of, like pull, tug and pull because I was doing this research with their competitor called Puppet, and I went to Chef, and so I’m, kind of, like, managing these relationships really well or as well as I could. But that was also one of my first exposures to managing conflict at work and in professional relationships because this report, it was a research report, but it was done, kind of, through industry. So the main sponsor was Puppet, but I was working at Chef. And so how do I manage that? So I was at Chef for a year and a half, and then at the end of that year and a half, we, kind of, looked at each other and we were like, I think we’ve reached the end of this road because I had done about as much as I could do for this little startup. They had about 200, 250 people. They really didn’t need a researcher. They were doing me a solid. And then at the same time, we had, kind of, spun out a separate entity called DORA—DevOps Research and Assessment—and we said, so what should happen here? We had been doing research, the State of DevOps Report, but then so many companies were coming to us and they were saying, what if I want to have our own customized assessment? How could we do this? And, you know, I looked at a couple of my co-founders, you know, Jez Humble and Gene Kim, and I said, I know how to do this. I know the algorithm I would use. I know how I would build this out. I think we could do it, a SaaS company. I have a very low risk tolerance. I have never wanted to start a company. And I think, you know, to your prior question, like, how have I thought about doing this before? I actually looked at them, and I said, you know, who wants to be CEO? And they said, we think you should. And I said, eh, I’ll give you one year, and then I want you to tell me if you want me to continue doing this. And so we started this company. I mean, our first prototype, I drew pen and paper in the back of a notebook, and I showed it to Capital One, and we said, would you buy it if it looked like this? And then we just, kind of, iteratively built out pieces and pieces. And I was like copy-pasting pieces of it into reports as we went. And then at our offsite after one year, we read our results. I shared ARR and sales projections, and I said, OK, well, you have a first right of refusal, and do you want to renew? And they looked at me like what? And I’m like, no, it’s been 12 months. Do you want me to return again? And we just, kind of, decided if we wanted to. After that, things were going really well, but we were also growing and scaling really, really rapidly. Too fast for us to keep up as a bootstrapped company. And so, you know, I needed to figure out how to gain and acquire infrastructure. And so that would either have been external funding and hiring really rapidly or getting acquired, and so we … I approached a handful of companies, and Google acquired us.

GEHRKE: Wow. It’s an amazing story and must have also been a time of craziness and also fear of uncertainty. How, you know, what were some of your emotions during that time?

FORSGREN: It was. It was a lot. It was really interesting because it was, kind of, balancing also a few things, right. Because I had … I think some of it is also balancing identity, right. Am I a researcher, and how do I think about maintaining that identity and that credibility that I care so much about when the research and “publication path”—you know, kind of, in finger quotes—that I care so much about has shifted, right. Because now I’m doing a lot of applied research, and how do I think about that? Some of it was, am I an entrepreneur, and what does that look like, and what does, what does that credibility look like? How do I put out a product fast enough? How do I manage and maintain this company? How do I manage and maintain relationships with my employees, with my partners, you know, with this partner ecosystem that we’ve developed? And then when we get acquired by Google, what does that look like? How do you manage that growth path?

GEHRKE: And these are all very, very different skills than you had as a software developer or even as a professor.

FORSGREN: Especially as a professor. Right. And it was also a really, really wonderful time, I think, to grow and learn and iterate. And I’m really grateful for the partners that I had along the way, right. There were times that were bumpy, right. But I appreciate that we were really honest with each other, right. There were times when we disagreed, and there were times when I also said, like, I know this is the right thing. Please, you have to let me do this. And there were times when, you know, they had their expertise.

GEHRKE: And then, you know, you were at the company. The company gets sold to Google.

FORSGREN: Yep, company gets sold to Google.

GEHRKE: Now you’re at MSR.

FORSGREN: And then I was at Google for a little bit. And then I had this amazing opportunity to join GitHub. And I was really excited about that because that framing in that invitation, we were talking about, you know, what could it look like? You know, what would a perfect world be where I could return to something that looked like research and strategy? Because I realized there were pieces about research that I really, really loved. And there were also pieces about, I don’t want to say products—it’s not quite product—but it’s about strategy. What is it that I love doing in terms of, kind of, execution and identifying holes, and how does that feed back into the research projects that I want to do? And so when Microsoft first approached me, they said, you know, what would your ideal job look like? And I, kind of, laid that out, and they said, you know, well, let’s think this through. And so we started with GitHub because, you know, if you want to study developers, that’s an amazing place to start. So we did a couple of iterations with the Octoverse report that were really rewarding and then we said, you know, another good place, you know, another wonderful opportunity would be to think about developers and a Developer Experience Lab. And if there’s a research lab, where does that live? And we talked about it some more. You and I did, too.

GEHRKE: That’s how we started talking … exactly.

FORSGREN: Yeah, and we thought, you know, MSR really is the perfect place for that to live.

GEHRKE: And you’ve been at MSR now for a few years, and now we’re going through yet another change. I mean, you’ve been through many of these changes before. We talk about this current change. It seems like, again, coming back to this, you’ve been amazing of, like, when the environment shifts, finding out where to go. You know, you have your spreadsheets, you know, as one mechanism. Now we’re at another sea change with AI, right. And AI is clearly changing the way we write code, which is, sort of, the innermost loop right now with GitHub, with Copilot, but it’s probably going to make it much more into the inner and outer loop and the whole way we write code and the way we develop with low code. So, I mean, first of all, how do you think about that sea change, and how do you deal with your research group and, you know, yourself as an identity, again, as the world around you is having this massive change towards AI?

FORSGREN: You know, sometimes, I just laugh that the world is a circle, right. I’m really excited because, you know, we’ve come back around to getting to rethink what it means to do what we love, right. So I’m personally getting an opportunity to come back to be a developer again, right. What does it mean to dive back in and learn brand-new things again? Because AI is new for almost all of us. Even people who have been studying AI for 10 years are saying, like, so much of this is new, so much of this is something that we couldn’t have predicted. I’m getting to, you know, dive back in and play with new tools and new technologies, and that I really love. I also love that you mentioned that, you know, there’s the inner loop and there’s the outer loop. And so in terms of my team, I’m really, really excited about the team that I get to work with because …

GEHRKE: Do you want to explain maybe a little bit, just for the audience, inner and outer loop?

FORSGREN: Yeah, so inner and outer loop. So inner loop is, you know, the coding that we do, kind of, locally, so it can be writing the actual code, you know, local build, if you do local build. It can be debugging; it can be everything that’s like just right there on your screen as you’re writing your code. Now outer loop is everything that you do to get that code running in production, right. So it can be additional tests. It can be integration build. It can be, you know, everything out through release and deployment until we’re operating that code and then, like, continuing to operate that on our systems at scale.

GEHRKE: I mean, the way I saw this was so impressive when I joined Microsoft, of course, right. What it means to actually … that first of all, software development is a team sport, right.

FORSGREN: Yes.

GEHRKE: And also it’s not a team of like 11 people like soccer, where I grew up with, but it’s a team sport of, you know, potentially thousands of people, right, and that there’s an, actually, there’s a lot engineering systems around it. And it’s called software engineering for a good reason.

FORSGREN: Yeah.

GEHRKE: Because there’s systems around it that help us to scale to that many people contributing to a single outcome. And so the inner loop is, basically, my notion is that when I do my own little exercises with the ball and then the outer loop is when I actually, you know, do strategy with the whole team and see that I integrate well. Is that a reasonable analogy?

FORSGREN: Exactly. And so sometimes the joke is, you know, well it worked on my machine, right. That’s kind of inner loop. Yeah. And then outer loop is all of the orchestration, right. All of the architecture. Everything else that we need to make things, especially really large things and complex distributed systems, work at scale. Yeah.

GEHRKE: And so if you think about … how do you think AI would influence both the inner and outer loop? I mean, we see what’s coming out in terms of, you know, GitHub Copilot and even more capabilities. I mean, in the “[Sparks of Artificial General Intelligence]” paper, we describe that GPT-4 can actually write an application with close to a thousand lines of code, right. So how do you think AI’s actually going to influence developer productivity and software engineering as a whole?

FORSGREN: I think there are so many exciting ways to think through this, right. I love your point that there’s inner and there’s outer loop, right. So, yes, we absolutely have opportunities to think about how it influences the way we write code, but I think it also has so many opportunities downstream, right. How can it, how could we use it to improve our code bases, right? Can it identify technical debt and clean up some of our technical debt for us? Can it help us think about downstream incident management? Can it help us manage our servers and our systems? Can we use it to take a look at our code for us? Can we ask it, can you please help me improve the security posture of my code? Can you help me improve the performance of my code? Can you help me improve anything else in my code, right? Even that explicitly: can you say, is there anything I haven’t thought of in my code, and what should I do? We can ask it, you know, to proactively watch and monitor our systems’ performance for us and then proactively manage that for us, you know. As we look, you know, even further into the future, there may be opportunities for brand-new abstraction layers. What happens if we let LLMs, or invite LLMs, to execute for us and then reason about that code for us so that all we need to do is guide and direct it?

GEHRKE: We’ve been talking a little bit about code, but maybe in the future, code would be, sort of, this low-level abstraction like what we have right now with assembly. There are very few people who still optimize, let’s say, locks and database systems with the assembly code, but most people write at a much higher level of abstraction. So what do you see as this next level of abstractions that are coming?

FORSGREN: You know, I think …

GEHRKE: Is it language, basically, language interaction?

FORSGREN: I do think some will be language. You know, I really like that idea for at least a few things, for a couple of things I just mentioned, right. Like asking it to do things like please check for security; please improve the performance. Can you help me generate workloads? Can you help me run these type of canary tests, right?

GEHRKE: Like semantic linters with a very bigger … with much bigger capabilities.

FORSGREN: Exactly. I also think there’s an opportunity for graphical interfaces, and by that, I mean what if we create a diagram or a UML and then ask it to implement that in the best way possible. Or reverse it, right? When I think about when I was working in code bases, the best way I could get a feel of the code base was to code it, and then I could create this mental model. If we’re doing less coding, how can we create that mental model? I think there could be wonderful opportunities to ask or invite these LLMs to diagram some of these code bases for us.

GEHRKE: So interesting …

FORSGREN: You know, don’t just ask it to create documentation or explain it to us, because language can be somewhat limited, but we know that diagrams and pictures can be incredibly powerful.

GEHRKE: I see. Create the actual architecture diagram for us.

FORSGREN: Create an architecture diagram—and create it in two or three different ways to help us understand how different components interact, which can also help us understand where there may be redundancies in code. There’s a huge amount of technical debt out there, right. So I think that, kind of, opens up some really interesting ideas for what could be there. You know, there are also some wonderful horizons that we’re already approaching in terms of testing and exploratory testing and what that can mean for really improving the way our code works.

GEHRKE: It’s super exciting. I mean, I would love to be able to talk more about that with you. But let me ask one last question. I mean, you’ve had this absolutely stunning career. I mean, if you think about where you started out, you know, then developer, you know, professor, startup founder, you know, working in a big company, being in a restructuring of the company, for someone who’s starting out, what’s the career advice that you give for anybody who’s right now starting and going into tech, people who are at university or just graduating?

FORSGREN: I think there would be two, and I think they’re related. One would be assume that something can be figured out and that it’s not hard. I think that would probably be one of my best tricks. I didn’t find out until the end of college that girls were bad at math, which I am not, or that computers were hard. It really helped that for most of my life, my dad just, sort of, helped me rethink through things or repivot or retry lots of things. And so if it’s hard, that’s OK. It just might mean that you should just spin it on its head and try to take another look. So that would be the first one. And I think the second one is consider new opportunities and go ahead and take them. And if after six or nine or 12 months, it’s not the right opportunity, go ahead and change your mind. I would not be where I am today if I hadn’t taken one or two really incredible opportunities that seemed a little bananas at the time, and it just worked out.

GEHRKE: That’s amazing advice, especially also in something that tells us to A/B test even our own life. The only problem is that we have only a limited number of tests that we can do, but I mean, it clearly is an amazing story. Thank you so much for the conversation.

FORSGREN: Yeah, thank you.

GEHRKE: Thank you.

To learn more about Nicole’s work or to see photos of Nicole as a child in Idaho, visit aka.ms/ResearcherStories (opens in new tab).