DORA Metrics 
Measuring Engineering Velocity Without Gaming It 

Every executive eventually asks some version of 'how fast is engineering, really?' and every engineering leader dreads it, because the honest answer is hard to evidence and the available proxies are all terrible. Story points measure estimation habits. Lines of code measure verbosity. Commit counts measure how someone squashes. Into that vacuum the four DORA metrics have become the closest thing the industry has to a shared answer — not because they're perfect, but because they measure the delivery system rather than the individuals inside it, and because a decade of research found they correlate with organizational performance rather than merely with looking busy. Used well, they turn a political argument into a trend line. Used badly, they become four more numbers to game.

The four metrics and what each actually tells you

• Deployment frequency — how often you release to production. This is really a measure of batch size and confidence: teams that deploy daily do so because their changes are small and their pipeline is trustworthy, not because they're heroic.
• Lead time for changes — how long from commit to running in production. This exposes everything sitting between a finished change and a customer benefiting from it: review queues, manual QA gates, release trains, approval theatre.
• Change failure rate — what proportion of deployments cause a degradation requiring remediation. This is your quality signal, and the necessary counterweight to the first two.
• Time to restore service — how long from detection to recovery. This measures whether you can respond, which in practice matters more than whether you can avoid failure entirely.

They only work as a set

The single most important thing to understand about DORA is that the four metrics form two opposing pairs, and any one of them read alone is actively misleading. Deployment frequency and lead time measure throughput; change failure rate and time to restore measure stability. Optimize throughput alone and you get a team shipping constantly and breaking things constantly. Optimize stability alone and you get a team that ships once a quarter behind six approval gates and reports a beautiful failure rate. The genuinely counterintuitive research finding — and the reason these four became the standard — is that the pairs are not actually in tension for high performers: the teams that deploy most often also fail least, because small, frequent, well-tested changes are easier to verify, easier to reason about, and trivially easier to roll back than a quarterly release containing four hundred of them. If your throughput improves while stability degrades, you haven't gotten faster; you've moved the cost downstream to whoever is on call.

Goodhart's law is the real risk

The moment a metric becomes a target, it stops being a good measure, and DORA is not immune. Tie deployment frequency to performance reviews and you'll get artificially split deploys that ship nothing. Target change failure rate and you'll find failures quietly reclassified as 'planned maintenance.' Target lead time and reviews get rubber-stamped. The defence is structural rather than moral: use these numbers at the team-and-system level, never to compare individuals, and never in compensation. Their job is to prompt questions — why did lead time double this quarter, why does one service account for most of our failures — and the answers, not the numbers, are the deliverable. Treat them like the SLOs and error budgets that govern reliability: an instrument for a conversation, not a scoreboard. It also helps to publish them as trends rather than absolutes. Nobody needs to know whether you're 'elite'; everybody benefits from knowing whether the last three months made things better or worse.

Instrumenting them without a six-month project

You can get a usable version of all four in a couple of weeks from data you already have. Deployment frequency comes straight from your CD pipeline — count successful production deploys per service per week. Lead time comes from joining commit timestamps to deploy timestamps; start with the crude version (first commit in a merged PR to the deploy that carried it) and refine later. Change failure rate needs one small discipline: tag incidents and rollbacks with the deploy that caused them, which is a field in your incident template rather than a platform. Time to restore comes from your incident tracker, provided you consistently record detection and resolution times — which, if you already run blameless postmortems, you do. Resist the urge to buy a dashboard first. The value is in the trend and the conversations, and a weekly figure computed from your existing pipeline and incident data delivers that immediately; a procurement cycle delivers it in a quarter.

What to do with the numbers

The metrics are diagnostic, not prescriptive — they tell you where the friction is, and then you have to go look. Long lead time with healthy deploy frequency usually means work is piling up in review or waiting on a manual QA gate, and the fix is smaller pull requests and automated verification rather than pressure on reviewers. Low deploy frequency almost always traces to a release process painful enough that people batch changes to avoid it, which is a pipeline problem masquerading as a culture problem. A high change failure rate points at gaps in testing or staging fidelity, or at deploys big enough that nobody can reason about their blast radius. Slow restore times usually mean you're finding out from customers rather than from monitoring, or that rollback is a manual scramble instead of one button. Notice that in every case the remedy is engineering work on the delivery system itself — better pipelines, smaller batches, progressive delivery, real observability. That's the actual value of DORA: it consistently points at the system, which is the only place where durable improvements come from.

How Infiniti Tech Partners improves delivery performance

We use DORA the way it was intended — as a diagnostic on the delivery system, not a report card on people. Typically we instrument the four metrics from data you already have inside the first couple of weeks, establish an honest baseline, and then work on whatever the numbers point at: pipeline reliability, smaller batches, automated verification in place of manual gates, progressive delivery so releases stop being events, and fast, boring rollback. The outcome our clients care about isn't a badge, it's that shipping stops being scary and the trend line moves in the right direction for reasons everyone can explain. If your delivery has been getting slower and you'd rather diagnose it than argue about it, we're happy to look — we keep our engagement count deliberately low so the teams stay senior, which means the calendar for this quarter fills earlier than people expect. A 30-minute call is usually enough to tell you where your friction actually is.