top of page

The DORA Four — Engineering Metrics & DORA, Part 1

  • Shawn West
  • Jul 28
  • 6 min read

Updated: Aug 20

Engineering Metrics & DORA · Part 1

Ask a room of engineering leaders how their team is doing and you'll get vibes — "pretty good," "busy," "shipping." DORA is the research-backed answer to "good compared to what," distilled to four numbers that actually predict whether a team delivers well. This walks through the DORA four — lead time, deploy frequency, change failure rate, and time to restore — what each one tells you, and, just as important, what they deliberately don't.

Four metrics that correlate with high-performing teams. Validated by DORA research over years.

Before you start

  • Read access to one team's deploy pipeline and issue tracker. Every number below is derived from timestamps you already emit; nothing here needs new tooling.

  • One team in mind, not an organisation. The four keys are team-level measures, and Step 9 explains why aggregating them across teams destroys the signal.

  • About 90 minutes, and a place to write four definitions down. The definitions are the deliverable — the dashboards in Part 8 are worthless if "deploy" and "failure" mean different things to different people.

  • A tolerance for the answer being uncomfortable. The first honest measurement of lead time is usually several times longer than the team's estimate of it.

Step 1: What DORA Is (5 min)

DevOps Research and Assessment — research group (now Google). Published the State of DevOps reports.

Found: four metrics correlate strongly with team performance.

These metrics aren't "the answer." They're a signal.

Step 2: Lead Time for Changes (15 min)

How long from code commit to running in production?

  • Elite: less than 1 hour

  • High: 1 day - 1 week

  • Medium: 1 week - 1 month

  • Low: > 1 month

Long lead time = slow feedback. Bugs found late. Reviews stale.

Measured: timestamp of commit → timestamp of prod deploy.

Step 3: Deploy Frequency (10 min)

How often do you deploy to production?

  • Elite: multiple per day

  • High: between once per day and once per week

  • Medium: once per week to once per month

  • Low: less than once per month

Frequent deploys = small batches = lower risk per deploy.

Not "deploy a lot" for its own sake. The shape of frequent deploys requires healthy supporting practices.

Step 4: Change Failure Rate (15 min)

What % of deploys cause an incident / rollback?

  • Elite: 0-15%

  • High: 16-30%

  • Medium: 16-30%

  • Low: 16-30% (yes, same band — many teams here)

Definition matters:

  • What counts as "failure"? Rollback? Incident? Hotfix?

  • Pick a definition; stick to it

  • Measure over enough deploys to be statistically meaningful

Step 5: Mean Time to Restore (15 min)

How long until you're back up after a failure?

  • Elite: less than 1 hour

  • High: 1 day

  • Medium: 1 day - 1 week

  • Low: > 1 week

Measured: incident detected → resolved.

Even high-performers have incidents. The difference: how fast they recover.

Step 6: Why These Four (10 min)

They balance:

  • Speed: lead time, deploy frequency

  • Stability: change failure rate, MTTR

Old myth: speed vs. stability trade-off.

DORA research: high-performing teams excel at both.

You can't optimize speed at the cost of stability — it backfires.

Step 7: SPACE Extends DORA (5 min)

a separate framework (ACM Queue, 2021) SPACE adds:

  • Satisfaction (developer experience)

  • Performance (outcomes)

  • Activity (commits, PRs)

  • Communication (collaboration)

  • Efficiency (flow)

Broader. Harder to measure. Useful for diagnosing why DORA is low.

(More in Part 6.)

Step 8: What DORA Doesn't Measure (10 min)

  • Code quality

  • Test coverage

  • Architecture quality

  • Customer satisfaction

  • Revenue

  • Engineer wellness

DORA is signal, not the whole picture. Don't optimize DORA at the expense of these.

A team can hit elite DORA while shipping buggy features users hate. Track other things too.

Step 9: Per-Team, Not Per-Engineer (10 min)

DORA measures team-level performance.

Don't:

  • Compare engineers by DORA

  • Punish individuals for missed targets

  • Use as performance review fodder

Do:

  • Identify team patterns

  • Find bottlenecks in the system

  • Improve processes

DORA at the engineer level becomes Goodhart's Law (gamed; useless).

Step 10: Start Measuring (10 min)

To start:

  • Pick one metric (e.g., deploy frequency)

  • Instrument data collection (CI / CD logs)

  • Measure for a month

  • Discuss with team

  • Set a target if motivated

Most companies don't measure DORA. The ones that do, often improve.

Tools exist:

  • LinearB

  • Swarmia

  • Faros AI

  • Cortex

  • Or custom dashboards from GitHub / CI data

The four keys, and what each one hides

Metric

What it actually measures

What it cannot tell you

Lead time for changes

Elapsed time from commit to that commit running in production

Whether the change was worth making. A team can cut lead time and ship faster things nobody asked for

Deployment frequency

How often you put a change in front of users

Batch size directly. Frequency is a proxy for it — one weekly deploy carrying forty changes reads the same as one weekly deploy carrying two

Change failure rate

The share of deploys that need a fix, rollback or patch

Severity. A cosmetic regression and a checkout outage count identically, which is why Part 4 splits failures by type

Failed deployment recovery time

How long a change-caused impairment lasts before service is restored

Anything about failures you never detected. A short recovery time can mean good tooling or poor monitoring

Read the bands as a moving target, not a scoreboard

The tier thresholds in the steps above come from DORA's State of DevOps reports, and those thresholds have changed between report years — a team that is "high" against one year's table can land differently against another. Two things follow. First, always name the report year beside any band you quote, internally or in a deck; a band without a year is unanchored. Second, check the current report rather than treating a number you read in a blog post — this one included — as fixed.

One genuine oddity worth knowing before someone flags it as a typo: on change failure rate, the high and medium clusters have shared a band in DORA's published tables. That is the finding, not a mistake. Change failure rate is simply the metric that separates the top clusters least cleanly.

What changed after these four were named

The framework this tutorial teaches is the classic four keys, and it is still the right place to start — but DORA has moved on, and you should know where before you present these to anyone.

  • Mean time to restore was renamed and redefined in 2023, to failed deployment recovery time. The old framing did not distinguish a failure caused by your change from one caused by something external — a data-centre outage, an upstream provider — which made it inconsistent with the other delivery metrics. If you instrument MTTR in Part 5, scope it to change-caused impairment and you will be measuring the current metric.

  • The current model has five metrics, not four. Deployment rework rate was added for unplanned deployments that follow a production incident — work triggered by a failure but distinct from the emergency fix itself, which change failure rate already counts.

Neither change invalidates the four keys. Both change what you should call them in a room where someone has read the current report.

You're done when

  • You can write down all four definitions for your pipeline — what counts as a deploy, what counts as a failure, when the clock starts and stops — and two engineers on the team read them the same way without discussion.

  • You have pulled one real number for one metric from your own timestamps, not an estimate. Lead time is the usual first one, and the usual surprise.

  • You can state, for any tier claim you make, which report year the band came from — and you can say out loud one thing the four keys will not catch about your team.

What You Just Did

DORA fundamentals: lead time, deploy frequency, change failure rate, MTTR, why these four, SPACE, what's not measured, team-level, start measuring. The framework.

Common Failure Modes

Optimize one metric at others' expense. DORA misses the imbalance.

Compare engineers by DORA. Gaming; resentment.

Set targets without baseline. Random.

Track DORA; ignore quality. Fast garbage.

One-time measurement. No trend; no improvement.

Sources

Continue the Engineering Metrics & DORA path

Part of the Engineering Metrics & DORA learning path.

bottom of page