There's a persistent myth that shipping carefully means shipping rarely, that big, infrequent, heavily-reviewed releases are the safe choice. Google's DORA research, running since 2014, says the opposite. The teams that deploy most often are also the most reliable, and they get there through a specific practice: trunk-based development, small changes merged to a shared main line and released constantly.
Key Takeaways
- Elite performers deploy on demand, many times a day; low performers deploy monthly to every six months, roughly 1,000x less often (DORA).
- Elite teams are 2.3x more likely to use trunk-based development (LaunchDarkly on DORA).
- Throughput and stability aren't a tradeoff: frequent deployers also fail less and recover faster (DORA).
- Frequent deploys are an outcome of good practices (small batches, automated tests), not a goal you chase directly.
What the Data Shows
Every DORA State of DevOps report since 2014 has found the same counterintuitive thing: speed and stability go together. Elite teams deploy on demand, often many times a day, while low performers ship somewhere between monthly and twice a year, a gap of roughly a thousand times (DORA). And those fast-shipping teams aren't reckless, they have fewer failures and recover faster. The tradeoff everyone assumes, go fast and break things or go slow and stay safe, isn't real in the data (2024 DORA report).
The practice underneath it is trunk-based development: engineers integrate small changes into a shared main branch frequently, rather than working for weeks on long-lived feature branches that turn every merge into an adventure. DORA found elite performers 2.3x more likely to work this way (LaunchDarkly).
Why Small and Frequent Wins
The logic is batch size. A small change is easy to review (see the code-review size research), easy to test, and easy to reason about when it breaks. Deploy ten-line changes twenty times a day and each one has a tiny blast radius; if something breaks, you know exactly which change did it and you roll it back in a minute. Deploy one 5,000-line release a month and every deploy is a terrifying event where dozens of changes go out together and any of them could be the culprit. Frequency isn't the risk. Big batches are.
| Big infrequent releases | Small frequent releases | |
|---|---|---|
| Batch size | Large | Small |
| Blast radius per deploy | Huge | Tiny |
| Finding what broke | Hard (many changes) | Easy (one change) |
| Rollback | Scary | Routine |
A Concrete Version
A team ships once a month behind a big release process. Deploy night is all-hands, tense, and often runs late, and when something breaks they spend hours bisecting which of forty changes caused it. They "go slow to be safe," and it isn't safe. Switch to trunk-based development, merge small changes to main, run automated tests on every commit, deploy behind flags several times a day, and each release becomes boring. Breakages are rare, obvious, and reverted in minutes. The team that deploys 50x more often has fewer incidents, exactly what DORA predicts.
The Honest Counterpoint
Trunk-based development isn't a switch you flip, and it doesn't work without the scaffolding underneath it. You need a solid automated test suite (so merging to main constantly is safe), feature flags (so unfinished work can ship dark), and fast CI. Without those, merging everything to main just means breaking main for everyone, all the time. DORA's own point is that elite teams didn't deploy more to become elite, they built the engineering practices that made frequent deploys safe, and the frequency followed. Deploy frequency is a result, not a goal you can mandate.
What This Means for Teams
Getting to safe, frequent deploys is an engineering-maturity question, and it's the kind of thing experienced engineers set up almost reflexively: test automation, flags, a clean pipeline. It connects directly to the DORA metrics that measure delivery health and the fast recovery behind blameless incident response. Senior engineers who've built this before can stand it up far faster than a team learning it the hard way. See available engineers.
Frequently Asked Questions
Is it safer to deploy less often?
No. DORA's research since 2014 finds the opposite: teams that deploy most frequently also have fewer failures and recover faster. Big, infrequent releases are riskier, not safer.
What is trunk-based development?
A practice where engineers merge small changes into a shared main branch frequently, instead of maintaining long-lived feature branches. DORA found elite performers 2.3x more likely to work this way.
Why do small, frequent deploys reduce risk?
Each deploy carries a tiny change, so its blast radius is small and it's obvious what broke. Big batched releases send many changes at once, making failures more likely and harder to trace.
How do we start deploying more frequently?
Build the foundations first: automated tests on every commit, feature flags for unfinished work, and fast CI. Frequent deploys are an outcome of those practices, not something to mandate on their own.
The Bottom Line
The safe-means-rare instinct is backwards. A decade of DORA data shows the teams that deploy on demand are also the most reliable, and they get there with trunk-based development and small batches. Ship small, ship often, build the test-and-flag foundation that makes it safe, and both speed and stability improve together.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
