DORA metrics explained — the four keys executives actually care about
Deployment frequency, lead time, change failure rate, time to restore. Why elite performers are strong on all four at once, and what that means for how you pitch a platform.
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.