Running network operations at a large enterprise telecom, I once signed off on a maintenance window that bundled nine changes into a single overnight release. A firmware update, two configuration changes, a database migration, a routing change, and a handful of smaller fixes that had been waiting weeks for a slot. Batching them felt like the responsible move. One window, one customer notification, one on-call rotation, one set of approvals. Everything I had absorbed in twenty years of operations said that fewer, larger, carefully staged releases were how you protected a production network.
Something broke around 2 a.m. The rollback ate most of the night, because nobody could isolate which of the nine changes had caused it. We reverted all of them, threw away work that was almost certainly fine, and rescheduled. The incident review asked the obvious question, and my first answer was wrong. I said we needed more testing, a longer window, another layer of sign-off. The correct answer was the opposite. We needed to stop shipping nine things at once.
Product teams make the same mistake with features that operations teams make with changes. And the delivery research on it is now clear enough that guessing is no longer an excuse.
The big release hides a bet nobody decided to make
When you bundle nine changes into one release, you are not reducing risk. You are concentrating it and hiding it. The release either succeeds as a block or fails as a block, and when it fails you are handed a diagnostic problem that scales with the size of the batch. Nine changes means nine suspects, plus every interaction between them. The time to find the culprit goes up, the pressure to just revert everything goes up, and the good work gets thrown out alongside the one line that broke.
A small release inverts all of that. One change means one suspect. If it fails, you know what failed. If you revert, you lose one thing, not nine. The batch size is a decision about how much you are willing to lose when you are wrong, and most teams never frame it as a decision at all. It gets set by default, by the calendar, by the release train, by the instinct that grouping work together is tidier.
Speed and stability are not the trade-off everyone assumes
The belief underneath the big release is that shipping less often is safer. Google’s DORA program has spent years measuring whether that is true across tens of thousands of engineering teams, and the finding is the reverse of the folklore. The teams that deploy most frequently, in the smallest increments, also fail least. In DORA’s data the highest performers deploy on the order of 973 times more often than the slowest teams, recover from failures far faster, and carry a change failure rate roughly a third as high. Throughput and stability move together. They are not opposite ends of a dial.
The 2024 State of DevOps report puts elite change failure rates in the 0 to 15 percent band with recovery measured in under an hour, and it is blunt about the mechanism: many of the moves that raise throughput, including automation and smaller batches of work, also improve stability. Smaller is not a tax you pay for speed. Smaller is what buys you both.
None of this is new theory. Donald Reinertsen made the economic argument in The Principles of Product Development Flow years before the DORA numbers existed. Reducing batch size, he showed, cuts cycle time, cuts variability, accelerates feedback, and reduces risk, all at once. The overnight window I signed off on violated every one of those principles in a single stroke.
Why smaller is genuinely safer, not just faster
The safety comes from three places, and they compound.
Diagnosis gets cheap. Fewer changes in a release means fewer variables when something goes wrong, so you spend minutes finding the cause instead of a night. Rollback gets cheap. Reverting one small change is a shrug; reverting a bundle means sacrificing work that had nothing to do with the failure, which is its own quiet form of rework that never shows up as shipping faster. And feedback gets fast. A small change that reaches a customer this week tells you something real this week, instead of sitting in a batch waiting for the next big window while the work item quietly ages on the board.
There is a fourth effect that is easy to miss. Big batches encourage more work in progress, because everything piles up waiting for the same slot. Small, frequent releases pull work through instead of letting it accumulate, which is the same discipline behind limiting how much a team starts at once. Batch size and work in progress are the same lever seen from two angles.
What to do when you can’t deploy on demand
Most product teams cannot ship dozens of times a day, and that is fine. The principle does not require continuous deployment. It requires that you stop treating the big release as the safe default and start treating batch size as something you choose on purpose.
That means slicing a feature into pieces that can ship and prove value independently, rather than holding the whole thing back until every part is done. It means putting a change behind a flag so it can be turned on for a slice of users and turned off in seconds without a rollback. It means sequencing dependent changes across separate releases instead of stacking them into one window because the window was already booked. And it means asking, every time work gets grouped together, a single question: if this release fails, how many things will we have to untangle to find out why?
I have run enough late-night rollbacks to give you the honest version. The disciplined-looking release, the one that batches everything into a careful, well-approved event, is usually the riskiest way to ship. The safe release is the small one you can understand at a glance and undo without regret. It took a wasted night and a bad first answer in a post-incident review for me to learn that operations teams and product teams are solving the same problem. Ship less at a time. You will ship more in the end.