How Team Size Affects Productivity: Brooks's Law in Real Data

"Adding manpower to a late software project makes it later." Fred Brooks wrote that in 1975. Fifty years later, engineering leaders still debate whether it's true.

We looked at real coding data from 100+ B2B companies on PanDev Metrics to understand how team size relates to individual developer productivity. The answer is more nuanced than Brooks suggested — but his core insight still holds.

The Original Argument

Brooks's Law, from The Mythical Man-Month (1975), rests on two observations:

1. Communication overhead scales quadratically. A team of 3 has 3 communication channels. A team of 10 has 45. A team of 20 has 190. This is closely related to Conway's Law — that organizations design systems mirroring their communication structures.
2. New members need ramp-up time. They don't contribute immediately, and they slow down existing members who need to onboard them.

The implication: there's a point where adding developers actually reduces total team output. More people, less done.

But is this reflected in actual coding data?

What Our Data Shows

PanDev Metrics tracks individual developer activity across companies of varying sizes. With active B2B developers across 100+ B2B companies generating thousands of hours of IDE activity, we can observe productivity patterns across different organizational contexts.

Observation 1: Smaller Teams Show Higher Per-Developer Coding Hours

When we segment by company size, a consistent pattern emerges: developers at smaller companies tend to log more coding hours per person. This aligns with Brooks's prediction — less communication overhead means more time writing code.

In small teams (2-5 developers), a larger proportion of each person's day goes to actual coding. There are fewer meetings, fewer Slack channels, fewer code review loops, and fewer coordination touchpoints.

In larger teams (20+ developers), individual coding hours per person trend lower. This doesn't mean larger teams are unproductive — their total output is higher. But the efficiency per person decreases.

Department structure in PanDev showing team size and management hierarchy.

Observation 2: The Communication Tax Is Real

Larger teams in our dataset show characteristic patterns of communication overhead:

• More context-switching: Activity records show shorter, more fragmented coding sessions
• More review cycles: Pull requests take longer to merge as more reviewers are involved
• More coordination time: Morning coding starts later, likely due to longer standups and planning meetings

These aren't bugs in the process. Code reviews and coordination are valuable. But they have a measurable cost in coding time.

Observation 3: The Two-Pizza Team Still Works

Teams in the 5-8 developer range appear to hit a sweet spot in our data. They're large enough for meaningful code review and knowledge sharing, but small enough that communication overhead remains manageable.

This aligns with Amazon's famous "two-pizza team" rule, with Jeff Sutherland's recommendation for Scrum teams of 5-9 members, and with Conway's Law — small, autonomous teams naturally produce more modular, maintainable systems.

Beyond 8-10 developers, teams in our dataset that maintain high per-person productivity tend to have clear sub-team boundaries, well-defined interfaces, and strong async communication practices.

Where Brooks Was Right

The Ramp-Up Effect

Our data on developer onboarding (see our article on new developer ramp-up) confirms Brooks's second point. New team members take weeks to reach full productivity. During that time, they also require attention from existing team members — pair programming, code review, answering questions.

In a 5-person team adding 1 developer, the temporary productivity hit is significant: you're slowing down 5 people to onboard 1. In a 50-person team adding 5 developers, the hit is distributed across more people but lasts longer.

The Coordination Explosion

A team growing from 5 to 10 people doesn't just add 5 developers. It adds complexity:

• 45 possible communication pairs (up from 10)
• More microservices, more APIs, more shared dependencies
• More meetings to keep everyone aligned
• More code review bottlenecks

Our activity data shows this as a measurable increase in fragmented coding sessions — shorter bursts interspersed with communication activities.

Where Brooks Was Incomplete

The Parallelization Factor

Brooks assumed most tasks are sequential — that you can't make a baby in one month with nine women. In modern software development, many tasks are parallelizable.

Microservices architectures, well-defined API contracts, and feature flags allow multiple developers to work on independent workstreams with minimal coordination. Teams that invest in architecture that reduces coupling can scale more efficiently than Brooks predicted.

Tooling Has Evolved

In 1975, communication meant meetings and memos. In 2026, teams have:

• Async communication (Slack, Notion, Loom) that reduces meeting overhead
• CI/CD pipelines that catch integration issues automatically
• AI-assisted code review that reduces the review bottleneck
• Infrastructure as Code that makes environment setup reproducible
• Activity tracking tools like PanDev Metrics that provide visibility without meetings

These tools don't eliminate Brooks's Law, but they shift the curve. The team size at which overhead becomes problematic is larger now than it was in 1975.

Specialization Matters

Brooks treated developers as interchangeable. In practice, a well-composed team of specialists (frontend, backend, infrastructure, QA) can scale more efficiently than a team of generalists, because each specialist's work requires less coordination with others.

Our data shows that teams with clear role boundaries maintain higher per-person coding hours at larger sizes compared to teams where everyone works on everything. The GitHub Octoverse data on contributor patterns supports this — repositories with well-defined CODEOWNERS files show faster merge times and fewer conflicts.

Practical Implications

For Growing Teams

If your team is growing from 5 to 15 developers, plan for a temporary productivity dip. Budget 2-4 weeks of reduced output per new hire, and factor in the onboarding burden on existing team members.

Mitigation strategies:

• Stagger hires (don't add 5 people simultaneously)
• Invest in documentation and automated onboarding
• Assign dedicated onboarding buddies rather than spreading the burden
• Use pair programming sessions strategically, not as a default

For Team Structure

The data supports the two-pizza team model. When your team crosses 8-10 developers:

1. Split into sub-teams with clear ownership boundaries
2. Define interfaces between sub-teams (APIs, shared contracts)
3. Minimize cross-team dependencies in sprint planning
4. Maintain one tech lead per sub-team for coordination

For Estimation

If your team has 5 developers producing X output, adding 5 more will not produce 2X. At best, expect 1.5-1.7X in the medium term. Communicate this to stakeholders before they ask "we doubled the team, why isn't output doubled?"

For Remote Teams

Remote teams experience Brooks's Law differently. Async communication reduces the meeting tax but increases the "waiting for response" tax. Remote teams in our data show longer coding sessions (fewer interruptions) but slower feedback loops.

The ideal remote team structure: small, autonomous pods with clear ownership, minimal cross-pod dependencies, and well-defined async communication protocols.

Measuring the Effect in Your Organization

You can validate Brooks's Law in your own data using PanDev Metrics:

1. Track per-developer coding hours over time, especially during hiring periods
2. Compare coding session length before and after team expansion
3. Monitor the Tuesday/Wednesday peak — if it flattens, communication overhead may be increasing
4. Look at ramp-up curves for new hires to understand the real cost of each addition

The goal isn't to stop hiring. It's to hire intelligently, with realistic expectations and the right team structures to maintain productivity at scale.

Conclusion

Brooks's Law is 50 years old and still fundamentally correct: communication overhead scales faster than team size, and adding people has a real cost. But modern tools, architectures, and practices can mitigate the effect significantly.

The teams that scale best in our data share three traits: small autonomous sub-teams, clear ownership boundaries, and investments in async processes that reduce the coordination tax.

Don't fight Brooks's Law. Design around it.

---

See how team growth affects your productivity. PanDev Metrics tracks per-developer coding hours over time, so you can measure the real impact of scaling.