DORA Metrics in 2026: What Elite Performers Actually Do Differently

Most engineering leaders can quote their DORA numbers. Deployment frequency, lead time for changes, change failure rate, time to restore service — the four metrics have been the industry vocabulary since the DORA research programme began publishing them. The 2025 report moved the goalposts in two useful ways: it added a fifth metric, rework rate, and it replaced the familiar Low/Medium/High/Elite tiers with seven performance archetypes.

The problem is that a benchmark is a mirror, not a map. It tells you where you stand. It does not tell you what to change on Monday. A team that discovers it sits in a middling archetype learns almost nothing actionable from that label alone — the interesting question is which of the underlying capabilities is dragging the others down, and what a focused intervention over one quarter would move.

Here is how to read the 2025 findings and turn them into a 90-day plan you can actually run.

Finding 1: Rework rate is the metric that exposes the illusion of speed

The four classic metrics are easy to game. You can push deployment frequency up by shipping smaller, more trivial changes. You can compress lead time by merging faster and reviewing less. Both make the dashboard greener while the codebase quietly degrades.

Rework rate — the proportion of deployments that exist only to correct a recent change — is the metric that catches this. It measures the work you are doing to undo yourself. A team shipping five times a day with a 30% rework rate is not fast; it is thrashing, and the velocity is an artefact of repeated correction rather than throughput.

The DORA data is consistent on this point: throughput and stability are not a trade-off among high performers. The teams that ship most often also break things least often, because the same underlying disciplines — small batches, strong test signal, fast rollback — produce both outcomes simultaneously.

Action this week: Instrument rework rate before you touch anything else. You can approximate it from commit and deployment metadata: tag deployments that revert, hotfix, or re-touch code changed in the previous 14 days. If that number is above 15%, your other DORA gains are probably being funded by rework, and a velocity push will make it worse.

Finding 2: The archetypes reward capability balance, not a single heroic score

The move from four tiers to seven archetypes is the most misunderstood part of the 2025 report. It is not a finer-grained ranking. It reflects a finding that has held across years of DORA research: performance is multidimensional, and teams fail in characteristic patterns rather than along a single axis.

Some teams are fast but fragile. Some are stable but slow. Some have healthy delivery metrics but burnt-out engineers — the report has repeatedly linked delivery performance to organisational and wellbeing outcomes, and a team hitting elite throughput on the back of unsustainable on-call is a specific, recognisable failure mode.

The practical consequence is that copying the tactics of a top-archetype team is unlikely to help unless you share their bottleneck. A team blocked on a 45-minute CI pipeline needs a different intervention from a team blocked on manual change approval, even if both sit in the same archetype.

Action this week: Map your four-plus-one metrics against each other rather than against an external benchmark. If deployment frequency is healthy but change failure rate is high, your problem is test signal and rollback, not velocity tooling. If lead time is long but failure rate is low, your problem is process latency — review queues, approval gates, batch size — not quality. Diagnose the pattern before you buy the tool.

Finding 3: The capabilities that move the metrics are prerequisites, not the metrics themselves

The most useful part of the DORA body of work is not the metrics but the capability catalogue that explains what predicts them. Trunk-based development, continuous testing, loosely coupled architecture, fast feedback from automated tests — these are the levers. The metrics are the readout.

This is where most improvement programmes stall. Leaders set a target — "halve our lead time" — and treat it as a goal to be managed rather than a symptom to be diagnosed. The lead time is long because PRs sit in review for two days, or because the pipeline is slow and flaky, or because branches live for weeks and merge in painful conflicts. You do not fix lead time; you fix the capability, and lead time moves as a consequence.

A useful proof point sits in the public record of how large platforms handle this discipline at scale. Cloudflare's engineering writing repeatedly describes tight feedback loops and small, reversible changes as the mechanism behind their resilience — the practices that keep change failure rate low are the same ones that let them ship constantly. The lesson for a 50-to-500-engineer organisation is not to copy their scale but to copy the direction: invest in the capability, measure the metric, and let the metric confirm the capability worked.

Action this week: Pick the single capability most connected to your weakest metric and scope a two-week spike against it. If change failure rate is your problem, the spike is a PR-level quality gate with real test-effectiveness measurement — not just line coverage, but evidence that tests would actually catch a regression. If lead time is the problem, the spike is batch size and review latency.

What a 90-day plan actually looks like

A quarter is enough to move one archetype, not all of them. The mistake is trying to improve every metric at once. Sequence it:

• Weeks 1–2: Instrument honestly. Add rework rate. Validate that your existing four metrics are measured from the same source of truth, not four different dashboards that disagree. Diagnose the archetype pattern.

• Weeks 3–8: Fix one capability. Choose the capability behind your weakest metric and hold the line on it. This is the phase where most programmes fail, because the fix — trunk-based development, a quality gate, pipeline parallelisation — requires leadership to protect the change through the awkward middle where it feels slower before it feels faster.

• Weeks 9–12: Prove and transfer. Confirm the metric moved, document the mechanism, and make sure the team owns it without external support. A capability that only works while someone is watching is not a capability.

The reason this sequencing matters is that the metrics are correlated. Fixing test signal to reduce change failure rate almost always improves deployment frequency and lead time too, because engineers merge with more confidence. You do not need four separate programmes. You need one well-chosen intervention with the discipline to see it through.

How Anystack fits

The hard part of a DORA improvement programme is rarely knowing what to do — the capability catalogue is public. It is holding the line through the six-to-eight weeks where a branching-strategy change or a new quality gate feels like friction before it pays off, and doing it inside a live codebase without stalling delivery. A qualified engineering pod works to a client's own quality bar, using test-effectiveness measurement and adversarial review so that a falling change failure rate is evidenced rather than asserted. The pod approaches a 90-day plan by diagnosing the binding constraint first, fixing one capability at a time, and transferring ownership before it leaves — with the metric movement documented against the client's baseline, not a generic benchmark. If your teams know their scores but not their next move, that diagnosis-to-delivery gap is the work. You can see how the delivery and CI/CD practice frames it in more detail.