DORA Metrics: The Only Numbers That Matter
"You can't manage what you can't measure."
The problem in software engineering isn't a lack of measurement; it's that we measure the wrong things. We count Lines of Code (which encourages bloat), Hours Worked (which encourages burnout), and Velocity (which encourages estimating abuse).
These are "Vanity Metrics." They look good on a slide but tell you nothing about value.
The Google DevOps Research and Assessment (DORA) team spent six years analyzing 31,000+ professionals to find the metrics that actually correlate with high-performing companies. They found four.
In this guide, we break down the DORA metrics and how to use them to diagnose your team's health.
The 4 Key Metrics
The DORA metrics balance Speed (Throughput) with Stability (Quality). If you only measure speed, you get bugs. If you only measure stability, you get nothing done.
1. Deployment Frequency (DF)
"How often do we ship?"
- The Diagnostic: If you deploy once a month, every release is a terrifying event. If you deploy ten times a day, a release is a non-event.
- Elite Standard: On-demand (multiple times per day).
- How to Fix: Automate the pipeline. If deployment requires a human to sign off, you will never be elite.
2. Lead Time for Changes (LTC)
"Time from Commit to Production."
- The Diagnostic: This measures the friction in your pipeline. If code sits in a Pull Request for 4 days and then waits for QA for 3 days, your Lead Time is 1 week.
- Elite Standard: Less than 1 hour.
- How to Fix: Use Trunk-Based Development. Long-lived feature branches are the enemy of speed.
3. Change Failure Rate (CFR)
"How often do we break it?"
- The Diagnostic: What percentage of deployments cause an incident?
- Elite Standard: < 5%.
- How to Fix: Automated testing. If you rely on manual QA, your failure rate will naturally be higher because humans get tired.
4. Mean Time to Restore (MTTR)
"How fast do we fix it?"
- The Diagnostic: When prodoction breaks (and it will), do we panic for 4 hours, or do we rollback in 5 minutes?
- Elite Standard: Less than 1 hour.
- How to Fix: Feature Flags. Don't "fix forward" during an outage; just toggle the broken feature off.
The "J-Curve" of Transformation
Be warned: When you start optimizing these metrics, things often look worse before they look better.
- Start: You are slow but stable (because you never release).
- Chaos: You start deploying daily, but you lack the tests to catch bugs. Failure Rate spikes. Performance dips.
- Integration: You stop the bleeding by adding test coverage.
- Elite: You are now fast and safe.
Most leaders quit during the "Chaos" phase. Don't.
Summary
If you want to know if your team is healthy, ignore the Jira burn-down chart. Look at your DORA metrics.
- Are we shipping daily? (DF)
- Does code sit in limbo? (LTC)
- Do we break things often? (CFR)
- Can we recover fast? (MTTR)
If you get these four right, everything else—revenue, morale, customer satisfaction—follows.
