Brooks' Law is 50 years old and still right

In 1975, Fred Brooks published The Mythical Man-Month and introduced what became known as Brooks' Law: adding manpower to a late software project makes it later. The insight was that software development isn't like digging a ditch, where twice the people means half the time. It involves communication, coordination, and integration that grow in complexity as the team grows, and at some point the overhead of adding a new person exceeds the output they contribute.

Fifty years later, the tools have changed enormously. Async communication, CI/CD pipelines, infrastructure as code, modular architectures, AI-assisted code review. The question is whether these tools have made Brooks' Law obsolete.

The data says they haven't. They've shifted the curve (the team size at which overhead becomes problematic is larger now than it was in 1975), but the fundamental dynamic, that communication paths grow faster than headcount, remains true.

The maths hasn't changed

The number of one-to-one communication paths in a team grows with n(n-1)/2. At 5 people: 10 paths. At 10: 45. At 20: 190. At 50: 1,225. This is a mathematical fact that no tool can change. Each path is a potential coordination point, a potential miscommunication, a potential meeting.

Modern tools reduce the cost per path. Async communication means not every path requires synchronous time. CI/CD catches integration issues that used to require manual coordination. Clear API contracts reduce the need for cross-team discussion about interfaces. But reducing the cost per path doesn't change the number of paths, and the number grows fast enough that even cheap paths become expensive in aggregate.

Analysis of real engineering data from over 100 B2B companies (PanDev Metrics, 2026) confirms the pattern: small teams (2-5 developers) spend a larger proportion of their day coding, while larger teams spend proportionally more time in coordination. The teams that scale best share three traits: small autonomous sub-teams, clear ownership boundaries, and investments in async processes that reduce the coordination tax per path.

What modern tools actually change

Modern tools don't break Brooks' Law, but they do shift where the inflection point sits.

Async communication (Slack, Notion, Loom) reduces meeting overhead by allowing some coordination to happen without everyone being available simultaneously. But async tools create their own coordination burden: more channels to monitor, more threads to follow, more notifications to process. The coordination moves from meetings to messaging, and the total overhead doesn't necessarily decrease.

CI/CD pipelines catch integration issues automatically, reducing the need for manual coordination around merges and deployments. This meaningfully reduces one category of coordination cost, but it doesn't address the larger categories: context transfer, decision-making, and knowledge sharing.

Modular architectures (microservices, well-defined APIs) reduce coupling between teams, allowing them to work more independently. This is the most effective mitigation because it reduces the number of paths that actually carry coordination traffic. But modular architecture requires significant upfront investment, and the inter-module boundaries create their own coordination needs.

Self-writing documentation reduces the cost of context transfer by making knowledge available without requiring the knowledge holder to be present. This directly addresses one of Brooks' three causes of overhead (the other two being training and integration). When a new person can read the docs rather than asking the existing team for context, the onboarding burden that Brooks identified is substantially reduced.

The AI-era twist

Recent research introduces a twist that Brooks wouldn't have anticipated. In the AI era, each person on a team can command AI agents that amplify their individual output. A single engineer with AI tools can produce code at a rate that previously required two or three engineers.

The naive conclusion is that AI breaks Brooks' Law because you need fewer people. The more nuanced conclusion, from a 2026 paper on the "Novelty Bottleneck," is that AI might actually make Brooks' Law worse.

The reasoning: if each person's amplified output increases the integration burden on every other team member, then the marginal coordination cost of adding person n+1 grows with agent capability. A team of five engineers each using AI agents to produce 3x the code still needs to integrate that code, review it, test it, and maintain coherence across the system. The integration burden scales with total output, and AI increases total output per person.

The practical prediction: AI-augmented organisations should converge toward smaller, more autonomous teams rather than larger ones. A team of 5 engineers with AI can match the output of a team of 50 without AI, while incurring far less coordination overhead. This is consistent with the emerging pattern of small AI-augmented startups outperforming larger traditional engineering organisations.

The practical implication

Brooks' Law is often cited as a warning (don't add people to a late project) but its deeper implication is prescriptive: invest in reducing coordination overhead rather than adding headcount.

The investments that reduce coordination overhead are the same ones that have been effective since Brooks wrote about them, updated for modern tools:

Clear boundaries and interfaces between teams, so each team can work autonomously. The two-pizza team model is the organisational expression of this.

Documentation that reduces the onboarding and context-transfer burden, so new people become productive without consuming the existing team's time.

Searchable knowledge that makes information available on demand, so coordination doesn't require synchronous communication.

Async-first processes that reduce the meeting load, so coordination happens in writing rather than in real-time.

Brooks was right in 1975, and the fundamental insight hasn't changed. Communication overhead grows faster than team size. The only question is how much of that overhead you're willing to accept versus how much you're willing to invest in reducing.

Frequently asked questions

Has any company actually beaten Brooks' Law? Companies have shifted the curve significantly through modular architecture, clear team boundaries, and strong documentation. Amazon's two-pizza teams are the most cited example. But the underlying dynamic (paths grow with n²) hasn't been eliminated. It's been managed.

Does this mean we should never scale teams? It means scaling should be accompanied by proportional investment in coordination infrastructure. Adding people without adding documentation, clear boundaries, and async processes is where Brooks' Law bites hardest.

How small should teams be? Research consistently points to 5-8 people as the optimal range for autonomous teams. Above 8, consider splitting into sub-teams with clear interfaces. The two-pizza team model provides a practical framework.

Related reading: The knowledge scaling problem, How to scale an engineering team, Why your team is getting slower, The coordination tax. Related pages: Self-writing docs, For engineering teams.