The SPACE Framework: What It Measures and Where DORA Stops

TL;DR. DORA tells you how your delivery pipeline performs. SPACE tells you whether the engineers running that pipeline are burned out, blocked, or systematically less productive than they could be. The two frameworks are complementary, not competing. Organizations that only measure DORA miss the human layer. Organizations that only survey engineer satisfaction miss the pipeline layer. You need both to understand what is actually happening.

The gap DORA leaves

DORA's four metrics — deployment frequency, lead time for changes, change failure rate, and mean time to restore — are excellent diagnostic tools for delivery pipeline health. They tell you how often code goes out, how long it takes, how often it breaks things, and how fast you recover when it does.

What they do not tell you: whether engineers are burning out doing the work. Whether the most experienced people on the team are spending most of their time on work that is below their capability level. Whether communication overhead is so high that deep technical work rarely happens. Whether developers feel that their tools and processes help them do good work or get in the way.

These are not soft, unmeasurable concerns. Engineer attrition is expensive. Burnout produces subtle reliability and quality degradation before it produces turnover. Flow state time — the hours of uninterrupted deep work that produces the most complex and valuable technical output — is measurable and has been shown to correlate with productivity outcomes.

The SPACE framework was designed to address this gap. It was published in 2021 by Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler in "The SPACE of Developer Productivity" (ACM Queue, volume 19, article 30, March–April 2021; also published in Communications of the ACM). Forsgren is one of the lead researchers behind the DORA research as well, which makes SPACE and DORA explicitly complementary frameworks from the same research lineage.

What SPACE stands for

The five dimensions: Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow.

Each is a distinct measurement area. The SPACE paper is explicit that developer productivity cannot be captured by any single metric, that you need multiple dimensions and multiple perspectives, and that measuring only the easy things (activity, in particular) produces distorted pictures of what is actually happening.

Satisfaction and wellbeing

What it covers: how engineers feel about their work, their team, their tools, and whether their working conditions are sustainable. This includes survey measures of job satisfaction, sense of purpose, and indicators of burnout risk.

What to measure: periodic engineer satisfaction surveys (NPS for developers, or more structured measures), voluntary attrition rate as a lagging indicator, eNPS (employee net promoter score), and qualitative signals from manager 1-on-1s and retrospectives.

Platform engineering connection: developer experience quality is a direct input to satisfaction. Teams that fight deployment tooling, that deal with frequent production incidents because the platform does not make reliability easy, or that spend significant time on operational overhead they did not choose will report lower satisfaction scores over time. Poor developer experience is a retention risk, and platform investment is one of the levers for improving it.

The satisfaction dimension is the one most engineering leaders are comfortable with in principle and most uncomfortable measuring in practice. Committing to a regular survey and acting on the results creates accountability. Not measuring satisfaction does not mean it is fine — it means the signal arrives as attrition instead.

Performance

What it covers: outcomes, not outputs. The question is whether the engineering work being done is producing value — for users, for the product, for the business. This is deliberately hard to measure and easy to proxy badly.

What to measure: outcomes tied to engineering work (feature usage, bug rates, user impact of shipped capabilities), quality metrics (defect density, incident rate attributable to engineering changes), and product delivery against commitments. Velocity, story points, and commit counts are explicitly not measures of performance in the SPACE framework — they measure activity and get gamed when used as performance metrics.

Platform engineering connection: platform engineering improves performance indirectly by removing the friction that prevents engineers from doing their highest-value work. A developer who would otherwise spend two days configuring a new service's deployment and observability can spend those two days on the actual service logic if the platform handles the rest. The performance improvement is real, but it shows up in product outcomes over time, not in sprint velocity numbers.

Activity

What it covers: the volume of engineering actions — code commits, pull requests opened and merged, code review turnaround, build runs, deployments, incidents responded to. Activity is the easiest SPACE dimension to measure because most of it is already captured in version control systems, CI/CD pipelines, and incident tracking tools.

What to measure: commit frequency, PR merge rate, PR review latency, deployment count, incident response actions.

The danger: activity is the most commonly over-weighted dimension in developer productivity discussions. Commit counts, PR counts, and lines of code changed are all gameable and all poor proxies for value. The SPACE paper explicitly warns against using activity measures as primary productivity metrics. They are contextual data, not the measure. A developer who merges twenty small PRs per week may be less productive than one who merges three larger, more architecturally significant ones. A team with high commit frequency may be shipping noise. Activity is useful for spotting anomalies and providing context; it is not useful as a productivity scorecard.

Platform engineering connection: activity metrics are useful for measuring platform adoption — are teams using the golden paths, the shared CI templates, the observability defaults? Low adoption of platform tooling is visible in activity patterns before it surfaces in satisfaction surveys or performance outcomes.

Communication and collaboration

What it covers: how well information flows across the team and across teams, the quality of asynchronous communication, and the overhead imposed by meetings and coordination.

What to measure: pull request review latency (how long before a PR gets a first review?), documentation quality and update frequency, meeting load per engineer (hours per week in synchronous meetings), async-to-sync communication ratio, and cross-team dependency resolution time.

Platform engineering connection: platform engineering reduces communication overhead when it is working well. Good runbooks reduce the number of interruptions subject-matter experts receive from on-call engineers who do not know a system well. Good CI/CD templates reduce the questions product teams ask the platform team about why their build is failing. Good internal developer portals surface the information engineers need without requiring them to find the right person to ask.

The inverse is also true: poor platform documentation creates a high volume of interruptions that shatter flow for both the interrupter and the interrupted. The communication cost of undocumented platform tooling is real and measurable.

Efficiency and flow

What it covers: whether engineers have the time and conditions for sustained, uninterrupted technical work. Flow state — the condition of deep focus where complex, creative work happens — is real, measurable in aggregate, and destroyed by interruptions.

What to measure: flow state time (hours per day of uninterrupted work, measured via voluntary self-reporting or developer tools like Pluralsight Flow or LinearB), context switching frequency (how often engineers are pulled between tasks), wait time (time blocked waiting for CI, code review, or external dependencies), and interruption frequency.

Platform engineering connection: the platform team's work is one of the primary drivers of engineer flow time — in both directions. Slow CI pipelines break focus: an engineer waiting 20 minutes for a build to complete either sits idle or switches context, and context switching has a documented recovery cost. Unclear deployment processes create anxiety that interrupts focus. Frequent production incidents that pull engineers into unexpected on-call response shatter planned deep work time.

Platform investment that makes CI faster, deployments more reliable, and incidents rarer directly increases the flow time available to application engineers. This is the efficiency argument for platform engineering that is hardest to capture in a spreadsheet and most viscerally understood by engineers who have worked in both environments.

SPACE and DORA together

DORA answers: is the pipeline performing? SPACE answers: are the people performing sustainably?

Used together, they cover the territory. A team with strong DORA metrics but poor SPACE scores is shipping frequently but burning out to do it — a pattern that is not sustainable and will surface eventually in attrition, quality degradation, or incident rate increases. A team with strong SPACE scores but poor DORA metrics has a healthy culture operating an inefficient pipeline — the people are fine, the system is not.

The highest-value organizations score well on both. They have frequent, reliable delivery AND engineers who find their work sustainable and meaningful. Platform engineering is one of the primary investments that moves both at the same time — it makes the pipeline better and reduces the operational friction that degrades engineer wellbeing.

For a closer look at the DORA metrics side of this picture, DORA Metrics for Engineering Leaders covers what each metric signals and the common misuses.

For a broader developer experience overview, see the developer experience glossary page.

To understand where your organization currently sits across both dimensions, the Foundations Assessment provides a structured baseline measurement across delivery pipeline and developer experience before any investment decisions are made.