Brooks Described Our Team in 1975. Nobody Could Afford It Until Now.

The Team Was Designed in 1971 by Someone Who Could Not Afford It

Chapter 3 of The Mythical Man-Month is called "The Surgical Team". It describes a proposal made by Harlan Mills in 1971: a large job should be tackled by a team organised like a surgical team rather than a hog-butchering team. Instead of every member hacking away at the problem in parallel, one person does the cutting, and everyone else exists to make that person more effective.

Brooks thought it was right. Most of the industry thought it was right. Almost nobody did it, and the reason was money. To get one or two people actually operating, you had to hire the entire support staff around them. The structure was correct and the economics were impossible.

That is the team we put on an engagement today. Three people, and a support staff nobody has to hire.

What Changed Was the Support Staff

The support roles are what collapsed. Boilerplate, scaffolding, first-draft tests, documentation, the exploratory prototype that proves an approach before anyone commits to it: those were jobs, and now they are tooling.

What cannot be generated is the judgement, and there turn out to be exactly three kinds of it worth paying a salary for:

• What we are building and in what order. A Technical Product Manager who owns the spec and the priority order, talks to the people who use the product, and reads the implementation well enough to know whether it matches the intent.
• Whether the design holds. A senior developer and architect who owns technical direction, writes the critical paths, directs the tooling rather than following it, and decides who may touch production.
• Whether it is safe to release. A QA engineer who owns test automation, the quality gates, and release verification. This role gets more important in a lean team, not less, because generated code is plausible-looking by construction and the failures are subtle.

Three people, three judgements, and a support staff that no longer needs hiring. That is a surgical team at a price an ordinary project can pay.

Why Three Beats Eight: Three Channels Against Twenty-Eight

The structure came first. The reason it outperforms a bigger team is arithmetic, and Brooks published that in the same book.

A three-person team has three lines of communication. Add a fourth person and it is six. By eight people it is twenty-eight.

The formula is n(n-1)/2. Each person can talk to everyone but themselves, and each conversation is shared by two people, so you halve it. Going from three people to eight is 2.7 times the headcount and 9.3 times the communication channels. Each individual goes from holding two working relationships in their head to holding seven.

It is the mechanism underneath Brooks's Law, that adding manpower to a late software project makes it later. His argument is that effort and progress are only interchangeable when a task can be perfectly partitioned. Most software cannot be. And once the parts have to agree with each other, coordination becomes work in its own right:

If each part of the task must be separately coordinated with each other part, the effort increases as n(n-1)/2.

Brooks separates the burden into two parts. Training grows in a straight line with headcount: each new person has to learn the system, and that cost is paid once per person. Intercommunication grows quadratically. It is the one that kills projects, because it does not just add cost, it adds cost at an accelerating rate while the perceived benefit of each new hire stays flat.

Every engineering leader has felt this. The formula is why it feels that way.

What Fifty Years of Data Actually Says

Brooks reasoned from one very large project. The measurement came later, and the largest body of it belongs to QSM, which has examined team size four separate times across thousands of completed projects.

• Putnam, 1997. 491 completed projects of 35,000 to 95,000 source lines. Optimal team size: three to seven people.
• Beckett, 2006. Nearly 600 IT projects. The best performers delivered five times faster using fifteen times less effort, with teams on average four times smaller.
• Armel, 2012. Roughly 1,060 projects. Small teams of four or fewer against larger teams averaging eight and a half people. On smaller projects the large teams cost three times as much and shipped twice the defects. On larger projects, four times the cost and three times the defects.
• Putnam, 2018. 390 applications. Teams under four people against teams of nine or more. The large teams compressed the schedule by about 30%, and paid 350% more in cost and 500% more defects for it.

That last study is worth reading slowly, because it is the closest match to the comparison most companies are actually making: three or four people against a squad of nine.

Concede the 30%. The large team really does finish sooner on the calendar. Anyone who tells you otherwise is selling something. The question is what the 30% costs, and the answer is roughly four times the budget and five times the defects, which you then pay for again in support, rework, and incident response.

Two caveats, because a number without its limits is marketing. This research is largely from the lines-of-code era, and lines of code is a crude measure of output. And correlation runs both ways: hard projects attract big teams, which inflates the apparent penalty. What survives both objections is the mechanism. Coordination cost is not an artifact of a methodology or a metric. It is arithmetic.

Agile Already Agrees With This

The most common objection is that this is an argument against agile. It is the opposite. Agile got there independently.

The 2020 Scrum Guide caps a Scrum Team at "typically 10 or fewer people", and says it plainly:

In general, we have found that smaller teams communicate better and are more productive.

The guide goes further: if a team gets too large, it should split into several smaller teams working on the same product. Earlier versions recommended three to nine.

So nobody credible has been arguing for the eight-person squad. The Scrum ceiling became the Scrum default in practice, and the reason had nothing to do with communication.

So Why Was Anyone Ever Eight People?

Because you were not buying communication. You were buying capacity.

Eight people was never a claim that eight people coordinate well. It was an admission that three people could not produce enough code to finish the thing in a reasonable window. The coordination cost was a tax you paid to get throughput, and everybody paid it because the alternative was a project that never shipped.

That is the constraint that moved, and it is the only one that did. Not the theory, which was settled in 1975. Not the structure, which was drawn up in 1971. Not the evidence, which has been accumulating since 1997. The constraint was the cost of producing working software, and it fell through the floor.

What This Does Not Mean

A lean pod is not a corner-cutting pod, and it is not a smaller version of the same process.

Fewer channels means denser communication, not less of it. Three channels are only cheap if all three are used every day. A three-person pod has no slack to absorb a wrong assumption: an assumption that survives a day costs a day of the wrong work. That is why the daily standup is not status theatre, why decisions get written where the work lives rather than spoken in a call, and why blockers are raised the moment they appear instead of at tomorrow's standup.

The audit story gets stronger, not weaker. What an auditor tests is not headcount, it is the chain: issue, branch, pull request, review, CI gate, release, deploy, with production access explicitly approved rather than casual. Separation of duties survives at three people, because the person who writes the code is not the person who approves it or the person who verifies it. A three-person pod holding that line is more auditable than an eight-person team with direct commits to main. That is how we hold ISO 27001 while shipping in regulated industries.

And some things genuinely need more people. Work that partitions into streams with no shared data model. Several pods that must land against one deadline. Contractual status reporting. Stakeholder management across many external parties. Those are real reasons to grow, and a project manager earns their keep at that point. Producing enough code is no longer one of the reasons.

The Short Version

The structure was proposed in 1971. The theory was published in 1975. The measurements have been piling up since 1997, and agile's own guidance has said the same thing for a decade.

None of it was actionable, because you still had to buy capacity by the head, and capacity came bundled with coordination cost whether you wanted it or not.

That bundle is broken. The right answer has been sitting in chapter 3 for fifty years, waiting for the price to come down.

Related reading: The 3-Person Engineering Team That Outships Your 8-Person Squad · Why We Don't Hire Project Managers · You're Outsourcing the Wrong Roles · From Vibecoding to Production

Sources: Frederick P. Brooks, The Mythical Man-Month (1975), chapters 2 and 3 · QSM, "4 Key Studies on Team Size" (Putnam 1997, Beckett 2006, Armel 2012, Putnam 2018) · The 2020 Scrum Guide