The instinct is to save work up for one big, careful release. The risk maths and the queueing maths both say the opposite. A small, frequent change fails small, is caught in minutes, and — when something does break — leaves almost nothing to bisect. Batching feels efficient. It is the enemy of flow.
The same 48 changes have to ship. Send them as a stream of small deploys, or save them for one big release. Drag the batch size and watch what a single failure costs — the red block is the blast radius, and it scales with every change you pile into the batch.
A bad change is hidden somewhere in the release. Binary search — the idea behind
git bisect — halves the suspects with every test, but the number of tests you need is set
by one thing: how many changes were in the batch. Pick a batch size and hunt the culprit yourself.
Click the middle of the suspect range each time to narrow it fastest.
Small batches are the opposite of the waterfall, big-bang drop — and the same idea as WIP limits and short queues. Here is what the lens captures that "one big push" misses, line by line.
| Big-bang batch | Small batches | |
|---|---|---|
| Blast radius | Everything you shipped is suspect at once. | Just the one small change that went out. |
| Time to detect | Days or weeks later, buried in noise. | Minutes — one change, watched closely. |
| Debug / bisect | Sift hundreds of changes to find the one. | Often the change itself; a step or two at most. |
| Feedback speed | One late, giant lesson. | Constant, cheap lessons that compound. |
| Rollback ease | Roll back the whole release — and its good parts too. | Revert a single small commit. |
| Feels efficient? | Yes — and that is exactly the trap. | No — but it is what actually flows. |
Queueing theory is blunt about it: the bigger the batch, the longer everything waits behind it. Code sits unmerged, reviews pile up, feedback arrives late, and work-in-progress balloons. WIP limits and small batches are the same medicine — keep the queue short so signal comes back fast and nothing rots on a branch.
It is — for a machine with a big fixed setup cost. Amortising one expensive setup (a print run, a kiln firing, a factory changeover) over a huge batch genuinely lowers unit cost. Software deploys are the opposite: automation drives the setup cost of a release toward zero. So batching buys you nothing on setup and costs you everything on flow, feedback and risk. Optimise the deploy, not the batch.
The same 48 changes, shipped as a trickle or as a flood, produce completely different weeks. These are the scenarios every engineer and team lead will recognise.
A three-month release ships hundreds of changes at once. Something breaks, and the team spends weeks untangling which change — out of everything since spring — did it. Down the road, a team shipping daily hits the equivalent bug and catches it in minutes: only one thing changed.
A coordinated mega-deploy goes out over a weekend — schema, config, two services, a library bump. By Monday something is clearly wrong, but nobody can say which of the 200 changes did it, so recovery means unpicking all of them under pressure.
Small commits merge to trunk continuously, integrated many times a day behind feature flags. There are no long-lived branches to reconcile; every change is small, tested and reversible. Batch size stays near one, by design.
A branch drifts for a month before anyone merges it. What started small is now a giant batch: huge conflicts, a wall of untested interactions with everything that moved in the meantime, and a review no one can meaningfully do. The delay grew the batch on its own.
The idea is simple; the discipline is not. It means resisting the pull to save work up, automating the deploy until it is boring, and trusting a stream of small, reversible steps over one grand plan. That is the work we do with the engineering teams we coach — turning "we should ship smaller" into a way of working that holds under pressure.
Talk to us about coachingWhen only one thing changed, only one thing can be wrong. Shrinking the batch shrinks everything downstream: the failure, the search, and the rollback.
Saving work up for one big release optimises a setup cost that automation already erased — while quietly maximising risk and delay. The maths favours small.
A small change you can ship and check today teaches you more than a big one you will validate next quarter. Flow comes from small, frequent, reversible steps.