DORA metrics for small teams: what to measure and how

What are the DORA metrics?

The research behind DORA (published in DORA’s annual reports, long titled State of DevOps, and the book Accelerate) found that speed and stability move together. Teams that deploy more often also tend to break things less. The original four keys split into two for throughput and two for stability; DORA’s current model counts recovery time as throughput and measures instability with change fail rate and rework rate.

• Deployment frequency – how often you successfully release to production. Count production deploys per day or week.
• Change lead time (long called lead time for changes) – the time from a commit to that commit running in production. Not ticket-created to done; the clock starts at the commit.
• Change fail rate (also written change failure rate) – the percentage of production deployments that cause a failure needing remediation: a rollback, a hotfix, a patch or an incident.
• Failed deployment recovery time (formerly time to restore service) – how long it takes to recover when a change fails in production. The rename narrowed the metric, so outages caused by things other than your own deploys (a cloud region going down) are tracked separately.

The fifth metric, deployment rework rate, is the share of deployments that were unplanned and happened because of an incident in production. DORA also tracks reliability, whether you meet your own availability and performance targets, but as operational performance rather than a delivery metric. In practice that means SLOs: if you don’t have any, set them up last, after the delivery metrics are flowing.

Why DORA metrics matter more for small teams

Large organizations use DORA to compare hundreds of teams. A small team gets a different benefit: the metrics point at the specific bottleneck. Long lead time with high deploy frequency usually means a slow review queue. Low deploy frequency with short lead time usually means batched releases or a manual approval step. A high change failure rate tells you your tests aren’t catching what production catches.

That’s the real use. The numbers are a diagnostic, not a target. If you’re asking a broader question about why delivery feels slow, I’ve written a longer developer productivity diagnostic that covers the non-pipeline causes too.

How to measure DORA metrics cheaply

You don’t need a vendor to start. A small team can get usable numbers in a day with a script and the APIs of the tools it already pays for.

1. Make deploys an event you can query. Every production deploy should write a record: timestamp, commit SHA, who triggered it, success or failure. Your CI system’s deployment history, GitHub Deployments or a single table in your own database all work.
2. Deployment frequency falls straight out of that log. Count successful production deploys per week.
3. Lead time is the deploy timestamp minus the commit timestamp, for each commit included in the deploy. Take the median, not the mean; one month-old branch will wreck an average.
4. Change failure rate needs a link from failure back to deploy. The cheapest version: label every rollback, revert and hotfix PR, then divide labeled deploys by total deploys.
5. Recovery time comes from your incident tool or on-call channel: time from the alert (or the first customer report) to the fix being live. Record both timestamps in every incident, which a good postmortem template will force.
6. Review weekly, trend monthly. Put four numbers in the engineering channel every Monday. Look at the four-week trend, not single weeks.

Once the habit sticks and you want history and drill-down, paid tools can do this from Git and CI data. Check what your existing platform offers first; several CI and source-control vendors now ship some version of these engineering metrics.

Common mistakes when measuring

• Counting staging deploys. Only production counts. A team that deploys to staging fifty times a day and to production monthly has a monthly deployment frequency.
• Starting lead time at ticket creation. That measures your backlog, not your delivery pipeline. Track cycle time separately if you want it.
• Ignoring feature flags. If code ships dark behind a flag, the deploy counts. That’s the point of flags. Measure the release of the feature as a product metric instead.
• Treating every bug as a change failure. A typo fixed next sprint isn’t one. A change failure is something that needed immediate remediation in production.
• Averaging across teams. One platform team and one product team produce a number that describes neither.

How DORA metrics get gamed

Goodhart’s law applies in full: once a number becomes a target, people optimize the number. Every one of these has a known exploit.

• Deployment frequency: split one change into five trivial deploys, or ship no-op config changes. Watch for a frequency jump with no change in lead time.
• Lead time: rebase or squash so the commit timestamp is recent, or open the PR only when it’s already approved informally. Use the first commit on the branch, not the merge commit.
• Change failure rate: stop labeling hotfixes, or roll forward quietly instead of declaring an incident. This one is corrosive because it trains people to hide problems.
• Recovery time: declare incidents late, or close them before the fix is verified. Use the alert time, not the time someone opened a ticket.

The defense is cultural, not technical. Never tie DORA metrics to individual performance reviews, never compare individuals, and say out loud that a bad number is information, not a failure. Teams that feel safe report honest numbers.

What good looks like (and why I won’t give you a number)

DORA’s annual reports have grouped teams into performance clusters, and both the thresholds and the groupings shift from year to year. Check the current report rather than a number quoted in a blog post, including this one.

For a small SaaS team, the direction matters more than the cluster. The healthy pattern is: deploy on every merge to main, a lead time measured in hours rather than days, a change failure rate low enough that nobody fears deploying on a Thursday afternoon, and recovery in minutes because rollback is one command. If you’re far from that, the fix is usually in the pipeline and the review process, which is the work I do as an embedded engineering lead or through DevOps consulting.

What to do when a number is bad

• Low deployment frequency: find the manual step. It’s usually a release manager, a change-approval meeting or a flaky end-to-end suite people rerun until green.
• Long lead time: measure time-to-first-review. If PRs sit for a day before anyone looks, that’s your lead time. Smaller PRs and a review rotation fix more than any tooling.
• High change failure rate: look at the last ten failures and ask which test, check or canary would have caught each one. Add those, not a generic coverage target.
• Slow recovery: make rollback boring. One command, rehearsed, with database migrations written to be backward compatible so the previous version can run against the new schema. See zero downtime deployment for the migration patterns.

Related

• Developer productivity: why your engineering team is slow
• A blameless incident postmortem template that gets used
• Zero downtime deployment, including the database
• DevOps consulting for teams without a platform team
• An engineering lead for hire, embedded in your team