Appendix - DORA metrics deep dive
This page serves as a detailed companion to 4.2 - Data-driven engineering: Tracking lead time, velocity, and DORA metrics. While Chapter 4 covers why you should track these metrics and how they stabilize velocity, this appendix breaks down exactly what DORA metrics are and how to practically use them in your team.
What are DORA metrics?
DORA stands for DevOps Research and Assessment. Formed by a research team (which was later acquired by Google), the DORA framework analyzed years of data from thousands of software teams to determine what separates high-performing engineering teams from low-performing ones.
They identified four key metrics that act as the ultimate indicators of software delivery performance. These metrics balance speed (throughput) against stability (reliability).
The 4 key DORA metrics
1. Deployment frequency (DF)
What it measures: How often an organization successfully releases to production.
- High performance: Multiple deployments per day (on-demand).
- Low performance: Deploying once per month or less.
How to use it: Use DF to measure agility. If your deployment frequency is low, it means your batches of work are too large, or your deployment pipeline is too manual and risky. Break work into smaller chunks and automate your CI/CD pipeline.
2. Lead time for changes (LT)
What it measures: The amount of time it takes a commit to get into production.
- High performance: Less than one hour.
- Low performance: Between one and six months.
How to use it: LT measures the efficiency of your development pipeline. If it takes a week for a merged PR to reach production, you have a bottleneck. Look for slow automated tests, manual QA gates, or heavy approval processes, and optimize them.
3. Change failure rate (CFR)
What it measures: The percentage of deployments causing a failure in production that requires remediation (e.g., a hotfix, rollback, or patch).
- High performance: 0% - 15%.
- Low performance: 46% - 60%.
How to use it: CFR is your quality sensor. If your team is deploying fast but breaking things constantly, your CFR will spike. Use this metric to justify investing in better automated testing suites, staging environments, and stricter Code Review guidelines.
4. Mean time to recovery (MTTR)
What it measures: How long it takes to recover from a failure in production.
- High performance: Less than one hour.
- Low performance: Between one week and one month.
How to use it: Systems will eventually fail. MTTR measures how resilient your team is when that happens. To improve MTTR, invest in better observability (logging, alerting, tracing) and build automated rollback capabilities so you can revert bad code instantly.
How to use them as a Tech-Led Coach
The biggest mistake Engineering Managers make is treating DORA metrics as KPIs (Key Performance Indicators) to evaluate individual engineers. DORA metrics evaluate systems, not people.
If your MTTR is high, do not blame the engineer who took 4 hours to fix the bug. Instead, ask: Why didn't our alerts fire immediately? Why was it so hard to find the error in the logs?
Use DORA metrics as your shield to negotiate with Product Managers. When CFR spikes, point to the data to justify halting feature work and dedicating the next sprint entirely to technical debt and stability.
🎯 Self-Reflection for You
- Does your team currently track these four metrics, or are you relying entirely on gut feeling to assess engineering speed and quality?
- Which metric do you suspect your team struggles with the most: Speed (DF, LT) or Stability (CFR, MTTR)?
If you want to move away from gut-feeling management and implement a dashboard of healthy engineering metrics, let's discuss it in a virtual coffee chat.