An inside look at SPACE with Dr. Margaret-Anne Storey

Abi: Peggy, it’s so great to be sitting down with you and talking about SPACE and all things developer productivity. This is something I’ve really been looking forward to for a while. To begin, you could give us a brief overview of your background and what your work focuses on?

Peggy: Sure. And thanks, Abi. I’m super excited about this conversation and chatting with you and maybe some other people about what SPACE is about and about developer productivity in general. So first of all, me. So I am a professor at the University of Victoria. I’ve been there for quite some years. I also consult a lot with industry in particular, lately I’ve been consulting with Microsoft over the past few years.

I’ve also done some work with Abi who might talk about a bit later on. And my research focus has been on understanding how to improve developer productivity and satisfaction. And how do, how to come up with better tools, how to come up with better processes, and just generally how to improve productivity, engineering productivity, and developer wellbeing.  

Abi: I think a lot of people listening are familiar with what improving productivity sort of looks like on the industry side, but it’d be great to just hear a little bit, as a professor, what does that look like? What does your work focus on, and do you work with students? Are you guys cranking out papers? What does that look like?

Peggy: Yeah. So I’ve been collaborating a lot with industry and working with students with industry as well. On the research side, we work with students. Obviously writing papers is kind of how we measure our performance, which I’ll get to in a little bit. We do a lot of studies, so a lot of rigorous studies. We build on a lot of other research. So we build on theories, not just from software engineering, but also theories from behavioral psychology and social sciences.

And we try to bring what we know already from research and use that to discover new problems or new theories that help us understand a phenomenon that we’re studying, or to come up with ways, theories about what could improve. And then how do we run studies to maybe experiment or to understand do the things that we design bring improvement. So with the students, many of my students have interned or worked with industry as well.

So a lot of my research tends to be really centered around working with industry because I’m very much interested in the real problems that practitioners have and understanding those problems and understanding ways to address those problems. And my students tend to also have that applied perspective as well. But I do do a lot of kind of more research, kind of geeky stuff on the side, which we won’t talk about today, but yeah, I have a passion for, for learning about a breadth of research and then, how do we apply that and translate that to other new fields?

What the SPACE framework is 

Abi: So it seems like the SPACE framework is one of the attempts at applying the research. Can you provide just a high level overview of what The SPACE Framework is?

Peggy: Definitely. It’s definitely about it being applied, and it was definitely a paper that we wrote to aim at practitioners more than at researchers. So productivity, what does it mean? What does the word productivity mean? It’s a very, very complex construct. It’s a human construct and… Sorry, I’m just going to silence some of my messages here that are coming in. It’s a human made construct, right?

We try to describe what does it mean? And it means different things to different people. In fact, I did a study before we wrote this paper where we asked developers and managers to define productivity and they came up with very, very different definitions. And how productivity is measured really varies a lot when you talk to different people in industry or just even how they think about it. How can you measure it?

So I don’t know if you want me to tell you where this paper came from before saying what it is, but this paper came from… You can see the names here, actually. So it was a bunch of us. We were, during the pandemic, studying productivity, and trying to understand what is the impact of suddenly having to work from home basically overnight on developer productivity. And we were doing a lot of different studies. Myself and Tom, for example, and Brian, we were doing surveys with developers.

Jenna was doing diary studies. Chandra and Nicole were looking at telemetry data. And we were, together, trying to make sense of what productivity meant, and how we could shake up, if you like, a little bit the way that industry was thinking out productivity in a very narrow way, and basically say productivity is very complicated and it’s personal. And it refers to a lot of different things. You can’t just look at telemetry data. You have to think about it in a very, very rich way. And so that’s what led to SPACE.

Why the researchers came together for this paper

Abi: That’s a fantastic overview. And you touched on this in that overview, but why do you think… Why now? Why is this paper and this research needed now in the context of industry?

Peggy: I think it was needed for a long time, but it was just… The pandemic kind of forced us to say, “Okay, we have to do something about this.” All of the people that are listed there on that paper, and I should say there are many other people that I’ve collaborated with whose research and insights and opinions have contributed to it, we’re all, I guess, very aware that productivity is complicated and you can’t just measure it using one metric or even a couple of metrics. And that there’s a lot of myths about productivity and trying to measure it, using these very, very narrow perspectives is dangerous and very risky to other developers and to companies.

And so we got together and we’re like, "Okay, there’s a lot of research that talks about this and has a lot of the insights in SPACE that has been sort of rigorously researched, but how do we put it in a form that we can get the attention of practitioners so that we can shake up their opinions, change their mind about the myths that they might hold and give them a way to talk about productivity with their team and with other people, and give them a way to think about what might need to be improved, and even how they may try to measure it, although that can be challenging?

The process of writing this paper

Abi: Definitely. And so for people listening who don’t have experience in “research,” what was the process like with all the different co-authors? What was the actual process of producing and writing and drafting and conducting research to build this paper?

Peggy: That’s a really great question. So actually the process for this was quite different to other papers that I’ve written. And I have to say it was probably some of the most fun that I’ve ever had writing a paper. It was fun because we were all passionate. We all cared about it. And I think Nicole, she has a great sense of humor, with the other authors that are on the paper, Tom, Brian, Chandra, Jenna, and I think I said Brian already.

We’ve worked a lot together, and one of the things that we do is we laugh a lot. And so working on this paper, we really had a lot of fun working on it because we cared about it, but we also saw a lot of humor. And I think that that helps us kind of share all of our insights and perspectives. The idea to write the paper was to have something that industry… That we would shake, we would change how practitioners thought about productivity and get rid of those narrow definitions and narrow metrics.

And between us, we had so many insights to build on. So several of us were more on the research side, but Brian, for example, and Nicole came from industry and brought very deep in insights from industry and Jenna as well from doing the diary studies. And so bringing those different perspectives together, a lot of rigorous research, as well as our insights from working with practitioners, that was basically what we did. We shared what we knew. It was during the pandemic, so we were remote.

We met weekly. I think we met on Friday mornings, pretty much, and we would brainstorm about what are the main dimensions that are coming out about productivity? And we had a whiteboard and we sketched on the whiteboard. And then once we decided on the main dimensions, we also thought about, “Well, what are the myths? Let’s write those down.” So we brainstormed on what are the myths that we had each heard and which one should we include in the paper?

And then from the dimensions, we then started talking about, what are some possible metrics? How could you take those dimensions and then turn them into metrics? And actually writing the paper was something we did collaboratively. So we would all have our… I guess we were using Teams. We’d have our cameras on, but we would all say, “Okay, I’m going to write this part. Okay, I’m going to write that part.” And then we would just say, "Hey, I’m kind of stuck on this. What do you think about this? And then we would just kind of share, and then we’d go back to writing. And most of the paper was written that way with a few sprints on some weekends and maybe a couple hours before the meetings.

How the SPACE categories and acronym emerged

Abi: Well, you mentioned the categories, so you distilled productivity down into these five categories, which is an impressive feat. Can you share more about how those categories emerged and were there disagreements? How do you feel about those categories now? Yeah. Share the process of how you guys came up with those five categories.

Peggy: So, they are based on a lot of research findings. So an earlier study that I did with Tom and other folks at Microsoft. We came up with 44 factors, for example, that we found impact developer productivity and developer satisfaction. This was a quantitative survey, so we were able to do some clustering with those factors, and then those led to categories of factors that impact developer productivity and satisfaction.

So some of the themes came from that, but I think a lot of the themes honestly came from our experience as a group, that every time we had done a study or talked to people about productivity, that these were the top level… The top of mind themes, if you like. I don’t know that I’d call them categories, but more dimensions of productivity. The ways that people think about productivity in terms of the activities that they do, or that it’s about how they collaborate with others, or their ability to work in an efficient way without interruptions.

These were really the top of mind, things that came out, and we didn’t disagree on those. We did disagree a little on which words to use to describe those because each of those is also quite complex, but early on, I think Nicole said, “We need a good acronym for this,” which was pure magic, actually. We did disagree on which words we would use for describing those dimensions. And in part, we were driven by trying to come up with a word and of course, SPACE was a great word for capturing this. And then we aligned the dimensions with those words. So there you go. There’s the kind of the behind the scenes look at where those came from.

The authors’ intention for how this framework would be received

Abi: So you came up with this framework and as authors, what was your intention for how people would use this framework? What was the vision for that?

Peggy: The main vision was to change how people think and talk about productivity. To get away from thinking that productivity, first of all, can be measured in just one way, with one metric. Or even, I would say, a set of universal metrics that you could apply say across the industry, because productivity is really personal to developers, but it’s also very context dependent, right? In terms of different projects and even different state of the project, right?

Is it a new startup or is it an established team that’s dealing with technical debt say in a project? And so the first thing that we wanted was to change how people think and the way that they talk about productivity, and to call out when they see people saying, “Well, if we do this, it’ll improve our productivity.” To then ask a question, “Well, what does, what does that mean to you,” right?

“When you say improve productivity, what does that mean? Is it improving the quality of the outcomes or the code that you’re writing or is it developers spending more of their day writing code, or is it developers helping new developers on board? What does it mean?” So that was the first thing. And then I guess we were also hoping that it would shake up some of these myths as I was mentioning. And it would also give some guidance to attempts that are made if there is an attempt to measure. But even then, we have a lot of caution around how those metrics are being used.

Finding a definition for what developer productivity is

Abi: You mentioned something interesting that industry has varying definitions for productivity. I’m curious, in your personal experience, because I’m sure you’re getting hit up all the time by companies and practitioners. What do you think is the most conversion or, or common definition or meaning of productivity when people come to you and ask you to help them measure it or understand it? What do you think they mean?

Peggy: So often they don’t know. So that’s why it’s always important to ask, “What do you mean by productivity? What does that mean to you?” And it’s not just, what does it mean to you, but who cares, right? If you’re trying to say, “I want to define and measure productivity,” for whom, right? And for what purpose? Why are you doing that? Are you trying to understand what’s going on? Are you trying to improve it, or are you trying to understand the impact of an intervention?

So that’s the first thing. And actually going back to your last question, one of our goals that I didn’t mention, and I think it’s important here is that we wanted practitioners to be aware that if they did try to improve some aspect of productivity, that it could have an impact on another dimension. So for example, you might assume that allowing developers to have no interruptions will improve their satisfaction and will also improve the quality of the code overall. But perhaps it doesn’t, right? Because other developers on the team might get stuck or they may not be interrupted and told about this change and how it could impact other parts of the system.

And they may get bored writing code all day long. I know many years ago, I thought I wanted to be a developer. And then I found, “Oh, I’m kind of bored if I write code all day long.” So you can’t make those as assumptions that if you make a change in one place, it’s going to make changes in others. So coming to my own definition of productivity, I don’t think we can really define productivity. I think productivity is this catchall phrase. It’s a very, very big and broad concept, and it’s better to be more specific about goals, right?

So what does productivity mean? If it’s about improving the product, the quality, even that is a very broad concept. If it’s about feeling that your productivity, well, what does that mean? So for me personally, if I look at my own work, and maybe this is what you’re asking me to get into, if I think about how do I measure my own productivity, in my earlier days, probably as a professor, I would write down goals for the day, and I would write down goals for the week and goals for the term. And I was always feeling that, "Oh, I’m not achieving my goals.

I’m doing all of these things, but I’m being interrupted." And then I shifted, and perhaps I shifted because I could. I have tenures, so I’m allowed to do this. I’m a little bit privileged, but I shifted towards thinking about my values rather than my goals. So what do I value? Well, I value helping people around me. I value helping students, and mentoring people, and I value teaching other people and sharing information with other people, not just creating new knowledge.

And so once I’ve realized that, I started writing down everything that I do you in a day. And so I have a log, and then at the end of the day, I can go, “Well, I didn’t get the things done that I thought I was going to get done today, but I did all of these other things, and these things do align with my values so I feel productive.” So for me, I think it’s about defining your values and then seeing “Am I doing things that I feel bring value to me or to other people?” And that’s not really the definition I think you were looking for, but yeah.

The metrics included in the SPACE framework 

Abi: Was that something your group was looking at in the development or the curation of these metrics, and have you seen examples of that out from practitioners?

Peggy: So the metrics that we included in the paper were example metrics, and we gave example metrics by three levels, the individual, the team and the system, because you can think about productivity at those different levels. We didn’t intend to curate a full list of metrics or even claim that these are the metrics that you should use. They were example metrics. To come up with metrics, it’s really important to go back. I’m going to sound a little bit like a broken record, I think today, but I think it’s really important to define what your goal is before you jump to defining metrics.

So I’ve seen often, with groups and even in academia too, that people start with trying to define a metric without really understanding what it’s going to be used for. Well, we do this with software as well, right? We create solutions to problems that we don’t really know whether they exist yet. And we don’t really know who has the problem, and these are why some startups fail. And the same with metrics. Metrics will fail and will be misused and will introduce risks.

If there isn’t a clear understanding of how they’re going to be used and why they’re going to be used, and also then tracked over time to see what impact they have. Because over time, the things that you measure and your needs and your context are going to change as well. And you might also be aware that having this metric, there’s an expression, you’ll get what you measure, right? So if you measure pull requests, you…

I did this when I was teaching this last term, I told my students, “I want to see your poll requests so I know how much effort you’re putting into the projects.” Well, guess what I got? I got more pull requests. Not necessarily higher quality code or solutions to the problems, but I got more poll requests. So you have to be careful over time. But I think in terms of actionability, the metrics can help guide us towards some of those actions that we need to take to bring value. 

Abi: So what has the industry reception of this paper been like for you?

Peggy: Yeah, it’s been huge. In part, I think, because Nicole is so well known in industry, and so she’s advertised it through social media. We also published it in ACMQ, which was intentional because that is aimed at practitioners rather than some of the other venues that we tend to publish in research. And so a lot of people have seen it. I am curious to know how a lot of companies are using SPACE.

From a high level view and from what I’ve seen and chatting with a few people, I think that for the most part, it’s shifting how people think about productivity. And I think that was the main goal that we had. But I do think that some folks are perhaps struggling a little bit to use it to come up with metrics. So in our industry, a lot of us are engineers.

I’m an engineer, that’s where I started. And we want objective data. We want to measure things. We want to know, “Are we making improvements?” And so there’s still this desire to look at those different dimensions and then perhaps choose objective or quantitative data, some telemetry data from systems, for example.

But one of the things that we talk about in the paper is don’t just use that kind of data, actually talk to people. Ask them, what is their… How are they feeling? What is their perception of productivity? What are their barriers? What are their challenges? And use the dimensions to help drive the kinds of questions and the kinds of places that we look to get insights on productivity.

Abi: That’s really interesting. So I’m gathering, are you getting lots of questions from industry, just asking you, “Okay, here’s this framework. Now what metrics should we use?” What kinds of questions are you hearing?

Peggy: Yeah. A lot of people are trying to figure out how to take the dimensions in SPACE and then turn them into metrics in a dashboard. And my usual answer to that is not one that many people might want to hear. It’s not a quick fix. It can’t be applied. It doesn’t take away the hard work that you need to do to understand what is going on in your team or in your company or between teams or with your engineering system, that it takes a lot of work to understand what’s going on.

And choosing metrics might bring some visibility and signals that there are problems, but you still need to then go and look at that and try to understand that in a very deep way. Do I think that you can use them? I think that you could use these metrics in small teams. When everybody buys into what these metrics are measuring, they’re all proxy measures, they’re not perfect and they will shift over time.

But if you use them in a very intentional way, and everybody understands why we’re using those metrics and that they can’t be used in isolation, then I think they can bring some value. But I don’t know that you could apply them across a large company and then say, “Oh, look, this team over here is doing so much better than this other team, and here’s why.” Because I don’t think there’s a universal set of metrics.

Abi: That makes sense. And that’s definitely a theme in the paper. One other thing that was interesting to me in the paper, it’s mentioned that productivity and satisfaction are intricately connected, and I know this has been an area of research for you for a long time. Can you explain what that means?

Peggy: It’s not just research that I’ve done, but also there are other researchers in my community. So [inaudible 00:25:54] for example, have looked at happiness of developers. And one of their insights is happier developers feel more productive, and developers that are more productive, feel happier. Satisfaction is a little bit of a slightly different concept, but it’s related, of course.

So what we found in our research though, is that yes, they’re related, they’re correlated, but there are many other factors that mediate and moderate that relationship. So you can’t just say that if a developer feels satisfied in their work, that they’re going to necessarily feel more productive and vice versa. You have to look at these other factors as well. So their work environment, their culture of the team, the psychological safety that they have, how their manager is managing their team, all of these things play a really, really important role in both of those, as well as the tools that they’re using in their process.

Abi: Is there a chicken and egg thing here? Which comes first, satisfaction?

Peggy: Yeah, yeah. So we did not look at causation. We do not claim causation. My own opinion on this is that all of these things kind of move together. That if you’re feeling satisfied with your work and you have a positive work environment and feel that your work is appreciated, and you have that autonomy, that is going to… There is a bit of a relationship, but it goes in both directions.

So if you’re feeling all of those things, and I feel that you value… Say we’re working together and you value what I’m doing, then I’m going to feel that, “Oh, I’m more productive. My boss values that I’m helping all of these other people.” Likewise, if I get a lot of things done and I get these great features done, I am going to be more satisfied as well. And there is a lot of research and organizational psychology that does look at this and does see some causation going in both directions.

How SPACE is different from DORA

Abi: That’s really interesting. One question I had for you. Prior to SPACE, you mentioned Nicole’s pretty well known in industry with her book. And of course, one of the most popular sort of sets of metrics in industry prior to SPACE were the DORA metrics as they become called. So you worked with Nicole on this paper. How, how is SPACE different than DORA? How do you contrast these two sets of metrics?

Peggy: Yeah, to me, and I think perhaps Nicole as well, DORA is more focused on the process and the engineering and the delivery of features through the software engineering life cycle. The SPACE framework is more looking at it from the lens of the developer and the team, although it also can be used to think about the system as well.

So they’re definitely related, but I think DORA are more specific and can be operationalized a lot more easily in some ways. Although I think a lot of practitioners still struggle with that because again, context matters, but SPACEs is broader. It’s much broader. And I think SPACE touches a lot more on the perspective of the developer, right? And their experience for working.

Why lines of code and number of pull requests were included as example metrics

Abi: That makes sense. One other thing I saw in your paper that caught my attention, you talk about lines of code and velocity points. They’re in the table of example metrics. And I’m just curious to know, those are metrics that in industry, there’s been quite a bit of controversy around the usage of those types of metrics. I’m curious, was that a point of discussion for the authors when you were writing this paper?

Peggy: Oh, absolutely.

Abi: I’m curious to know what the perspectives were on that.

Peggy:  I mean, we would kind of laugh about it, really, that lines of code is being used as one of the metrics, and even the number of poll requests. But we put them in because they are metrics that we find a lot of practitioners do use. And so to kind of reach out to them and to build a bridge, we included those in the table. They are signals though. You can’t that they’re completely useless. I think that they are worse than useless if they’re used alone, but they’re still signals. And I was talking about assessing my student groups. If they’re not producing any lines of code, and not committing any code, then it’s, “Okay, I’ve got to talk to them. What’s going on, folks? What’s happening?” So they are important signals, but they can’t be used by themselves.

What Peggy is thinking about next

Abi: That makes sense. Well, you’re involved, deeply involved in this kind of research area. And I know you’re constantly thinking about the next sort of evolution of solutions in the SPACE. I’m curious since publishing the SPACE framework, how have your opinions or recommendations, how are they evolving?

Peggy: So, you know about it a little bit of it because we’ve been doing some of that work together. I think SPACE is great. And I think if any practitioners care about productivity or trying to measure it, or trying prove it, they should read that paper, because I think it has a lot of insights, but in terms of trying to measure and perhaps be a little bit more actionable at the level of the developer, I think that we need to think about how to measure their experience and what factors are going to be important.

And there are many different factors that influence experience, just like your happiness. There are many, many different factors that influence how happy I feel. And the same with developers, and it’s important for industry, not just because they need to retain their engineers because losing their engineers is so expensive and disastrous in some cases. But also because if their engineers do feel happier in their work and more satisfied and are having a more positive experience and they’re motivated to do the right things, then they’re going to produce code that’s better.

It’ll be higher quality code, they’re going to work more effectively and more efficiently, and there’ll be more communication in the team, more awareness about what’s going on. So I think focusing on… I think we’ve done, as a research community, a pretty good job at describing the factors. “Okay, you can look at different papers and there are different words used and maybe some pop up higher in the models than others,” but we kind of have it. We kind of know, right? That all of these things matter.

What I’m not sure that we’ve spent enough time on is really understanding how to make change, and what interventions, what changes should be important. And actually, I’ll give you an example of one that I was listening to a talk yesterday by Kat Hicks. I’m not sure if you’re familiar with her work. And so she’s been looking at the importance of learning. And I love her research because learning was one of the themes that came out of my research when I was at Microsoft and studying developer satisfaction.

That learning was really, really important for a lot of the engineers. Not just in being productive down the road, but in their satisfaction, in their feeling of being competent. So if you want to… Actually, there’s a theory called the self-determination theory, which talks about the needs for people to feel motivated towards work. And that theory talks about autonomy, competence and relatedness. And so competence comes from learning and feeling like I’m learning something new. And so, as a team, you might want to be thinking about supporting your engineers to learn.

Not just because it will help them down the road in choosing better technologies or using other frameworks, but because it will also make them feel more satisfied and more engaged and more motivated to do their work. So I think as an industry, we need to stop trying to measure productivity, and maybe not even use that word as much and instead have more focused goals. And as an industry focus on what are the things or the practices or the approaches or the interventions or values that we can use to improve developer experience. And in terms improve the product performance measures and improve the velocity of the engineering process.

Abi: That’s really interesting. I’m curious, maybe a similar question, but what are… And you touched on this earlier, what are the roadblocks with applying the SPACE framework in terms of the example metrics? Where are you seeing… I’m sure companies are coming to you asking, “Which metrics should we use,” and they’re trying stuff. Where are you seeing the SPACE framework, maybe fall short in being the answer?

Peggy: I think that it’s still quite broad in its goals. And it falls short because… But this is something we did talk about when we were writing the paper about there’s this model called goals, questions, metrics, where you need to start with a goal and then you come with questions and then those lead to the metrics. And I think we even wrote some of the stuff along the way. And then we took it out to try to keep the paper a little bit more succinct.

But I think SPACE, it isn’t enough by itself. There really have, has to be a lot of attention placed on understanding, what are your goals? In terms of whether it’s understanding whether it’s improving or changing or whether it’s even measuring, if you are measuring, why are you measuring and what do you hope to get with that? And so it’s not enough. It’s a start.

It’s definitely a lot better than using lines of code or even a simple survey, but it’s not enough to help in narrowing down what are those goals? And I gave a talk yesterday for Never Work in Theory. And one of the three kind of high level goals that I was thinking about was one in terms of the product, right? What is the quality of the product? I have another paper that talks about quality.

Quality is also something that people don’t agree on. And it’s also very complex. It’s not even that easy to measure that because there are many dimensions to quality, but that’s one of the three. And then the second one is engineering velocity. That’s what DORA kind of looks at. The process, understanding how the tools, understanding the throughput of what people are working on.

And then the third piece to me is the experience of the developer or satisfaction. I’d prefer the term experience to satisfaction because experience captures more about the motivation for the developers, as well as their cognitive and their effective. Their feelings say about their work.

Abi: You’ve touched on the term experience a couple times, can you give some concrete examples of what you mean by experience?

Peggy: So yeah, you were asking me what is next. And I’m going to go back to that, and then I’ll talk about experience. Now, in terms of what’s next, as engineers, as computer scientists, as developers, a lot of what we do has… It involves people and there are a lot of theories, I think from psychology and social science that we need to bring into our discipline and from the management sciences as well, to bring into our discipline, to making those changes.

And one of those theories about experience. Now, by experience, I don’t mean how skilled you are or how long you’ve been working. I mean, how you think about how you feel about your work and what you value. And there’s a theory called The Trilogy of Mind that captures that and looks at these three aspects of our experience when we’re living or when we’re working, and breaks those down into… Identifies what are some of the factors that influence those three aspects.

But these three aspects, how I think about, how I feel about, and what I value, they can’t be separated. We can’t just say lets just improve that and not improve the others. They’re intricately connected. So that’s what I mean by experience. And I’m not sure if you’re sharing links with this podcast, but I think we could share a link to the paper that we did with McKayla. McKayla Grailer led this paper together with you and myself, where we identified the important factors for developer experience, that impact developer experience.

And one of the kind of concluding quotes from that paper that I absolutely love that McKayla pulled out was being empowered to do my best work joyfully. And that quote kind of captures those three aspects of experience. So if you aim as a practitioner to empower your developers and your engineers to do their best work and to do it joyfully, you’re there, right? You’re going to make it in my opinion. Yeah.

Abi: That’s a great quote and great description. I’m curious for people listening who are really fascinated by the research in this SPACE, what else should they be looking at? Who are there other researchers or is there stuff coming up that people should stay on the lookout for? What would you direct people toward?

Peggy: Well, I’m going to post my slides from yesterday, from the talk that I gave at Never Work in Theory. And I can share those with you too, because I have a list of references in there to other people’s work, as well as some of the work that I’ve done. There’s definitely a lot out there that brings those insights, delving a bit into behavior change, theories and theories that affect people’s motivation, as well as their job satisfaction.

I think all of those things kind of help open your eyes a little bit to what is important. I can give a little example actually from some work that I’m doing with my postdoc right now. So we’re looking at security or how to motivate developers to write more secure code. And so we’re working with a psychologist and we’re using something called the behavior change model to understand what kinds of things will motivate them and capabilities and what opportunities they need to actually go and write more secure code.

And this is a challenge. And one of the insights that I was thinking about, getting your engineers to write more secure code can be tricky because a lot of engineers… And we found this when we asked developers, “What makes you feel productive?” It’s shipping features. A lot of them say, “Shipping features or meeting my sprint goals.” But the leaders are like, “Well, wait a minute, we have to write secure code,” but that slows them down.

And so how do we motivate them to do that? So some companies might say, “Well, we’re just going to mandate it. We’re going to punish them if they don’t do this.” But the theories from psychology show us that well, if you control people, and you bring even external motivators, you actually reduce and lower their internal motivation to write more secure code.

And it’s better to internally motivate developers to write more secure code or higher quality code than to control them and take away their autonomy, or even to give them a pay rise if they do it. That actually also reduces their internal motivation. So understanding those nuances and understanding that, I think, brings a lot of that. Can bring a lot of value.

Abi: That’s really interesting. So where is your research then, you personally, what are you focused on then? What are your goals in research for the next year or two years to come?

Peggy: We’ve been looking at this security SPACE and trying to understand that. Actually we’re going to be submitting a paper soon on that. So maybe I’ll put that online. I’m very interested going forward, looking at the impact of more automation and AI is being used everywhere, in software development, I’m interested on the impact of that. A lot of it is perhaps making developers write their lines of code more quickly, but does that make them feel more satisfied with their work?

Maybe it reduces the challenge, and that was the part that they actually kind of liked. How does it impact their understanding of the code and the quality of their code? How does using automation impact how other developers collaborate and talk with each other? So my work is continuing to kind of understand that space between, I guess, the social and the technical aspects of software engineering.

Abi: That’s really exciting. Well, I’m sure we’ll all be following that research. We’re done for the day, so thank you so much, Peggy, for coming on, and listeners for joining in as well. Just to wrap up, we wanted to let everyone know we’ll be doing another research session with Dr. Duncan Brumby and that’ll be about managing interruptions on engineering teams. So we look forward to that. Thanks so much again, Peggy, for coming on.

Peggy: Thanks, Abi.