Every engineering org measures something. Most measure the wrong thing — story points,
velocity, lines of code — because those numbers are easy to collect and mean almost
nothing to the person signing off on a platform investment. DORA's four keys are the
closest the industry has to a standard instrument panel, and they're worth
understanding properly because they're the vocabulary an executive already trusts,
even if they've never heard the acronym.
The four keys
- Deployment frequency — how often code ships to production.
- Lead time for changes — how long from commit to running in production.
- Change failure rate — what percentage of changes cause a failure in production.
- Time to restore service — how long an incident takes to resolve.
Group them and a pattern appears: the first two measure throughput, the last two
measure stability. That grouping is the entire point of the framework.
The finding that surprises people
The intuitive assumption is that throughput and stability trade off — ship faster, break
more things. DORA's research says the opposite: elite performers are strong on both
throughput and stability at the same time. Speed and safety aren't in tension; they're
correlated, because the same practices that make deployment fast and frequent — small
batches, automation, fast feedback — are the practices that make each individual
change lower-risk.
This matters enormously for how you pitch a platform internally. "We want to move
faster" sounds like it's asking leadership to accept more risk. "We want to move
faster and reduce change failure rate" is a different conversation, and it's the
honest one — a platform that only improves deployment frequency while degrading
stability isn't actually elite by this model, it's just fast and fragile.
Translating the four keys into dollars
Executives fund outcomes, not metrics, so the translation matters as much as the
measurement:
- Lead time reduction → faster time-to-revenue for new features. A feature that ships two weeks earlier starts earning two weeks earlier.
- Change failure rate reduction → fewer incident-hours and less firefighting cost, which is real payroll spent on unplanned work instead of the roadmap.
- Deployment frequency increase → more experiments run per quarter. This one has option value even before anyone monetizes it directly — the org that can ship ten small tests learns faster than the org that can ship two big bets.
SPACE is the counterweight
DORA measures the delivery pipeline. It says nothing about the humans running it,
which is where the SPACE framework —
Satisfaction, Performance, Activity, Communication, Collaboration — earns its place
alongside it. A platform that improves DORA numbers while tanking developer
satisfaction is buying short-term throughput with long-term attrition, and attrition
is one of the most expensive line items an engineering org has. If you're only
reporting DORA to leadership, you have half the picture — and it's the half that
looks great right up until the team that made it look great starts leaving.
Start here, not with a custom scorecard
Before building a bespoke productivity dashboard, get a DORA baseline. It's a known
framework, it's already legible to whoever approves the platform budget, and it gives
the before/after story a platform investment needs — "lead time went from 11 days to
3" lands with an executive in a way that an internal happiness score never quite does
on its own.
