The DORA research (from the DevOps Research and Assessment team, now part of Google) identified four metrics that consistently predict software delivery performance and organizational outcomes. Most engineering leaders know them. Far fewer have turned them into meaningful improvement programs.
The gap isn’t in measurement—it’s in interpretation and action.
The Four Metrics
Deployment Frequency: How often does your organization deploy to production? Elite performers deploy multiple times per day. High performers deploy daily to weekly. Medium performers deploy weekly to monthly. Low performers deploy monthly or less.
Lead Time for Changes: How long from code commit to production? Elite: less than one hour. High: one day to one week. Medium: one week to one month. Low: one month to six months.
Change Failure Rate: What percentage of deployments cause a degradation requiring remediation? Elite and high: 0–15%. Medium: 16–30%. Low: 16–30% (the research shows medium and low are similar here; the elite/high split is the meaningful one).
Time to Restore Service (MTTR): When a failure occurs, how long to recover? Elite: less than one hour. High: less than one day. Medium: one day to one week. Low: one week to one month.
What the Metrics Are Actually Measuring
The four metrics aren’t arbitrary. They measure two distinct things:
Throughput (deployment frequency + lead time): How fast does value move through your system from idea to production?
Stability (change failure rate + MTTR): When things go wrong, how bad is it and how quickly do you recover?
The insight from DORA research is that throughput and stability are not in tension—elite performers score well on both simultaneously. The belief that moving faster means breaking more things is a property of low-maturity delivery systems, not of software delivery in general.
This reframes the metrics. If you’re scoring low on both, you have a systemic delivery problem. If you’re scoring high on stability but low on throughput, you’ve optimized for safety at the cost of speed—typically through approval processes and coordination overhead that don’t actually improve quality. If you’re scoring high on throughput but low on stability, you’re moving fast without adequate testing, observability, or deployment safety.
Where Most Teams Get Stuck on Deployment Frequency
Teams that deploy weekly or monthly rarely have a technical barrier to deploying daily. The barrier is usually one of:
Large batch sizes: If each deployment is a two-week sprint’s worth of changes, deployment frequency is structurally limited. The fix is trunk-based development and smaller PRs—not a tooling problem.
Fear of deployment: If deployment is risky, teams delay it. The fix is deployment safety (feature flags, canary releases, automated rollback) not fewer deployments. Counterintuitively, deploying more frequently reduces risk per deployment.
Manual gates: Release approval processes, CAB (Change Advisory Board) reviews, and multi-step sign-offs are the most common blockers in enterprises. DORA research consistently shows these processes have no statistically significant relationship to stability, but significantly reduce deployment frequency.
The action: map your deployment pipeline and identify the human wait time vs. automation time. In most organizations, a deployment that takes 2 hours from commit to production involves 5 minutes of automation and 115 minutes of waiting.
Where Most Teams Get Stuck on Lead Time
Lead time measures the full cycle from commit to production, which means it captures everything: code review wait time, CI build time, test suite duration, deployment pipeline steps, and environment wait time.
The most common contributors to high lead time:
Long-running test suites: A 45-minute CI run that blocks deployment is 45 minutes of lead time. Parallelization, test splitting, and smarter test selection are the levers.
Code review bottlenecks: PRs sitting unreviewed for days are a lead time problem that no amount of pipeline optimization fixes. This is a team practice problem—review culture, PR size, and pairing norms.
Environment contention: Shared staging environments where teams queue for deployment slots add unpredictable wait time. Environment-per-PR (preview environments) eliminates this class of delay.
Sequential pipeline stages: Build → test → security scan → deploy running sequentially when parallelization is possible.
Interpreting Change Failure Rate
A low change failure rate can mean different things:
- Your changes are genuinely high quality (good)
- Your definition of “failure” is too narrow (bad)
- You’re not observing failures because observability is poor (bad)
Before celebrating a low change failure rate, verify what you’re counting. Are you including performance regressions, not just outages? Are you counting failures caught by customers but not by monitoring? Are on-call teams acknowledging silent degradations that never make it into incident tracking?
A change failure rate that doesn’t move despite team growth and deployment frequency increases is a signal to audit your definition, not celebrate your stability.
MTTR: The Metric Most Teams Underfund
Mean Time to Restore is the metric with the most direct relationship to business impact—it measures how long customers experience degraded service. Yet most engineering improvement efforts focus on deployment frequency and lead time while treating MTTR as an incident management problem.
The levers for MTTR:
Observability: You can’t restore what you can’t see. MTTR starts the moment something goes wrong, not the moment your monitoring fires. Alerting that lags by 10 minutes adds 10 minutes to every incident. See observability without overwhelm for how to structure your alerting.
Runbooks and playbooks: Incidents handled by engineers who’ve never seen this failure mode take longer than incidents handled by engineers following a practiced playbook. Game days and chaos engineering drills reduce MTTR by building muscle memory.
Rollback automation: The fastest restore is usually a rollback to the previous known-good version. If rollback requires manual steps, interrupting the on-call engineer at 2am to figure out which version to deploy, MTTR suffers. Automated rollback triggered by SLO violations is the elite practice.
Blast radius reduction: Feature flags, canary deployments, and regional rollouts limit the scope of failures. A deployment that fails for 5% of traffic has a smaller MTTR target than one that fails for 100%.
Setting Improvement Targets
The mistake is picking targets without identifying the constraint.
If deployment frequency is weekly and lead time is three weeks, the constraint is almost certainly batch size and deployment culture, not tooling. Adding more CI/CD automation won’t move the metrics.
If deployment frequency is daily but MTTR is one week, the constraint is incident response capability and observability, not deployment velocity.
Map the system first: where does time actually go? Which metric is furthest from elite performance? What’s the single biggest contributor to that gap? Address the constraint before optimizing everything else.
DORA metrics are diagnostic tools. The value isn’t the number—it’s the conversation about what the number reveals.