Engineering Performance Signals: DORA, SPACE, and DX — What to Measure and What to Ignore

Every CFO eventually asks the CTO: 'How do we know engineering is productive?' The honest answer is uncomfortable: there is no single number, and any single number you optimise for will be gamed within two quarters. There are, however, three serious frameworks built by researchers who have studied this problem for two decades. This is the leader's guide to DORA, SPACE, and DX — what each measures, what each misses, and how to use them without breaking the team you're trying to measure.

Why engineering measurement is different

Software engineering output is non-linear, non-additive, and frequently invisible. A senior engineer who removes 4,000 lines of code and prevents a future incident produced more value than a junior who shipped 12 features. Lines of code, story points, and commits are universally discredited as productivity metrics — and yet they are still the default in many organisations because they are easy to count. The frameworks below exist because the easy metrics actively cause harm.

DORA — the four keys

Originating from the DevOps Research and Assessment program (Nicole Forsgren, Jez Humble, Gene Kim — published as Accelerate, 2018) and now run by Google Cloud, DORA distils a decade of research into four delivery metrics that statistically separate elite-performing organisations from low performers.

DORA is a team-level signal. It tells you how the delivery system is performing, not how any individual is performing. Using DORA to compare engineers is a category error.

SPACE — the five dimensions

Published by Forsgren, Storey, Maddila, Zimmermann, and Houck (ACM Queue, 2021), the SPACE framework was an explicit reaction to organisations using DORA as a single-axis productivity stick. The authors argue that developer productivity is irreducibly multi-dimensional, and that any honest measurement program must capture multiple dimensions and pair quantitative with qualitative signals.

DX — Developer Experience as a measurement frame

DX is the youngest of the three frames and the closest to HR engagement work. Developer Experience asks: how does it feel to do engineering work here? It blends DORA-style throughput data with structured developer surveys (typically quarterly), measuring friction points along the inner loop (code, test, build, debug) and outer loop (review, deploy, monitor).

How the three frameworks fit together

In practice, mature engineering organisations run DORA at the delivery layer, SPACE at the team-health layer, and DX at the tooling and platform layer. They are complementary, not competing.

HR engagement scores vs. engineering signals

Standard HR engagement surveys (Gallup Q12, Glint, Culture Amp generic templates) tend to under-measure engineering reality because they were built for general knowledge work. They do not ask about CI build times, on-call load, code review wait time, or whether the engineer can ship a small change in under a day. The result is engineering teams scoring as 'engaged' on the HR dashboard while quietly being miserable.

Common failure modes when measuring engineers

• Stack-ranking individuals by DORA metrics. Destroys collaboration and rewards risk-aversion.
• Treating SPACE's Activity dimension as productivity. The authors specifically warn against this in the original paper.
• Running developer surveys without acting on the results. Engagement collapses faster than if you had never asked.
• Comparing teams to each other across very different problem domains. A platform team and a product team have different baselines.
• Letting finance build the metrics. Engineering measurement needs to be co-designed with the people being measured.
• Measuring everything and deciding nothing. Pick 5–7 metrics, review them monthly, change the system based on them.

A pragmatic starter measurement stack

Where to read further