Why Adding More People to a Late Project Makes It Later

Every Australian developer, project manager and tech lead has lived through some version of the same scene. A project is slipping. A deadline is looming. Someone in a meeting — usually someone who isn't writing the code — suggests the obvious fix: throw more people at it. Bring in contractors. Pull engineers off another team. Spin up a few AI coding agents while we're at it.

It almost never works. And the reason it almost never works was diagnosed half a century ago, in a slim book that has outlasted just about every technology it described.

Brooks' Law, fifty years on

Fred Brooks' The Mythical Man-Month, first published in 1975 after he managed IBM's enormous OS/360 operating system project, is one of those rare technical books that became scripture. Its central claim, now known as Brooks' Law, is brutally simple: adding manpower to a late software project makes it later.

The reasoning is just as simple. Software work isn't like picking fruit or laying bricks. You can't double the workers and expect to halve the time. New people have to be onboarded by existing people — which slows the existing people down. Communication overhead grows roughly as the square of team size: two people have one channel; five have ten; ten have forty-five. And much of the work on a complex system is sequential — you can't parallelise something that depends on a decision yet to be made.

As DevPro Journal noted in a recent retrospective, the lessons Brooks drew from a 1960s mainframe project still describe what happens on modern software teams with uncanny accuracy. The tools have changed. The humans haven't.

The 'man-month' is a myth

The book's title refers to the unit project managers love and Brooks despised: the man-month, the idea that effort can be measured by multiplying people by time. If a job takes twelve man-months, surely twelve people can finish it in one month? Or six in two?

Brooks called this interchangeability a dangerous fiction. People and months are only swappable when a task can be cleanly partitioned and workers don't need to talk to each other. Almost no interesting software is like that. Designing an API, debugging a race condition, deciding how a feature should behave at the edges — these are not parallelisable. They are thinking tasks, and thinking does not scale by headcount.

This is why TheServerSide still lists 'more people equals faster delivery' near the top of its catalogue of software myths that refuse to die. Plenty of executives know to nod sagely at Brooks' Law in the abstract, then violate it the moment a board meeting goes sideways.

Why onboarding is a tax, not an investment

The maths of onboarding is the part most managers underestimate. A new engineer arriving on a six-month-old project doesn't start at zero — they start at negative. They consume the time of the people who already understand the codebase. They make changes that have to be reviewed, sometimes reverted. They commit confident code based on incomplete mental models.

Brooks estimated this ramp-up at months, not weeks, for non-trivial systems. Anyone who has joined a large codebase at an Australian bank, a telco or a government department knows the feeling: three months in, you're still asking where the deployment scripts live.

This is also why hiring sprees rarely rescue troubled programs. The bigger the rescue, the bigger the tax. By the time the new hires are productive, the original deadline has come and gone — and the team's senior people have spent the intervening months mentoring rather than shipping.

Conceptual integrity and the small-team advantage

The other half of Brooks' argument is less famous but arguably more important. He argued that great software has conceptual integrity — a coherent vision, usually held by one or two minds, that makes the system feel like it was designed rather than assembled.

Big teams threaten conceptual integrity. The more cooks, the more compromises. The more compromises, the more the product drifts toward a Frankenstein of everyone's pet features. This is why small, opinionated teams routinely outship large ones, and why the standard advice in modern engineering — keep teams to the size you can feed with two pizzas — is essentially Brooks repackaged.

The lesson for managers is uncomfortable: when a project is late, the answer is rarely more. It is usually less. Cut scope. Protect the people who hold the model of the system in their head. Resist the urge to look busy by hiring.

The mythical agent-month

Which brings us to 2024 and 2025, and the latest twist on a very old story. AI coding agents — Devin, Claude Code, Cursor's background agents, GitHub's autonomous agents — promise to multiply engineering capacity on demand. If a man-month was a myth, surely an agent-month is the cure?

The recent O'Reilly piece on 'The Mythical Agent-Month' argues, persuasively, that the same arithmetic still applies. Spin up ten agents on a single feature and you don't get ten times the throughput; you get ten parallel attempts that have to be merged, reviewed and reconciled by humans who only have so many hours in the day. The communication-overhead curve doesn't disappear just because some of the participants are LLMs. If anything, it gets worse — agents need context, supervision and arbitration, and they make confidently wrong decisions at machine speed.

Andreessen Horowitz's 'Bitter Economics' essay makes a related point about where AI value actually accrues. The cheap, abundant resource (compute, agents, generated code) is not the same as the scarce, valuable resource (judgment, taste, system understanding). Throwing more of the cheap thing at a problem doesn't relieve the bottleneck — it just shifts more load onto the scarce thing.

For Australian tech leaders weighing whether to staff a project with people, contractors or agents, this is the framing that matters. The bottleneck is rarely typing speed. It is rarely even raw productivity. It is the cognitive bandwidth of the small number of humans who actually understand what is being built and why.

What to do instead

If Brooks' Law is right — and fifty years of evidence suggests it is — then the playbook for a late project looks roughly like this:

The tools of software keep changing. The economics of attention, communication and judgment don't. The Mythical Man-Month survives not because Brooks predicted Kubernetes or Copilot, but because he understood something more durable: that building complex systems is fundamentally a human coordination problem, and human coordination doesn't scale the way we wish it did.

The next time someone in a status meeting suggests adding five people to save a slipping deadline, it might be worth quietly handing them a copy of the book.

Related on Bleen

Sources