Thank you Greg and Mike for arranging this amazing talk series.
A lot of the things I'm going to touch on during the next 10 minutes have already been mentioned in some of the earlier talks and I wish that I had more time to maybe create more links to the to the earlier insights that were shared, but in the next about nine to ten minutes I'm going to discuss why developer productivity is more complicated than we may think and why measuring productivity may be counterproductive, and I'm also going to try to convince you that we should focus and pay more attention on improving and understanding developer experience, something we've heard about a few times today already, and why doing so may improve the space of productivity overall.
But first let's talk about productivity.
So if you want to turn a boring meeting with software developers and their managers into an exciting one just bring up the concept of developer productivity and suggest how it should be measured.
And you'll find that the people in the room have very different views of what productivity means to them and how productivity should be measured, if at all.
And we may also hear that - in those meetings that software company leaders and managers care about productivity because they assume that if they have higher developer productivity that will help them deliver value to their customers more quickly.
And developers care about productivity because having impact and feeling their work brings value will make them happier.
But what does developer productivity really mean to managers and developers?
Well it so happens that together with my colleagues Brian and Tom from Microsoft we asked managers and developers how they define productivity through an open-ended survey.
And we heard many varied definitions.
In fact managers were more likely to talk about productivity in terms of performance outcomes but many of these managers also gave us rich definitions of productivity that were not just about keeping their customers happy but also included the well-being of their developers and building a positive work culture.
From developers we also heard very varied definitions, but they - compared with their managers were more likely to define productivity in terms of activity outputs and the time they can spend doing their work without interruptions and in a state of flow.
But many developers also shared that productivity was not just about activity and flow but was also about the impact of their work - helping others and learning for the future.
So defining productivity is important but leaders - and I would say even some developers - want to be able to measure productivity so that they can understand the impact changes in tools, processes, and goals may have.
And we saw this of course especially during the past two years of work from home and the recent call for hybrid work.
And in fact early attempts to understand productivity in terms of telemetry data such as number of pull requests and even through surveying developers gave us the early impression that productivity had potentially improved or stayed the same.
But of course it wasn't quite that simple.
So as we and others discovered when we surveyed developers in the first few months of the pandemic many reported higher perceived productivity but at the cost of potential burnout, while others were struggling to work at all.
And we also learned that teamwork was more challenging and that interruptions and in fact the nature of these interruptions had increased.
But how to make sense of all of this research?
So there were a bunch of us studying productivity during the pandemic and we recognized that we needed a better way to frame developer productivity.
So building on years of research, not just the research we did, we developed the SPACE framework that synthesizes the main five dimensions of productivity that we saw emerging from the various studies of developer productivity.
And SPACE helps us articulate that developer productivity doesn't just come down to speed or output and that there are many different aspects of productivity that we need to consider.
Let me talk about these five dimensions a little bit in more detail.
The first dimension satisfaction and well-being, looks at how fulfilled and happy developers are.
Our earlier research shows that satisfaction and perceived productivity, although not quite the same, they are correlated, and it's crucial to look at how developers feel in order to get a holistic understanding of their productivity.
This is something that is often measured through surveys to gain the subjective data.
The next dimension of the SPACE framework is performance.
This refers to the outcomes of a system or process, and it is the aspect of productivity that many leaders care about the most.
And you might think well evaluating performance is easy, but actually even though there are some objective measures there are very many variables that we need to consider.
So for example a lot of code doesn't necessarily mean it's high quality, and high quality code doesn't necessarily mean happy customers, and even happy customers doesn't necessarily mean more revenue for a company.
The third dimension we added to SPACE is activity and outputs.
Of course this is an important metric to look at and it's one developers may often think about first, but as we've been alluding to so far in this talk it's not the be-all and end-all of productivity.
And in fact the activities developers perform are also complex and diverse, and we may be able to measure some, so for example pull requests or number of code reviews, but other activities, such as attending meetings, are helping other developers that are onboarding or learning for the future.
These things are hard to put into into numbers.
The next dimension in SPACE is about communication and collaboration, something we've heard a lot about today as well.
This dimension emphasizes that software development is a team activity and an inherently creative and collaborative process.
And then the final dimension that we added to the SPACE framework is about efficiency and flow.
Efficiency and flow is the ability to work without interruption.
These are topics that have been studied extensively in our research community over the past few years years, and this dimension captures the importance of flow for individual developers and the negative impact interruptions may have on their work.
But this dimension also captures how well teams are orchestrating their different activities and how often they're making continuous progress.
So SPACE gives us a much richer and a more nuanced way to think about productivity but can it help us measure productivity, something leaders as I mentioned in particular care about.
Fortunately these days it is now recognized that there is no universal metric for measuring productivity, and SPACE can help us and plays a role here in helping us choose at least several metrics from different dimensions of productivity, and actually our paper describes this in a bit more detail.
But we're not done: choosing these metrics is still challenging and I believe that we need to do a lot more to understand how to measure different aspects of productivity or otherwise we run the risk of being counterproductive.
This is especially important to be cautious about because, well, let's face it, engineers have been trained and conditioned to consider objective data and metrics that are easier to quantify before considering qualitative and subjective data, so before choosing metrics we need to first pause, take a step back, and focus on what are the goals, that is, are we trying to measure productivity in terms of improving the quality of the product, or are we trying to improve quality productivity in terms of the velocity of our engineering process and being able to continuously deliver code, or are we looking at the experience of the developer or perhaps it's all three.
Now for product quality and process quality we do already have some well-defined objective and validated quantitative metrics for these, but as I mentioned earlier, even these - measuring these is not simple, and they need to be - we need to carefully consider the context of the project and the developers before choosing these metrics.
The third one here, developer experience, in contrast relies much more on subjective metrics which can be harder to measure, but I'm proposing today that it is critical that we understand and improve developer experience, because we know from previous research that improving developer experience will lead to improvements in product quality and process velocity and vice versa.
But what do I mean when I say developer experience, you may wonder.
It is also complicated.
From a study I recently did with my colleagues Michaela and Abi, we define developer experience as how developers think about, feel about, and value their work.
And in this study we conducted in-depth interviews with 21 developers from across the industry to understand which factors have the most impact on their experience.
And we learned about key six factors - six key categories of factors: developer flow and fulfillment, how they collaborate with others and their culture at work, how their team and their product is managed, and the quality of the tools and the engineering processes they use.
But we also found that the impact these different factors have really depends on their specific context of the project and on their work.
And these factors can help us pick specific goals and in turn metrics that can improve developer experience and in turn developer productivity overall.
So in closing here are my main takeaways.
Productivity is more complicated than we think.
It means different things to different people and there is no universal productivity metric or even a universal set of metrics.
Space can help us select some metrics but first we need to clearly articulate our goals before selecting any.
And lastly we need I suggest that as an industry we need to place a lot more focus on understanding and improving developer experience, as doing so will lead to improvements in product quality and engineering velocity, all important goals within the space of productivity.
So thank you and I hope that you some of you might reach out to me by email or twitter if you have questions or thoughts to share and I would love to hear from you.