We’ve helped hundreds of organizations build a more complete picture of development productivity. This guide on the SPACE framework of developer productivity explains the framework, what we’ve learned along the way, and how to get started with SPACE in your organization.
What is the SPACE framework?
SPACE is a framework for developer productivity. It combines much of the latest research on development productivity under a single framework.
Nicole Forsgren, a member of the DORA team and a co-author of the book Accelerate, led the SPACE framework study. SPACE goes beyond the specific metrics included in DORA and gives a more complete and nuanced picture of developer productivity.
SPACE lists the five most important dimensions of developer productivity (Satisfaction & Well-being, Performance, Activity, Communication & Collaboration, Efficiency & Flow) at three different organizational levels (individual, team, and system).
Why you should use the SPACE framework?
The SPACE framework aims to overcome the flaws of earlier attempts of measuring developer productivity. These "myths and misconceptions about developer productivity" include:
- Productivity is all about developer activity.
- Productivity is only about individual performance.
- One productivity metric can tell us everything.
- Productivity measures are useful only for managers.
- Productivity is only about engineering systems and developer tools.
To counteract these myths, the SPACE framework "provides a way to think rationally about productivity in a much bigger space" that is informed by a wide range of research on developer productivity.
SPACE framework dimensions of developer productivity
Satisfaction and 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.”
Studies show that productivity and satisfaction are correlated. Measuring satisfaction and well-being can help you understand productivity and may act as a leading indicator of burnout and reduced productivity.
Satisfaction and well-being can often be best measured with surveys.
Example metrics:
- Employee satisfaction (eNPS and team health checks)
- Investment balance (amount of KTLO)
- Burnout and engagement
Performance
“Performance is the outcome of a system or process.”
Software engineering performance can be hard to quantify. Connecting individual work to business outcomes is often difficult. Producing more code faster may not lead to more high-quality code. High-quality code may not deliver customer value. Features that customers love don’t always create positive business outcomes.
Because of these challenges, software engineering performance is best evaluated as outcomes instead of outputs.
Example metrics:
- Change failure rate (DORA)
- Investment balance (the amount of building new stuff)
- Customer satisfaction (NPS)
- Reliability
Activity
“Activity is a count of actions or outputs completed in the course of performing work.” These include outputs like design documents and actions like incident mitigation.
Developer activity can provide valuable but limited insights about developer productivity if measured correctly. In practice, developer activity is impossible to measure comprehensively, because many developer activities are intractable (e.g. attending team meetings and helping other team members).
Therefore, you should never use activity metrics in isolation and always balance them with metrics from other dimensions.
Example metrics:
- Issues completed
- Pull requests reviewed and merged
- Deployment frequency (DORA)
Communication and collaboration
“Communication and collaboration capture how people and teams communicate and work together.”
Software development requires extensive and effective communication and collaboration between individuals and teams. Effective teams rely on high transparency and awareness of other people’s work and make sure everyone has access to the necessary information.
Good communication and collaboration improve the team- and system-level productivity but are often in tension with individual productivity. Helping others can limit an individual developer’s ability to get into a state of flow, which may reduce motivation and satisfaction.
Measuring communication and collaboration directly is complex as it includes a lot of invisible work. The example metrics below can be used as proxies to measure communication and collaboration.
Example metrics:
- The number of people working on the same features
- Team health checks (silos and communication)
- Pull request review time
Efficiency and flow
“Efficiency and flow capture the ability to complete work or make progress on it with minimal interruptions or delays, whether individually or through a system.”
For individual developers, this dimension of productivity is echoed when talking about “getting into the flow.” At the team- and system-level, efficiency is related to the steps needed to take an idea from start to the end customer.
The systemic effects of improving efficiency and flow often significantly impact your engineering productivity. Outside of SPACE, this dimension is discussed in detail in the ground-breaking book Principles of Product Development Flow by Donald G. Reinertsen.
You can measure efficiency and flow through a combination of metrics collected from the software development flow (e.g. DORA change lead time) and survey data.
Example metrics:
- Team health checks (silos and communication)
- Perceived ability to stay in flow and complete work
- Investment balance (the amount of productivity-related work)
- Change lead time and time to recovery (DORA)
- Story/issue cycle time
SPACE framework organizational levels
For a fuller picture of what is happening in your organization, the SPACE framework suggests that you select separate metrics for each of these three organizational levels:
- Individual
- Team or group: People who work together.
- System: End-to-end work through a system, e.g., the development pipeline of your organization from design to production.
Best practices for using the SPACE framework
We’ve helped hundreds of companies start and succeed in their efforts to build a more complete picture of development productivity. These are the best practices we’ve learned along the way.
1. Include metrics from at least three dimensions
To genuinely understand development productivity, you should use several metrics across multiple dimensions of the framework. The recommended minimum is three dimensions.
When selecting what metrics to include, less is more. Having too many metrics will make using the framework overly complex. Don’t try to squeeze everything in. Rather, start with a set of proven metrics that support your engineering organization’s priorities.
For modern software organizations, DORA metrics, issue cycle time, investment balance, and team health checks form a great set of core metrics. These all have a proven link to an engineering organization’s ability to deliver good business outcomes.
2. Start from team-level metrics
Out of the three organizational levels in the SPACE framework, the team level is often the easiest to get started with. It’s also the level, where you are likely to get the most useful insights and least likely to cause negative incentives or harm company culture.
Starting from the team level allows you also better optimize the metrics you use in each team. Productivity is very context-dependent. Especially in larger companies, different things matter for different teams and systems.
3. Invest in getting your engineers on board
Developers are often wary of all kinds of software engineering metrics. The resulting pushback may lead to managers trying to ignore the engineers and move forward without them.
In our experience, though, attempts that don’t include individual engineers fail. Engineers create the data in the systems that you’re trying to observe and will game the metrics if they don’t want to use them.
Also, asking people about their experiences creates a more accurate picture of productivity than data gathered from system behavior alone. If people don’t want to share their experiences honestly, you’ll lose crucial parts of the insights you need to succeed.
To get individual engineers on board, make sure the tools you use benefit individual developers and get them excited about improving the ways they work.
4. Go beyond aggregates to detect patterns and reduce bias
Relying solely on high-level metrics can quickly lead to making unwarranted conclusions and makes it impossible to spot possible bias. Make sure you’re able to drill down to individual items to investigate what’s causing a change in the metrics.
For example, when aggregating a year’s worth of data, one team member’s parental leave can show up as poor performance for the whole team.
How to implement the SPACE framework in your organization?
These steps will help you implement the SPACE framework in your organization without getting overwhelmed.
1. Start with the why
For most organizations, introducing the SPACE framework is a major cultural change. As with all changes, people will have questions and fears. You should communicate openly why the SPACE framework is important and proactively address the objections people may have.
When communicating the why, your main goal is to get everyone to agree that continuous improvement is important. Continuous improvement requires participation — and work — from everyone in the organization. If your leaders and teams don’t value continuous improvement, you’re unlikely to succeed.
Secondly, you should communicate that the goal of the SPACE framework is to benefit everyone in the organization. Not to stalk developers. Measuring development productivity correctly and applying the results improves product quality, engineering velocity, and developer experience.
2. Get easy wins and share success stories
Trying to roll out the SPACE framework to your whole organization immediately will diminish your chances of success. Instead, start with a few of the most motivated teams. This will allow you to get some easy wins and gain momentum.
Your goal is to show that implementing the SPACE framework is not too cumbersome and that individual teams can use it to get real results. The easiest way to get started is to use a tool like Swarmia, which includes a number of well-researched metrics that map into the different dimensions of the SPACE framework.
While you’re making progress and getting results, share any success stories with the wider organization to build momentum and get more people interested in measuring development productivity.
3. Roll out SPACE to the wider organization
Once you have a few teams happily using the SPACE framework, you can start thinking about rolling it out for the rest of the teams. If you’ve succeeded with the SPACE framework and the teams have found it an integral part of their continuous improvement journey, you should have multiple advocates excited to convince their peers.
In the beginning, continue rolling out the SPACE framework team-by-team to multiple systems in your organization. We’ve found that team lead and individual team onboarding sessions are a good way to educate people on the benefits of measuring software engineering productivity and address any concerns or questions that people may have.
When rolling out the SPACE framework, make sure that teams also incorporate it into their day-to-day working practices. The insights SPACE provides are useful in recurring meetings and ceremonies, such as one-to-ones, retrospectives, and feature prioritization discussions. This ensures that continuous improvement through metrics becomes a part of your culture — not a one-and-done project.
SPACE framework example template
This filled out template includes carefully selected metrics based on the latest research. These metrics fit most modern software engineering organizations and are our recommended starting point for implementing the SPACE framework.
If you’re using Swarmia, the example template shows how the metrics in Swarmia are related to the SPACE framework and suggests metrics you can collect from other systems.
Conclusion
Implementing the SPACE framework will allow you to build a more complete picture of developer productivity in your organization. Having the right insights will allow your teams and the whole organization to improve the ways they work, be more satisfied, and create better business outcomes.
You’ll likely go through multiple iterations of your SPACE framework implementation, which is OK. Get started with something simple today and keep improving it.
