There's an old line, usually attributed to an economist, that goes: when a measure becomes a target, it ceases to be a good measure. Engineering leadership has spent the last decade learning this one the expensive way, one dashboard at a time.
DORA metrics — deployment frequency, lead time for changes, change failure rate, and mean time to recovery — started as genuinely good ideas. They came out of real research into what separates high-performing engineering teams from the rest. For a while, they were a mirror: hold them up to your org and see yourself honestly.
Then they became targets. And the mirror became a funhouse.
How good metrics go bad
Take deployment frequency. The research says elite teams deploy on demand, sometimes multiple times a day. That's a real signal of a healthy pipeline and a team that isn't afraid of its own release process.
But the moment a VP puts "deploy daily" on a slide, something changes. I've watched teams split one sensible release into eleven meaningless ones to hit the number. Nobody got faster. The change didn't get smaller in any meaningful way. The dashboard turned green and the engineering didn't change at all.
Lead time for changes is worse. It's supposed to measure how long it takes an idea to go from commit to production — a proxy for how much friction lives in your pipeline. But once it's a KPI, watch what happens: the clock starts at the commit, so engineers start committing earlier, in smaller fragments, sometimes before the code is even coherent. The metric improves. The review process gets harder. Nobody wins except the chart.
The perverse incentives nobody talks about
Change failure rate is the sneakiest of the four. It measures what fraction of your deployments cause a failure in production. Sounds reasonable. But "failure" is doing a lot of heavy lifting in that sentence.
Who defines a failure? If your team defines it as "a deploy that triggered a rollback," then congratulations, you've just incentivized never rolling back. If it's "a deploy that caused an incident," you've incentivized downgrading incidents. The teams with the most honest postmortems will always look worse than the teams with the most creative definitions. The metric punishes exactly the culture it was supposed to reward.
And mean time to recovery? Lovely idea. Also trivially gamed. If the clock starts when the incident is declared, then the rational move is to declare it later. Nobody does this maliciously. It just... happens. The definitions drift, the numbers improve, and everyone politely agrees not to notice.
Measure anyway, just differently
I'm not arguing against metrics. Flying blind isn't a strategy. The DORA four are still the best starting framework we have, and a team that ignores them entirely is probably ignoring other things too.
But here's the thing I keep coming back to: metrics are for diagnosis, not for judgment. The moment a metric is attached to a performance review, a bonus, or a promotion decision, it stops measuring the system and starts measuring the team's ability to game the measurement. This isn't cynicism. It's just how incentives work on actual humans.
The teams I've seen use DORA well all share one trait: the metrics live with the teams, not above them. The team looks at its own lead time and asks "where's the friction?" — and then fixes the friction. The number is a conversation starter, not a verdict. Nobody's getting a bad review because their change failure rate ticked up in a quarter where they were doing genuinely hard work.
There's also a quiet fifth metric nobody dashboards, and it's the one that matters most: do the engineers trust the measurement? The day your team starts arguing about definitions instead of arguing about engineering, you've lost the plot. The metric has eaten the thing it was supposed to measure.
So yes, measure deployment frequency. Track your lead time. Watch your failure rate and your recovery time. Just keep them in the team's hands, keep the definitions honest, and the next time someone proposes putting them on an executive scorecard, ask what exactly they're hoping to learn — and what they're afraid they'll incentivize instead.
Goodhart's law doesn't care about your dashboard. It just waits.