DORA Metrics Deep Dive

What DORA Actually Measures

DORA (DevOps Research and Assessment) came out of six years of research by Nicole Forsgren, Jez Humble, and Gene Kim, which they published in Accelerate. The framework boils software delivery performance down to four metrics. What makes it interesting is that these four metrics also turn out to be predictive of organizational performance and even employee well-being.

Deployment Frequency tracks how often your team ships to production. Elite teams deploy on demand, sometimes multiple times a day. That's not about being reckless with speed. High deployment frequency goes hand in hand with smaller batch sizes, and smaller batches mean less risk per deploy. If you're only deploying once a month, every release carries a huge blast radius.

Lead Time for Changes is the clock from code commit to that code running in production. It captures everything in your pipeline: how long code review takes, CI build duration, staging validation, deployment mechanics. Elite teams get this under one hour. If yours is measured in weeks, the first places to look are approval bottlenecks and manual gates.

Change Failure Rate is the percentage of deployments that cause some kind of service degradation. Elite teams stay below 5%. Here's the thing that surprises people: teams that deploy more frequently actually have lower failure rates. Smaller changes are easier to reason about, easier to test, and easier to roll back.

Time to Restore Service measures recovery speed after something breaks. Elite teams get back to normal within an hour. This metric rewards teams that invest in observability, runbooks, and solid deployment tooling, rather than teams that try (and inevitably fail) to prevent every single failure.

How to Improve

Start by measuring what you have. Instrument your CI/CD pipeline to capture timestamps at each stage. Most teams find that their biggest bottleneck is not technical at all. It's waiting for code review or change approval. Automate what you can, but pay attention to the human handoffs first, because that's usually where the queuing delays pile up.

A practical sequence that works well: first, reduce time to restore (invest in observability and rollback capabilities). Then reduce lead time (automate testing and deployment). Then increase deployment frequency (smaller PRs, trunk-based development). Change failure rate tends to improve as a side effect of getting the other three right.

Common Misinterpretations

DORA metrics are team-level diagnostics. They are not individual scorecards. Using them in performance reviews creates exactly the wrong incentives. Engineers will start gaming deployment counts by splitting trivial changes into separate PRs. The research is clear on this: these metrics work when applied to the value stream, not to individuals. Put them on dashboards, talk about them in retros, and use them to find systemic constraints. Just don't use them to rank people.