What to Measure Once DORA's Four Metrics Aren't Enough
Beyond DORA's four metrics, track interrupt ratio, rework rate, and a short recurring developer experience survey, and review them at the team level only. The four core metrics show deploy health but say little about whether engineers are working on the right things or drowning in unplanned work.
Here's what's worth adding, and the trap to avoid when you do.
Why the Four Core Metrics Aren't the Whole Picture
DORA's research groups engineering organizations into performance clusters based on deployment frequency, from teams shipping multiple times a day at the fastest end to teams going as long as 180 days between releases at the slowest1. That's a genuinely useful signal for deploy health, but a team can score well on all four core metrics while still being miserable to work on, drowning in interrupt-driven work, or shipping fast in a direction that isn't actually what the business needs. The four metrics measure the pipeline's throughput, not what's flowing through it or why.
Add Interrupt Ratio: Planned Work vs. Everything Else
Track what fraction of engineering time actually goes to planned, prioritized work versus interrupts: production incidents, ad hoc requests, and context-switching between unrelated tasks. A team with excellent deploy metrics but a high interrupt ratio is often burning capacity invisibly, since the DORA numbers can look fine even while very little planned roadmap work is actually getting done in a given cycle.
Add Rework Rate: How Often Shipped Work Gets Redone
Change failure rate captures deploys that cause an incident, but it misses the quieter cost of work that ships, gets used, and then gets substantially rewritten within a short window because requirements were unclear or the first attempt missed the mark. A rising rework rate is often an earlier, cheaper signal of a genuine process problem, somewhere upstream in requirements or design review, than waiting for it to eventually show up as a change failure.
Add a Qualitative Signal, Deliberately, Not as an Afterthought
Every quantitative metric can be gamed or can look fine while something real is wrong underneath it. A short, regular developer experience survey, specifically about friction points like build times, flaky tests, or unclear ownership, catches problems the quantitative metrics structurally can't see. Keep it short and consistent over time so you can trend it, rather than a long annual survey that's too infrequent to catch a developing problem in time to act.
The Trap: Don't Turn Any of This Into an Individual Scoreboard
Every metric in this list is meaningful at the team level and actively harmful when applied to individual engineers, since it creates an incentive to game the number rather than improve the underlying thing it's meant to represent. Use these metrics to find systemic problems worth fixing, a team drowning in interrupts, a process producing too much rework, not to rank people. The moment a metric becomes something an individual is evaluated on, it stops measuring what it was built to measure.
For example, suppose a team's deployment frequency and lead time look excellent, yet the interrupt ratio has risen for three straight sprints and rework is climbing too. Read together, the pattern points to unclear priorities upstream, not a slow pipeline. A common mistake is to respond with a target for individual output, which only teaches people to game the number. The better response is to bring the trend and the survey comments to the team, agree on the most likely shared cause, and change one upstream practice, such as how requests reach the team, before measuring again.
Review Trends Together, Not Numbers in Isolation
A single metric moving in one review period rarely tells you much on its own; a rising interrupt ratio alongside a rising rework rate paints a much clearer picture than either number alone, since they often share a root cause, such as understaffing or unclear priorities upstream. Review the set together on a regular cadence with the team, not just with leadership, so the people generating the numbers are also part of interpreting what they mean and deciding what, if anything, should change.
Bring the qualitative survey results into the same review as the quantitative numbers, rather than treating them as a separate report. A quantitative trend tells you something changed; the qualitative comments are often what actually explain why, and reviewing them together shortens the distance between noticing a problem and understanding it well enough to act on with a specific, concrete, well-targeted fix.
Signals to add beyond the four core metrics:
- Interrupt ratio: the share of engineering time spent on incidents, ad hoc requests, and context switching instead of planned work.
- Rework rate: how often shipped work gets substantially rewritten soon after release because requirements were unclear.
- A short, regular developer experience survey about build times, flaky tests, and unclear ownership.
- A team-level review of all signals together, including survey comments, rather than any single number alone.
- A firm rule that none of these metrics is used to rank or evaluate individual engineers.
What Good Looks Like
A mature engineering metrics practice tracks DORA's four core metrics alongside interrupt ratio, rework rate, and a regular qualitative developer experience signal, applies all of it at the team level to find systemic problems, and never uses any of it to score individual engineers.
Building The Capability (5-Stage Skill Ladder)
How to Get Started
Frequently Asked Questions
Should we stop using DORA's four metrics in favor of these additional ones?
No, they're complementary, not a replacement. DORA's metrics measure deploy health specifically and remain useful for that; the additional metrics here fill in what DORA doesn't capture, like unplanned work and rework, which affect a team's real productivity in ways deploy metrics alone can't show.
How do we track interrupt ratio without adding a lot of manual time tracking?
Have engineers tag work items as planned or interrupt-driven inside their existing ticket workflow. Then review the ratio over a sprint or a month instead of trying to track it to the hour. This lightweight approach works better than detailed time logging and adds almost no overhead.
Is it ever okay to use these metrics to evaluate individual engineers?
Treat this as a hard no. Every metric here is useful for finding systemic problems at the team level and becomes counterproductive the moment it's applied to individuals, since people will optimize for the number rather than the underlying thing it's supposed to represent.
Sources
Where we quote a benchmark, we show its source. Other figures in this guide are estimates or general guidance, so check them against your own numbers.
- Deployment frequency by DORA performance cluster (max days between deploys). DORA Accelerate State of DevOps 2024 (Google Cloud), cluster table via Octopus Deploy analysis, 2024.
Related Guides
Blue-Green, Canary, or Rolling: Deploying Stream Processors
A decision guide to rolling, blue-green, and canary deploys for stateful stream processors, plus the rollback plan most teams never actually test.
Verifying Every Service That Talks to Your Pipeline
Which parts of zero-trust verification to build and which to buy, so every producer and consumer on a streaming pipeline proves its identity.
Getting a New Engineer to Their First Real Commit Faster
Where new-engineer onboarding time actually goes on a real-time data pipeline team, and the specific fixes that shorten it without cutting corners.
What to Track About Engineering Productivity Besides DORA
Why DORA's four metrics don't capture the whole picture of engineering health, and what to measure alongside them without turning metrics into a scoreboard.
Making a Streaming Codebase Bearable for New Engineers
A checklist of developer experience investments that actually shorten the ramp-up time on a streaming codebase, and the ones that rarely pay off.
Where Latency Actually Hides in a Growing Data Pipeline
A walkthrough of where latency hides as a real-time pipeline grows, from producer batching to consumer lag, so you can find your own bottleneck fast.