Shipping faster without hiring, and where the weeks actually go

The question arrives in a fairly standard form. The roadmap is late, the team is six people, and somebody senior asks whether two more developers would fix it. It is a reasonable question and it has a reasonable answer, which is that it depends entirely on what the delay is made of, and that almost nobody has looked.

Fred Brooks made the famous version of this point in 1975: adding people to a late software project makes it later. The mechanism he described is still the mechanism. A new person consumes the time of the people who already know the system, and the communication paths between everyone grow faster than the headcount does. What has changed since is that we can now be more specific about where the weeks go instead of just warning against hiring.

Measure waiting and working separately

Before deciding anything, take the last twenty pieces of work the team delivered and, for each one, write down two numbers: the calendar time from the request being accepted to it being merged, and your best estimate of the hours anyone actually spent on it. The first number is usually several times the second.

That gap is the thing to attack, because it is not labour. It is work sitting in a queue: waiting for review, waiting for a decision about a detail nobody can answer, waiting for an environment, waiting for a test suite that fails for unrelated reasons, waiting for a release window. Hiring adds capacity to the part that was not the constraint.

Make the batches smaller, which is the one with evidence behind it

Most advice in this area is folklore. Batch size is not. DORA, the research programme behind the State of DevOps reports, publishes working in small batches as a capability with specific guidance attached, and the guidance is usefully blunt about size: aim for batches that take hours to a couple of days, and treat any batch that takes more than a week to complete and verify as too big. It also says to commit to trunk at least daily, and names a measurement worth stealing, which is the share of features your team can finish in a week or less.

The reason this buys calendar time rather than just feeling tidier is feedback. A small change gets reviewed quickly because reviewing it is cheap, it is easy to triage when it breaks something, and it cannot sit half finished across a fortnight collecting merge conflicts. DORA's page makes the same point from the other direction, warning that recombining small batches before testing or release delays the feedback you broke them up to get.

Two practical notes from the same guidance. Start at the service or API layer and use feature toggles or dark launches so incomplete work can ship to production without being visible, which is what makes daily merging possible at all. And watch the size of machine generated changes: DORA flags that AI tools tend to produce large diffs, and a large diff is the thing you were trying to avoid.

Remove the handoffs rather than the people

Every handoff is a queue with a person at the end of it, and queues are where calendar time disappears. The common ones are a design review before build, a separate QA pass after build, a security sign off before release, and a deployment performed by someone other than the author.

None of those are useless. The question is whether each one needs to be a stage rather than a participant. A reviewer embedded in the work reviews continuously and costs nothing in calendar time. The same reviewer as a gate at the end of a two week batch costs whatever their inbox looks like that week. Give one person a thin slice end to end, with the reviewers alongside rather than downstream, and the handoff cost mostly disappears.

This is also the honest reason a bigger team often ships more slowly. Eight people cannot work on one feature, so the work gets split, and splitting work creates coordination, and coordination creates handoffs. The team got faster at producing output and slower at delivering a result.

Decision latency is a line item

The least visible delay is the one where a developer asks a question and waits. Should this field be optional. What happens to the old records. Who approves a refund. Each of those is a five minute decision that routinely takes four days because the person who can make it is in meetings and the question is in a comment thread.

There are two fixes and both are cheap. Name one person who can answer product questions within a day and give them the authority to be wrong occasionally. And let the team decide the small ones themselves, in writing, with a default: if nobody objects by tomorrow, the field is optional. A wrong default that ships is almost always cheaper than a correct decision that arrives next week.

What we would cut first

The row that people resist is the second one. Deploying and releasing are different events, and conflating them is what makes a release window feel necessary. Once a change can reach production invisibly, the fortnightly ceremony becomes optional and a large amount of batching exists for no reason.

The row that gets skipped is the third. A test suite that fails for unrelated reasons trains the team to ignore failures, which means the suite has stopped doing its job while continuing to cost time on every change. That is the same compounding problem described in what technical debt actually is, and it is worth a week of somebody's time to end.

The honest limits

There is no figure here for how many weeks this saves, because we do not have one worth citing. What the research supports is a direction, not a multiplier. DORA's 2025 report is explicit that the returns come from the surrounding system rather than from any single change, and frames AI in particular as an amplifier of an organisation's existing strengths and weaknesses. A team with a four day review queue and a fortnightly release will amplify exactly that.

This note is also not about tooling, and specifically not about whether AI assistance makes a build faster. That question has actual randomised evidence behind it and the evidence is more surprising than either camp claims, which is why it has its own note: AI assisted software development speed, measured properly. Nothing above depends on which editor the team uses.

And hiring is sometimes right. Three cases where it is: there are genuinely independent workstreams and the coordination cost is therefore low, the team is missing a skill rather than hours, or the constraint is coverage rather than throughput and somebody is carrying an on call rota alone. In all three, expect the new person to cost the team time for the first month and plan the date accordingly rather than treating their start date as a capacity increase.

Last caveat, and it is the one worth saying to whoever asked the original question. If the roadmap is late because the roadmap was never achievable, none of this fixes it. That is a scoping conversation, and the honest version of it usually starts from the cost side rather than the speed side: how to reduce software development cost, in the right order is the companion to this one, and why software projects fail covers what happens when nobody has that conversation.