The DORA Finding Everyone Misquotes: Speed and Stability Aren't a Trade-off
Everyone quotes DORA for deployment frequency. Fewer people notice the more interesting finding underneath it: teams that ship faster don't fail more often, they fail less. Two practices explain why, and a Dubai travel-tech company's change-failure rate is the number that proves it.
TL;DR: The common assumption is that shipping faster means breaking more. DORA's research says the opposite happens in practice, elite performers deploy far more often and fail less often than low performers. Two practices explain the mechanism: safe-to-fail experiments (feature flags, staged rollouts) make a bad idea cheap to undo, and the reliability work underneath (automated tests, fast rollback) is what makes trying things in the first place feel safe. A Dubai travel-tech company's change-failure rate fell from 23% to 6% in the same rebuild that also quadrupled its feature-shipping rate, same project, two numbers moving the same direction.
"We can move fast, or we can be careful" is the framing almost everyone defaults to, and DORA's research has been quietly contradicting it for close to a decade. Elite DevOps performers don't trade stability for speed, they have both, deploying far more frequently than low performers while also failing less often on each deploy. That's not a paradox once you look at which two practices are actually doing the work.
Practice 1: make the failure cheap before you try the risky thing
Feature flags and staged rollouts change what a bad idea costs. Instead of shipping to everyone and hoping, a new idea reaches a small slice of users first. If it's bad, it switches off at the flag, no redeploy, no incident. Because a failed experiment now costs minutes instead of a crisis, teams propose things they'd otherwise self-censor, the risky idea only stays unproposed when trying it is expensive, and this practice is specifically what makes trying it cheap.
Practice 2: the reliability work is what makes practice 1 trustworthy
A feature flag only feels safe to flip if you trust the rollback underneath it. Automated testing catches obvious problems before they ship at all; fast, practiced rollback means that if something slips through anyway, undoing it takes seconds, not a war room. This is the part that sounds backward: investing in reliability isn't the cautious alternative to moving fast, it's the precondition for it. A team that trusts its rollback path takes bolder bets than one that doesn't, because being wrong stops being expensive.
Why these two together explain the DORA finding
| Without both practices | With both practices | |
|---|---|---|
| Cost of a bad idea | High, a failed release is a visible incident | Low, a flag flips off in minutes |
| Team's instinct | Self-censor, propose only safe changes | Propose more, let the data decide |
| Deploy frequency | Stays low, each release is a risk | Rises, because each release is cheap |
| Change-failure rate | Stays high or improves slowly | Falls, because bad ideas get caught small |
The two metrics that look like they should trade off, deployment frequency and change-failure rate, actually move together once this is in place, because the same two practices drive both of them.
Case study: the change-failure number that mattered more than the feature count
A Dubai travel-tech company wanted to out-innovate larger competitors but kept stalling at one or two bundled releases a quarter, and every failed feature meant a painful manual rollback. Naturally, the team had grown cautious about proposing anything risky. Five-month rebuild of delivery and culture together:
| Problem | What got built | Outcome |
|---|---|---|
| Slow, bundled, high-stakes releases | CI/CD pipeline with short feedback loops | Lead time: 11 days → 2 hours |
| No safe way to test risky ideas | Feature flags, staged rollouts | Features shipped: 4 → 17 per quarter |
| Releases that were risky because rollback was manual | Automated tests, monitoring, practiced fast rollback | Change-failure rate: 23% → 6% |
| Decisions made on hunches | Live dashboards on feature performance | Repeat-booking rate +14% |
Most retellings of this engagement lead with the 4-to-17 feature jump, and it's a real number. The one worth sitting with longer is the change-failure row: the team didn't just ship more, each individual release got safer, from roughly one in four causing a problem down to one in sixteen. That's the DORA finding in miniature, the same rebuild that made releases four times more frequent also made each one four times less likely to fail.
FAQ
Doesn't shipping more often mechanically mean more chances to fail? More releases, yes, but each release is also smaller and better-tested, which is why the rate falls even as the count of releases rises. Volume and risk-per-release are different numbers, and DevOps practices specifically target the second one.
Which practice should a team adopt first if they can only pick one? Automated testing and fast rollback, underneath, since feature flags only feel safe to use once a bad flip can be reversed quickly. Add flags second, once the rollback path is trustworthy.
Is this specific to travel-tech, or does the mechanism generalize? The mechanism is general, cheap failure plus trustworthy rollback works the same way regardless of industry. Travel-tech's booking-engine seasonality just made the before/after numbers easy to measure cleanly.
This is a condensed take on the full write-up (with the complete six-practice breakdown and the faster/smarter/stronger framework). For the pipeline underneath both practices, see CI/CD pipelines explained; for the reliability layer specifically, resilient cloud infrastructure.
About the author: Muhammad Usman is Head of DevOps at Sherdil Cloud, AWS DevOps Engineer Professional, Certified Kubernetes Administrator (CKA), and Alibaba Cloud Certified, building cloud and DevOps infrastructure for enterprises across Pakistan, the UAE, and the United States since 2014.