Measuring developer productivity can be challenging. You’re under pressure from other execs to make the most out of your existing teams, but you can’t just conjure productivity out of nowhere. Conventional metrics place too much emphasis on output, which isn’t always the most effective approach in software development. And you can’t just have developers email you weekly updates, Elon.
Quantity is essential, but if you only focus on quantity metrics, teams might be prone to overlooking quality. You need teams to maintain tempo without throwing developer experience and business objectives under the bus. Leaning too far into speed can quickly drive your teams to crash and burn.
To avoid this fiasco, you need a more comprehensive way to analyze and improve developer productivity. Enter the SPACE framework, which gives you a more holistic understanding of productivity — beyond just output-based metrics. And this framework can make your engineering org’s performance skyrocket (pun intended).
Table of Contents
- What Is the SPACE Framework?
- Why Does the SPACE Framework Matter?
- How to Implement the SPACE Framework
What Is the SPACE Framework?
Developed by Nicole Forsgren, Microsoft Research, and the DORA team, SPACE is a framework for measuring and analyzing developer and team productivity to ensure consistent, high-quality software delivery. It approaches developer productivity holistically, combining performance and work patterns with well being, and aligning that with outputs and business value.
SPACE is a framework for measuring and analyzing developer and team productivity to ensure consistent, high-quality software delivery.
The SPACE framework provides a way for you to view productivity across all of your teams. It allows you to choose metrics that can help improve productivity and even eliminate the limitations of using metrics incorrectly. The SPACE framework uses five dimensions to measure developer productivity:
- Satisfaction & Well-Being
- Performance
- Activity
- Communication & Collaboration
- Efficiency & Flow
Each one is important in its own right, but you can’t rely on just one to track how productive your dev teams are. And that’s the beauty of the SPACE productivity framework — you can’t have a universe with just one star. So let’s dive into each of these dimensions and show you what they really mean.
1. Satisfaction and Well-Being
Job satisfaction is one of the crucial factors that influence developer productivity. When employees feel motivated and fulfilled in their work, they produce better results than when they’re unhappy and disengaged.
Let’s take the recent shift to remote work, for example. For some devs, remote and hybrid working was an absolute blast. But for others, it was pure hell, and some quickly grew to feel isolated. So if you balance satisfaction with well-being, you can ensure your dev teams are happy and healthy, physically and mentally.
Satisfaction and Well-Being Metrics
| WIP | Merge Frequency | Burnout |
| Shows you all branches currently in progress. Helps team leads assess whether devs are spread too thin or need help balancing priorities. | Measures how often code is being merged. Can indicate an absence of bottlenecks and a healthy software delivery pipeline — so it helps identify whether devs are frustrated with stuck code. | Tracks whether devs have worked 90% of the days in a sprint (monitoring for burnout starts at 6 days into the sprint). Helps indicate potential fatigue, and can show you if a dev is due for some perspective and distance before diving back into a sprint. |
2. Performance
Performance measures the output of a team’s systems and workflows and determines how they operate. Measuring performance allows managers to see their engineering org’s output — and compare it to the outcomes. And from there, the managers can adjust as needed to achieve better productivity.
Want a glimpse into how Netflix approaches outcome vs. output? We had a chance to get Kathryn Koehler, the Director of Productivity, on our podcast!
Performance Metrics
| Change Failure Rates (CFR) | Investment Profile | Planning Accuracy |
| Measures how many of your deployments lead to failure. Can indicate stability and quality in your code and SDLC. Lower CFR indicates higher performance, because it shows you’ve reduced the time spent dealing with failures and upped the delivery of features and value to customers. | Breaks down the work provided by issue type. Shows you and your team leaders whether the effort is going to tasks that truly matter to the business. Can allow you to prove to other execs — with hard data — why you can’t prioritize a new project. | Shows you the ratio of completed story points versus how many were planned. Helps you see what’s going on in your sprints, like unplanned and carryover work. So it enables your engineering managers to deal with technical debt and scope creep. Allows you to deliver on your promises more often than not — so the higher ups will be happy with your org’s performance. |
LinearB’s Project Delivery Tracker helps you correlate your investment profile and planning accuracy breakdown to see why project delivery is impacted.
3. Activity
This dimension is based on the actions (or outputs) completed while your teams are working. Oftentimes, this is difficult to measure, as your developer teams are often performing work that is difficult to quantify. But relying on activity metrics is an inaccurate way to gauge productivity (though it’s quite common in the industry).
One of the most common ways we see this dimension in day-to-day operations is through developer velocity. Having your developer teams working quickly does typically result in high activity levels — but going fast means code quality drops. And that’s a prime example of why you shouldn’t, under any circumstance, prioritize only one of the SPACE framework dimensions.
Activity Metrics
| Deployment Frequency | Story Points Completed |
| Shows you how often teams push code to production. Enables you to measure how quickly teams are churning out fixes or new features. Isn’t good enough if you have a higher deployment frequency but you aren’t working on things that align with business needs. | Shows you how active teams are with their number of completed story points. Needs more context — like planning accuracy — to truly show you whether their work is helping deliver on promises to the business. |
4. Communication and Collaboration
This dimension focuses on how well and regularly your teams work together, which is an often-ignored aspect of productivity. When you have a firm grasp on how your teams collaborate, you’ll be more equipped to assess how changes in cooperation and communication might affect output quality.
All humans are social creatures, even your devs. If you open up a channel for communication and ideas, they’ll sharpen their problem-solving ability as a team, not as individuals. Open communication elevates everyone, it’s that simple. Devs who work together will be able to produce higher quality products, and hone their skills to maintain this quality.
Communication and Collaboration Metrics
| Cycle Time | PR Pickup Time | PR Review Depth |
| Indicates bottlenecks within the PR review process. Shows you whether PRs are sitting idle for a long time and increasing cognitive load, developer toil, frustration, and negatively impacting quality and efficiency. Improved cycle times can improve overall communication among dev teams. | Measures how long a pull request waits to be reviewed. Can show you whether devs are struggling to be productive and get back into a task after waiting for a PR to be picked up. Shorter PR pickup times boost collaboration because it puts devs in a better mindset during reviews. | Gives you insight into the quality and thoroughness of reviews. Can show you whether communication is lost if reviewers are swamped with other tasks, so they only leave thumbs-up emojis as feedback. Good, thorough code reviews can elevate how your devs write and share code and ideas, as they can bounce ideas off each other and coach when needed. |
5. Efficiency and Flow
Finally, efficiency and flow illustrate whether your teams are progressing with or without delays and interruptions. With these metrics, everyone involved in a project always knows how things are coming along. This helps your team leaders keep everyone on the same page regarding deadlines and allows them to evaluate how well their team completes tasks.
The goal here should be to strike a balance between an individual’s needs and those of the group. For example, while avoiding disruptions by declining or postponing meetings may boost productivity for an individual, it may cause bottlenecks for the group later on while they wait for code reviews. Measuring efficiency and flow helps your team leaders pinpoint and eliminate software delivery bottlenecks.
Efficiency and Flow Metrics
| Cycle Time | Merge Frequency |
| Can help you see which areas are causing inefficiencies and disrupting flow when broken down into 4 phases. Longer cycle times make it difficult for you to plan iterations accurately and deliver on promises (and that’s unfortunately what happens with most teams, whose cycle times are 7 days on average!). | Can show you whether teams are running with little to no roadblocks in processes. Higher merge frequencies make devs happier, because they mean the entire team is excelling together, and nothing is stopping their flow and productivity. |
Why Does the SPACE Framework Matter?
The SPACE framework lets you and your engineering managers view developer productivity from a more holistic perspective. These five dimensions help remind us that developer productivity isn’t just the result of an individual’s work but of the collaborative efforts of an entire team.
It may seem contradictory, but productivity analysis doesn’t just include adding up outputs. For example, measuring lines of code has been in the news a lot related to tech company layoffs. This isn’t smart. The people who write less code are sometimes infrastructure engineers or SREs. Does that mean they’re less efficient? No. R&D is a team sport. So you can’t just look at one metric. And it’s your job to translate this to the other execs and board members when you’re feeling the pressure to quantify developer productivity.
You can position your engineering organization for long-term success if you take a comprehensive view of the elements affecting your developers’ productivity and act on that knowledge. So let’s talk about some of the myths you’ll need to address in the process.
Busting 3 Common Myths About Developer Productivity
1. Developer Activity Determines How Productive a Team Is
This widespread misconception often leads to undesirable consequences and unhappy developers Development is a team sport, and not everyone is filling the same role. By measuring metrics like lines of code or completed story points, you’re not showing how your team members are truly performing, just how much code they write. Your dev team is just that, a team. Goalies don’t need to worry about scoring goals, so why force SREs to write as much code as your other devs?
2. A Single Metric Can Give You Everything You Need to Know
A persistent myth in the industry is that measuring developers’ output yields a single metric that you can apply consistently across projects, departments, and even entire organizations. There is no perfect metric or ideal workflow that everyone should abide by. Every team is different, and every company is different. So don’t try to compare everyone across the world to the same metric. Productivity covers various fundamental aspects of work and is highly influenced by the work environment.
3. Productivity Depends Entirely on How Well Each Person Does Their Job
Keeping tabs on your individual dev’s metrics isn’t the way to measure developer productivity. Like we said before, software development is a team sport. Your developers aren’t creating the entire application alone, so why treat them like they are? Teams are dynamic, so measure how your whole teams are performing, not team members.
How to Implement the SPACE Framework
By using the right metrics and insights, you can paint a picture that illustrates teams’ overall developer productivity. When you have a more holistic understanding of what affects productivity, you’ll be able to direct more of your efforts into these key areas. And the end result, of course, will be a highly productive engineering org that always delivers value to customers.
So if you’re looking to improve your engineering org with the SPACE framework, look no further than LinearB. We eat, sleep, and breathe developer productivity. Our three pillars—developer experience, tempo, and business alignment—are key facets to measuring your overall developer productivity.
And our workflow automation tools, WorkerB and gitStream, improve developer productivity by automating your PR processes and taking away some of the cognitive load from context switching and idle time.
