Starting with DORA: A Practical Guide for Engineering Leaders

One of the most common questions I receive from engineering leaders is some version of "how do I know if my team is actually performing well?" It is a harder question than it appears. Story points are gamed. Velocity measurements create perverse incentives. Bug counts depend on how bugs are defined. The DORA metrics — developed through years of research by the DevOps Research and Assessment team — are the closest thing the industry has to a validated, objective framework for engineering performance.

The Four Metrics

• Deployment Frequency: How often does your team deploy to production? Elite performers deploy on-demand, multiple times per day.
• Lead Time for Changes: How long from code commit to running in production? Elite teams measure this in hours, not weeks.
• Change Failure Rate: What percentage of deployments cause a failure requiring remediation? Elite teams keep this below 5%.
• Mean Time to Recovery: When something breaks, how long to restore service? Elite teams recover in under an hour.

Why These Four, Specifically

The power of the DORA framework is not any individual metric — it is the balance between throughput and stability. Deployment frequency and lead time measure speed. Change failure rate and MTTR measure safety. Optimizing only for speed leads to chaos. Optimizing only for stability leads to stagnation. The framework forces you to hold both simultaneously, which is exactly what elite engineering looks like.

“DORA metrics are not a performance review tool. They are a diagnostic instrument — a way to locate where your system is constraining your team.”

Getting Started Without Overwhelming Your Team

The biggest mistake I see engineering leaders make with DORA is trying to measure all four metrics perfectly before acting on any of them. Start with lead time. It is the easiest to measure — you can often derive it from your existing CI/CD tooling — and it surfaces the most actionable information. A long lead time almost always traces back to one of: large batch sizes, manual handoffs, or insufficient test coverage. Each of those has a clear improvement path.

Once you have lead time trending in the right direction, deployment frequency naturally follows. Change failure rate and MTTR then become your quality and resilience story. Build the habit of measuring before optimizing, and you will avoid the trap of making changes that feel like improvements but do not actually move the metrics.