Applying the SPACE Framework

A guest post from Laura Tacho on why the SPACE framework can be difficult to understand, and how to apply it.

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

---

Laura Tacho, CTO at DX, and I held a discussion yesterday on the DORA, SPACE, and DevEx frameworks, including their differences and how they can be applied. It was a fun conversation, and it was great to hear from the audience about how different teams are measuring developer productivity today. (If you missed it, 70% of respondents are using some type of metrics, whether from DORA, SPACE, DevEx, or something else. 30% are not measuring productivity.) 

Laura also wrote a guide on DORA, SPACE, and DevEx, which goes into greater depth about how each framework should be used and how to collect metrics. In today’s newsletter, I’m sharing an excerpt from her guide which focuses on the SPACE framework.  

SPACE is particularly interesting because there’s still a lot of confusion around the framework and how it can be used. Here, Laura gives a clear explanation on SPACE and who it’s most useful for.

---

The SPACE Framework of Developer Productivity

The SPACE Framework of Developer Productivity is a holistic approach to thinking about and measuring software developer productivity. Unlike DORA, the SPACE framework is not a list of metrics or benchmarks. Instead, it outlines five different dimensions of productivity that can inform your own definition of productivity, and by extension, your measurements.

The five SPACE framework dimensions are

• Satisfaction and Well-being: How satisfied developers are with their work and working conditions, and how healthy and happy they are.

• Performance: How well the software fulfills its intended purpose, both from a quality perspective, but also in terms of user impact.

• Activity: A count of the actions within a system, such as number of tests, builds, and design documents produced by a team of developers.

• Communication and Collaboration: How well your team members communicate with each other and work together.

• Efficiency and Flow: The ability of your team to complete work with minimal interruptions and make continuous progress.

Not only does SPACE emphasize the importance of all five categories, it goes further to explain that both workflow metrics (like those used in DORA) as well as perception metrics, like how productive a developer feels, are equally as important when defining and measuring developer productivity. 

Who should use the SPACE framework?

SPACE is a broad framework that gives developers and engineering organizational leaders new vocabulary and mental models to define developer productivity. 

SPACE is a great choice for:

• Software organization leaders who are developing a definition of developer productivity for their organization

• Teams and leaders who want to make sure there are no gaps in their productivity measurements

• Leaders who are looking for a better way to get their team involved in measuring and improving developer productivity

• Teams looking for better ways to discuss their experiences when it comes to productivity

SPACE may not be as useful on teams where developers and leaders are not in a position to improve productivity through interventions, or for leaders who are hesitant to adopt new ways of thinking about productivity. 

How do you implement SPACE?

Since SPACE is a broad framework, all metrics related to developer productivity – even the “bad” ones – fit into SPACE. Additionally, because SPACE introduces other dimensions to consider, such as workflow vs. perception metrics, it can be confusing to understand how to implement SPACE on a practical level. 

“SPACE metrics” simply don’t exist, and it’s a misconception to think that it’s possible to swap out DORA metrics and use SPACE metrics instead. SPACE is a framework that does not come with a punch list of things to measure. Instead, SPACE provides guardrails and mental models when crafting your organization's definition of productivity, ensuring that you don’t overlook an important aspect of productivity and pay the price later by damaging culture or leading to burnout.

Using SPACE to challenge assumptions about productivity and uncover gaps in your teams’ thinking is a great way to get started with SPACE on your teams. An exercise to do this is to use an online whiteboard tool and have your team members create a sticky note for each measurement of productivity. Then, drag each measure into the corresponding SPACE category. 

In the case of the team below, this helped them see that they did not naturally view measurements of Satisfaction and Well-Being or Communication and Collaboration as part of their own definition of productivity. Many teams will discover the same, as the S and C categories are often absent in definitions of developer productivity. This is an area of strength for SPACE:

• If you work through an intense crunch time to ship something, but many of your team members experience burnout, was that period productive?

• If you complete a large project but do not take the time to document functionality, leading to delays in all subsequent projects due to lack of documentation, was that productive?

Another way to begin using SPACE is to introduce self-perception metrics as a way to measure developer productivity. Taking a closer look at the metrics from the team exercise above, we notice that all of the metrics can be collected from developer tools. The voice and experience of the developer, which SPACE data shows is equally important, is absent. 

If this is the case with your team, don’t worry – it’s normal. Often, engineering leaders and developers have a tendency to value automatically collected metrics more than self-reported metrics, and more than measurements of perception, like “how satisfied are you with our code review process?” 

But workflow measurements only tell part of the story. Take for example two teams that both have an average code review time of 12 hours. For one team, this is sufficiently fast, and does not delay work in a meaningful way. For the other team, it feels like swimming through mud, and the perception is that code review timing is a huge bottleneck. We can’t see this when only looking at the numbers, which is why SPACE advocates for including both measurements of perception alongside workflow measurements.

What’s important to consider about the SPACE framework?

SPACE is a holistic and comprehensive way to think about developer productivity. It advocates for balance in multiple ways:

• Include varied types of metrics based on their alignment with the five SPACE dimensions

• Include a balance of workflow metrics as well as perception metrics, as both are important

Because SPACE is a framework, it is still up to you to define productivity, and then select metrics that align to your definition. SPACE is a useful tool to reduce the likelihood of omitting important dimensions of productivity based on the latest research. 

Practice caution here. Just because a metric falls within a SPACE category does not mean it is a “good” metric or that it will not cause cultural damage when introduced.

It might be the case that there is hesitancy to adopt new ways of thinking about productivity outlined in SPACE, particularly for organizations and leaders that have experience with DORA metrics. DORA is very concrete, whereas SPACE is very abstract, and focuses equally on developers’ experiences as it does on metrics from tools. This might feel “squishy” to leaders who have developed a taste for quantitative metrics. An important consideration to keep in mind when advocating for SPACE is that Dr. Nicole Forsgren, the lead researcher for DORA metrics, is also the lead researcher for the SPACE framework. Though they measure different things – DORA focusing on software delivery performance and SPACE focusing on developer productivity – the research informing both frameworks is equally as rigorous.

One drawback of SPACE is that it can be difficult to understand because it is so vast. It’s not necessary for all developers in your organization to understand SPACE even if you are introducing a collection of metrics that were developed using principles from SPACE, so don’t view organization-wide understanding of SPACE as a limiting factor to your progress. 

Read the full guide from Laura for a deep-dive on DORA, SPACE, and DevEx.

---

Thanks for reading. If you know someone who might like this issue, consider sharing it with them:

-Abi