📖 Business
Biz - Sizing Teams
Will Larson's set of concrete heuristics for engineering team sizing, drawn from scaling organizations at Uber and Stripe. Rather than relying on intuition or "it depends," Larson provides specific numbers backed by operational experience. The core insight: team sizing is not a people problem — it is a systems design problem with predictable failure modes when the numbers are wrong.
2
Minutes
2
Concepts
+45
XP
1
How It Works

The sizing heuristics:

  • Managers should have 6-8 direct reports. Below 6, managers tend to micromanage or become overly involved in technical execution. Above 8, they become a communication bottleneck and lose the ability to provide meaningful mentorship.
  • Managers-of-managers should have 4-6 managers. The coordination overhead per report is higher at this level because each conversation carries organizational implications.
  • Teams should never be smaller than 4. Below 4, a team cannot sustain on-call rotations, absorb vacations, and maintain project work simultaneously. A 3-person team with one person on vacation and one on-call has zero people doing project work.
  • The "two-pizza team" only works if it's actually staffed. Amazon's famous heuristic is about communication overhead, but a two-pizza team of 3 people is just understaffed.

Growth and shrinkage rules:

  • When growing: add engineers to existing teams before creating new ones. New teams carry coordination overhead that established teams have already absorbed.
  • When shrinking: merge teams rather than letting them dwindle below 4. A team of 2-3 is organizationally expensive relative to its output.

Sizing also affects information flow. Too many reports means the manager becomes a bottleneck for decisions, context, and conflict resolution. Too few means the manager has excess capacity that often manifests as micromanagement or unnecessary process creation.