Contents
On March 31, 1966, IBM shipped the first version of its OS/360 operating system – almost two years after announcing it. The plan had been a single system that would run even on machines with 32 KiB of memory. What shipped needed at least 44 KiB. The man who had led the project distilled the experience into a maxim that software developers still know today. An example of the Team Principle of Size.
A Project Falls Behind
Situation
Frederick P. Brooks Jr., born in 1931, joined IBM in 1956. There he led the development of the System/360 computer family and then of its operating system. OS/360 was announced in 1964. IBM put its size at about 1.5 million instructions. The schedule slipped. As a stopgap, IBM released simpler systems, among them DOS/360. The large MVT variant followed only in 1967, after further delays.
Connection to the team principle
The task was enormous, and a small team could not have handled it. The Team Principle of Size does not deny that. It says: every additional member adds strength and costs coordination – a team should be as small as the task allows. So the question is never “big or small?” but rather: What does the next person cost, and what do they bring?
More People, More Delay
Situation
When the project fell behind, Brooks added staff. It was the obvious move: if the work isn’t getting done, you need more workers. Looking back, Brooks concluded that this decision made the delay worse.
Connection to the team principle
Here the core of the principle becomes visible. Every newcomer adds strength – but only later. The cost of coordination comes at once. In a project that is already late, the strength arrives too late and the costs arrive right on time.
The Law and Its Three Reasons
Situation
IBM chief Thomas Watson Jr. asked Brooks why software projects were harder to manage than hardware projects. The answer became the 1975 book “The Mythical Man-Month.” Its best-known line is Brooks’s law: “Adding manpower to a late software project makes it later.” Brooks gave three reasons. First, newcomers have to be brought up to speed, which ties up the experienced people. Second, the number of communication channels grows faster than the headcount, following the formula n(n−1)/2. With 50 developers, there are 1,225. Third, some work simply cannot be divided.
Connection to the team principle
The formula puts a number on the cost of coordination. Do the math for your own team: five people have ten possible pairings; ten people have 45. The headcount doubles; the connections more than quadruple. A 2012 finding by the researchers Bradley R. Staats, Katherine L. Milkman and Craig R. Fox fits here: in two experiments and in data from 594 software projects, the larger the team, the more the effort was underestimated. We see the extra strength and overlook the extra price.
The Surgical Team
Situation
Brooks did not stop at the warning. His counterproposal was the “surgical team”: a small core around a lead programmer whom the others support – as in an operating room, where one person operates and the rest assist.
Connection to the team principle
This is the second half of the principle turned into a blueprint. If the task needs many hands, organize it so that not everyone has to talk to everyone. A few decide, many support. That way strength grows without coordination growing at the same rate.
The Limits of the Law
Situation
Brooks himself called his law an “outrageous oversimplification.” It applies to projects that are already late. Bringing in experienced people early and cutting the work into cleanly separated parts softens the effect.
Connection to the team principle
The principle does not forbid growth. It demands an honest calculation at the right moment. Early on, with clear subtasks and experienced people, an additional person can pay off. Late in the day and without a clear division of the work, they aggravate the very problem they are meant to solve.
Key takeaways
Key Lessons
- Before you call in reinforcements during a crisis, do the math: Who will bring the newcomers up to speed, and what will be left undone in the meantime?
- Don’t just count heads – count connections. The formula n(n−1)/2 works for any team roster.
- If the task needs many people, build a small core that the others support.
- Check whether the work can be divided at all. What cannot be divided won’t go faster with more people.
- Expand early or not at all. The most expensive reinforcements are the ones that arrive just before the deadline.
Summary
On one of the largest software projects of his time, Frederick Brooks learned that people and months are not freely interchangeable. He brought more people into a late project and watched it fall further behind. His law is the best-known practical formula for the Team Principle of Size: a new colleague costs training and coordination immediately; their strength comes later. The answer is not to stay small at any cost. The answer is to measure size against the task – and to organize the team so that coordination doesn’t eat up everything.