Why adding more Engineers doesn't always mean faster delivery

For most CTOs, more developers sound like more speed. In practice, a team under deadline pressure that adds people mid-project usually gets slower before it gets faster, sometimes for months. The reason isn't laziness or bad hiring. It's arithmetic: every new Engineer has to be taught the system by someone who is already busy building it, and that teaching time comes straight out of the delivery you were trying to protect. This isn't a discovery, it's one of the oldest, best-documented findings in software management. Let’s dive deeper.

The IBM project that gave this problem a name

It all started in the 1960s when IBM was building OS/360, the operating system meant to run its entire new family of mainframes. The project was running late behind the planned schedule, so IBM needed to find a quick solution, which in their case was adding more developers, a solution that most companies adopt today. 

Fred Brooks managed the project, and in 1975 he wrote up what he'd learned in a book called The Mythical Man-Month. Its core principle, popularly termed Brooks's Law, is straightforward: introducing additional manpower to a delayed software project delays it further. Brooks illustrated the point with a comparison that has outlived the rest of the book: you cannot produce a baby in one month by putting nine women on the job. Some jobs don't divide. They only queue.

Fifty years on, engineering teams still run the experiment Brooks already ran, usually without meaning to, and usually with the same result.

Why extra hands don't just divide the work

The instinct behind "add more developers" treats a software team like a group digging a trench: put more people on it, and the trench gets dug faster. Engineering work rarely behaves that way, for two reasons that compound each other.

1. New Engineers borrow time before they repay it

No matter how strong a new hire is, they don't join your team knowing your codebase, your deployment quirks, your undocumented decisions from eighteen months ago, or which parts of the system are held together with good intentions. Someone has to teach them that, and the person best placed to teach them is almost always the person you can least afford to pull off delivery: your most senior, most productive Engineer.

That mentoring cost is real, and it's paid upfront. A new Engineer typically needs weeks, often a couple of months, before their output clears what their onboarding cost the team. Hire five people at once, and you haven't added five Engineers' worth of capacity. For a while, you've reduced it, because your strongest people are now half-occupied answering questions instead of shipping.

2. The later you add people, the worse the maths gets

When a deadline approaches, ramp-up time does not decrease. It stays roughly the same length, which means the tighter the schedule, the bigger a bite it takes out of whatever runway is left. Add three contractors two months before launch, and you haven't bought two months of extra output. You've spent a meaningful chunk of those two months training people who won't be fully productive until after the date you needed them for.

This is the exact mechanism behind Brooks's Law. It isn't that new people are bad at their jobs. It's that the team's most experienced capacity gets redirected toward onboarding at precisely the moment there's the least slack to spare it.

The UK learned this the expensive way

Software teams aren't the only place this plays out, and Britain has a well-documented example on a national scale. In 2002, the NHS launched the National Programme for IT. This was an attempt to build a single electronic care record system connecting GPs and hospitals across England. The original budget was £2.3 billion over three years.

It didn't stay that size. As delivery slipped, the programme brought in more suppliers and more contractors rather than solving the underlying coordination problem. By 2006, the National Audit Office was estimating the true cost at £12.4 billion over a decade, and concluded it hadn't been shown that the benefits would ever exceed what the programme cost. Two of its major IT providers, Accenture and Fujitsu, walked away before it was finished. By 2011, with parts of it still years behind schedule, the government scrapped the centralised model altogether in favour of letting local NHS trusts choose their own systems.

Nobody set out to build the UK's most expensive IT failure. They set out to hit a deadline, and every time the deadline moved, the answer was more people and more suppliers rather than a smaller, clearer scope. It's the same trap Brooks described in 1975, just with more zeroes on the invoice.

What this looks like on an ordinary engineering team

You don't need a national IT programme to see the pattern. Picture a fintech scale-up six weeks from a regulatory launch date, watching its sprint velocity flatten. The CTO brings in four contractors to help close the gap.

For the first two weeks, things will get worse, not better. The pull requests will pile up because the two Engineers who actually understand the payments integration are now spending half their day walking contractors through it instead of writing code. Without the context required to prevent overlapping efforts, developers frequently conflict when editing identical files, driving up merge issues. Furthermore, if a contractor acts on a flawed understanding of an overlooked edge case due to inadequate onboarding time, their update risks causing regressions elsewhere in the pipeline.

None of this shows up as a mistake in the plan. It shows up as a launch date that quietly moves right, for reasons that are hard to put in a single line on a status update, because the honest answer is "we made the team bigger at the exact moment it could least absorb that."

When adding Engineers does help

None of this means hiring is the wrong move by default. It just means that the timing and the type of work are more important than the number of Engineers. The newcomers usually give value to the team when the work is already well-scoped and independent, such as a new integration or a self-contained feature that doesn't touch the core system everyone else is working in. It also helps when:

• you're covering absence, on-call rotas or bus-factor risk rather than trying to hit a fixed deadline;
• you bring people in early, during a calmer phase, so the ramp-up cost is absorbed before the pressure starts rather than during it;
• the person joining already has the judgement to work with minimal hand-holding, because a senior Engineer's ramp-up drain on the team is a fraction of a junior's.

What rarely works is adding headcount two or three weeks before a deadline and expecting the new hires to close the gap by the date the gap needs closing.

How to add capacity without paying the delivery tax

A few habits keep this cost from ambushing a team:

1. Recruit well before any critical deadline rather than as a reaction to it, ensuring onboarding occurs while your timeline still has flexibility. 
2. Explicitly account for mentoring time in team budgets instead of assuming it occurs without affecting baseline productivity. 
3. Bring new people into low-dependency, well-documented parts of the system first, and let them earn context on the core before they touch it under pressure. 
4. Where possible, look for people who arrive with the context already built in, whether that's an internal transfer who already knows the codebase or a dedicated Engineer who has worked with your team long enough that the "getting up to speed" cost has already been paid.

That last point is worth sitting with, because it's the difference between the outcome most CTOs actually want and the one they usually get. A contractor who parachutes in for eight weeks pays the full ramp-up cost against a project they'll leave shortly after finishing it. An Engineer who's embedded in your team for the long term, sitting in your standups and carrying context from one sprint to the next, only pays that cost once. This is where TechPods steps in.

Fewer hands, better aimed

The uncomfortable part of Brooks's Law is that it's not really about headcount at all. It's about timing, context and judgement, three things a bigger team doesn't automatically have more of just because it has more people. A team that adds the right person early, with room to ramp up before the pressure hits, gets faster. A team that adds several people late, hoping numbers alone will close a gap, almost always gets slower first and sometimes never fully recovers the schedule it lost along the way.

We've written before about why how many developers you actually need is rarely the right first question, and how capacity and capability get confused for each other in most sizing decisions. This is the mechanism underneath both: the reason more people doesn't equal more speed, and why the timing of a hire matters almost as much as the decision to make one at all.

This is exactly the problem TechPods is built to solve. We're an elite technology co-sourcing company with offices in Bath, England and Sofia, Bulgaria, and our model gives businesses the engineering capability they need without the cost, complexity and employment risk of building everything internally. We build dedicated, exclusive engineering teams for our partners, with direct access to elite Bulgarian tech professionals, rather than a rotating bench that makes you pay the ramp-up tax every time a contract ends and a new one begins.

That's the practical answer to everything this article has covered. An Engineer who joins your standups, learns your codebase once and stays only has to be brought up to speed a single time, not repeatedly, every few months, for as long as the project runs. Cost transparency and cultural alignment are what make that kind of long-term partnership work, and they're the foundation everything at TechPods is built on.

If your team is about to add headcount against a deadline, it's worth asking first whether you need more people, or the right two who already know how to move fast together and are going to stay long enough for that to matter. Let’s talk.