The SPACE Framework in Practice: Five Dimensions, One Common Mistake

SPACE was published in ACM Queue in March 2021 by Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck and Jenna Butler — researchers from Microsoft Research, GitHub and the University of Victoria. It later appeared in Communications of the ACM.

Its central claim is a negative one: productivity is multidimensional, and any attempt to capture it in a single number produces decisions made on incomplete information. That claim has held up. What's aged less well is one of the five dimensions.

The five dimensions

S — Satisfaction and well-being. How developers feel about their work: engagement, frustration, burnout risk, job satisfaction. The paper's position is that well-being predicts both output quality and retention, which makes it a leading indicator rather than a soft one.

P — Performance. Outcomes and impact of the work, not the work itself. Did it do what it was supposed to for the people who use it.

A — Activity. Countable outputs: commits, pull requests, code reviews, deployments.

C — Communication and collaboration. How effectively people coordinate, how discoverable knowledge is, how work flows between people.

E — Efficiency and flow. Whether developers can make uninterrupted forward progress without unnecessary friction.

The framework's actual instructions

SPACE is more often cited than followed. Three rules from the paper do most of the work:

Measure across at least three dimensions simultaneously. The whole argument is that dimensions trade against each other. Activity rising while Satisfaction falls is a different situation from both rising, and a single-dimension view cannot tell them apart.

Include perceptual measures, not just system data. Satisfaction and Efficiency largely cannot be inferred from artefacts. This means surveys, which means ongoing cost — the most common reason teams adopt SPACE's vocabulary and skip its method.

Do not use it for individual evaluation. The paper is explicit, and specifically warns against judging developers by story points completed or lines of code.

A team tracking commits and calling it SPACE has adopted the acronym and none of the framework.

The dimension that broke

Activity was always the weakest, and AI-assisted development made it actively misleading.

Countable outputs assume a stable relationship between the count and the effort or value behind it. Generating a hundred lines and writing a hundred lines are different acts, and the commit records them identically. The framework has no mechanism for attribution, no measure of code durability, and its Activity metrics reward volume regardless of origin.

The practical fix isn't complicated: keep the other four dimensions, treat Activity as context rather than signal, and re-baseline anything derived from it after an AI rollout.

Worth noting that this doesn't undermine SPACE's core contribution. The framework's argument was that no single dimension suffices — Activity degrading is an illustration of the point rather than a refutation.

How to actually implement it

Pick one metric per dimension, three dimensions minimum. More metrics is not more insight. A workable starting set: a satisfaction survey item, a delivery outcome measure, and a flow measure such as uninterrupted time or review wait.

Put the survey on a fixed cadence. Quarterly is enough. Ad hoc surveying produces data you can't trend, which is most of the value.

Report the dimensions separately. Never combine them into a composite score. Compression into one number is exactly what the framework exists to argue against, and it reintroduces the problem under a new name.

Decide the evaluation policy first. Who sees the data, at what granularity, and whether it can enter performance review. Write it down before anyone is surveyed. Perceptual data collapses in usefulness the moment respondents suspect it's evaluative.

Where SPACE sits relative to the others

DORA measures the delivery pipeline, roughly commit to release, and has the strongest empirical foundation of the three. Its authors have acknowledged the scope limit directly: a great deal of important work happens before and after that window.

SPACE was co-authored by Forsgren as a deliberate extension of DORA's scope rather than a replacement. DevEx, published two years later, narrows again onto the lived experience of developers. Core 4 folds all three into four reporting dimensions.

They are layers, not competitors. The common mistake is choosing between them as if picking one meant rejecting the others.

Frequently asked

Is SPACE a replacement for DORA? No. It's an extension by one of the same authors, covering ground DORA deliberately excluded — satisfaction, collaboration, flow.

Can we do SPACE without surveys? Not honestly. Two of the five dimensions are perceptual by construction. Skipping the survey leaves you measuring activity and calling it something else.

How many metrics should we track? Three to five total, across at least three dimensions. Teams that track fifteen are producing a report, not a decision aid.

Why can't we combine the dimensions into one score? Because the dimensions trade against each other, and a composite hides exactly the tension you need to see. A score that goes up while satisfaction goes down looks like improvement.