The SPACE of Developer Productivity

A new lens for viewing productivity, why productivity can’t be reduced to “activity”, and the case for measuring productivity through perception.

Jun 24, 2022

This is the latest issue of my newsletter. Each week I cover the latest research and perspectives on developer productivity.

This week I read The SPACE of Developer Productivity which was published by a team of researchers from Microsoft. (Authors: Nicole Forsgren, Margaret-Anne Storey, Chandra Madilla, Thomas Zimmerman, Brian Houck, and Jenna Butler.)

Note: I recently hosted a fireside chat with Dr. Margaret-Anne Storey (who goes by Peggy), one of the paper’s authors. You can listen to the full discussion here.

My summary of the paper

About SPACE

SPACE was written to provide a better understanding of what developer productivity is, as well as share ideas for how teams can start measuring it. The two core parts of the paper were 1) the five categories and “the myths” (answering the question, “what is developer productivity?”), and 2) the metrics (“how do we measure?”).

How SPACE is different

There’s a lot to this paper, but here’s specifically what made it unique:

The paper claims that productivity can’t be reduced to just “activity”. The authors take a stance against the approach of measuring productivity by measuring individual or team outputs. It’s something most managers inherently know — that a “productive” day can’t just be measured by the visible outputs of that day — but here, the authors gave weight to that idea. The authors also gave weight to the idea that satisfaction and productivity are correlated. “Measuring satisfaction and well-being can be beneficial in understanding productivity and perhaps even for predicting it.”
It claims that personal perception matters. The third paragraph of the paper reads, “one important measure of productivity is personal perception”. This means we have to look at whether a developer feels productive and whether they perceive a process or tool to be effective.
It introduces a new lens for viewing productivity. Whereas the DORA metrics look at org-level metrics, SPACE looks at individual-level productivity.

What is developer productivity?

The SPACE framework presents five categories important to consider when measuring productivity. They assert that by using a multidimensional framework, we can more accurately measure productivity. The five categories they presented were:

S – Satisfaction & Well Being - Satisfaction is how fulfilled developers feel with their work, team, tools, or culture; well-being is how healthy and happy they are, and how their work impacts it.

P – Performance - the outcome of a system or process. (“Performance is best evaluated as outcomes instead of output.”)

A – Activity - the count of actions or outputs completed in the course of performing work. (“Developer activity, if measured correctly, can provide valuable but limited insights about developer productivity…”)

C – Collaboration & Communication - how people and teams communicate and work together. (Proxy metrics include discoverability of documentation, how quickly work is integrated, quality of reviews of work contributed by team members, etc)

E – Efficiency & Flow - the ability to complete work or make progress on it with minimal interruptions or delays, whether individually or through a system. (Example metrics include the number of handoffs in a process, perceived ability to stay in flow, interruptions.)

The authors also emphasize that no single measure can be taken alone to draw conclusions about productivity. Teams and organizations should leverage at least three of the categories to gain deeper insight into how teams are working.

The metrics

The focus of the paper was to change how people think and talk about productivity — in Peggy’s words, “We wanted to respond to how the industry was thinking about productivity, which was very narrow”. (This is apparent in the title of the paper: “there’s more to [productivity] than you think”.)

To help teams start measuring the different dimensions of productivity, the researchers shared example metrics that teams could consider:

When Accelerate published DORA’s four metrics, it was the first scientific study on what makes a high-performing software delivery organization. The metrics in that study swept through the industry, and today most teams use them or have used them. So it’s no surprise we’re seeing a similar trend with SPACE where many teams are starting to apply the metrics introduced in the paper.

If your team is looking at applying the SPACE framework metrics, one note of caution: Peggy said “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.” She emphasized the importance of starting with an understanding of why you’re measuring productivity in the first place before deciding which ones to use.

The question “why measure productivity in the first place?” isn’t always very clear, which is why we need to define what our goal with metrics is first. Usually the answer boils down to one of these three:

either a team wants to understand what’s going on, or
they want to improve, or
they want reporting.

Each of these reasons will lead towards choosing different metrics.

Shortcomings of SPACE

SPACE advances the way we think about measuring productivity by sharing a multidimensional framework. (It’s a lot better than measuring lines of code, or by looking at activity metrics alone.)
However, the paper falls short of encouraging teams to start by understanding the goals of measuring before choosing metrics. (Peggy did this in our discussion, but it’s not covered in the paper.)
The metrics in SPACE give signals of productivity, but don’t help teams understand why things are happening or how to improve. Teams still have to do the work of digging in and asking questions to understand why something may be happening.

Engineering Enablement

Discussion about this post