The SPACE Framework
Pick balanced developer productivity metrics across five dimensions — never rely on one.
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 95%
SPACE is a framework for choosing the right metrics to measure any complex creative work, especially developer productivity. Rather than handing you exact metrics, it gives you five dimensions — Satisfaction & well-being, Performance, Activity, Communication & collaboration, and Efficiency & flow — and tells you to pick at least three that are in balance or tension so you don't optimize one thing into dysfunction. DORA is itself an implementation of SPACE.
Origin
Created by Nicole Forsgren with a group of collaborators after years of advising people on metric selection; published at ACM Queue where it became one of the most-read papers of its year. Named for its five dimensions.
Core principles
- 01Productivity is holistic and can't be brute-forced — software is a team sport and well-being is a leading signal.
- 02Use at least three dimensions at a time so metrics balance and hold each other in tension.
- 03You don't need all five — 'we're not playing blackout Bingo.'
- 04Activity metrics (counts of PRs, commits, check-ins) are seductive because they're easy to instrument — never pick them alone.
- 05Satisfaction and well-being are highly correlated with the other dimensions and fall off first when things break.
- 06Data from people and data from systems are complements — you'll never want only one type.
How to run it
- 1
Define what you're trying to improve
Start from a specific thing you want to improve (e.g. from a DORA quick-check constraint like continuous integration or culture), not a vague 'improve productivity.'
Watch out Vague goals like 'improve pull requests' lead to bad instrumentation — one team's instinct was to ping someone every 15 minutes, which would have caused alert fatigue.
- 2
Map candidate metrics to the five dimensions
For your target, consider: Satisfaction & well-being (survey-based sentiment), Performance (an outcome like change fail rate or reliability), Activity (counts of PRs/commits), Communication & collaboration (meetings, code searchability, how systems talk), and Efficiency & flow (time through the system, number of ticket hops).
- 3
Pick at least three dimensions in balance
Choose three metrics across different dimensions that hold each other in tension so improving one doesn't secretly damage another (e.g. balance code-review/PR time against protected time to work, plus a satisfaction metric).
Pro tip The 'pick three' rule forces the mental exercise of considering what you could possibly measure — its purpose is to break people out of defaulting to activity counts.
Watch out Never pick number of lines of code, and don't let a pile of easy activity metrics (commits, PRs) stand in for real productivity.
- 4
Capture each metric at the right cadence
Instrument system metrics continuously since they're scalable and automatable. Collect satisfaction metrics periodically via a survey to engineers — once every few months to once a year.
Pro tip Even the most instrumented teams still survey developers at least once a year because people reveal things systems never will (e.g. a 'fine' lead time that actually takes heroics, or mission-critical code sitting outside version control).
Watch out Don't dismiss survey data as lies — developers have no incentive to lie about a bad system they want fixed, and system data has holes too.
In the wild
A group wanted to 'improve pull requests' and was about to optimize purely on alert frequency. Forsgren pushed them to balance efficiency and flow — protecting developers' time to actually code — against code-review/PR time, and then added a satisfaction metric asking whether developers were satisfied with the PR process and reviewer selection.
→ A single-dimension activity optimization was reframed into a balanced three-dimension measurement that wouldn't create alert fatigue or steal focus time.
Forsgren points out that DORA is really 'space four' — an instance of SPACE focused mostly on the outer loop, drawing performance (change fail rate, reliability) and efficiency metrics from the SPACE dimensions.
→ Demonstrates how the general framework (SPACE) and the specific metric set (DORA) fit together rather than competing.
Common mistakes
Defaulting to easy activity metrics
People repeatedly pick lines of code, number of commits, or number of pull requests because they're trivial to instrument — but these are all activity metrics and measuring only activity tells you nothing about real productivity or its costs.
Measuring a single dimension
Optimizing one metric in isolation (e.g. alert frequency, or raw speed) throws the system out of whack; without at least three balanced dimensions you can improve a number while degrading well-being, focus time, or quality.
Is it for you?
Best for
Engineering leaders and platform teams who have identified a specific area to improve and need to choose defensible, balanced metrics for complex creative work.
Not ideal for
People who want a prescriptive, exact set of metrics handed to them with no contextual judgment — SPACE gives dimensions, not answers.
From the transcript
“we called it space because it stands for the five Dimensions that you want to measure so s is satisfaction and well-being”
“p is performance this is going to be the outcome of a process”
“a is activity anytime you have a count or a number of something these we see all the time because they're super easy to instrument…”
“to use space correctly we want to use at least three dimensions at a time because that helps us balance”
“they kept picking things like number of lines of code never picked number of lines of code”
From the episode
How to measure AI developer productivity in 2025
Nicole Forsgren