Primary source
Team got 2x bigger, results did not become 2x
Post on sublinear team scaling and why more people do not equal proportional outcomes.
Primary source
Team got 2x bigger, results did not become 2x
Post on sublinear team scaling and why more people do not equal proportional outcomes.
#Management
Doubling team size rarely doubles outcomes. At scale, diminishing utility, onboarding load, communication overhead, and sequential work constraints become dominant.
Why scaling becomes sublinear
Diminishing marginal utility
Each additional engineer tends to add less net impact than the previous one.
The first hires remove critical bottlenecks and create initial product momentum. Later hires often work on less critical items, so net output scales sublinearly.
Onboarding and group dynamics
Team expansion temporarily lowers throughput, even with strong hiring quality.
New people need context, and senior contributors switch part of capacity to mentorship and coordination. A previously stable team can return to a storming phase.
Communication cost
Potential interactions grow faster than headcount.
If everyone communicates with everyone, links follow n*(n-1)/2. As N grows, coordination overhead grows quadratically and consumes part of delivery capacity.
Parallelization limits
Not all work can be parallelized.
Planning, architecture junctions, code bottlenecks, and operational rituals include sequential portions. Amdahl's law captures this ceiling well.
Communication links follow n*(n-1)/2
Even if quality stays constant, the number of potential communication links grows faster than team size. This directly impacts synchronization load and decision speed.
Team size
4
Links
6
Team size
6
Links
15
Team size
8
Links
28
Team size
10
Links
45
Team size
12
Links
66
Amdahl law constraint on a simple example
If 30% of work is inherently sequential (planning, architecture junctions, coordination), speedup has an upper bound. Below is a simple theoretical example:
Engineers
2
Theoretical speedup
~1.54x
Engineers
4
Theoretical speedup
~2.11x
Engineers
8
Theoretical speedup
~2.58x
Engineers
16
Theoretical speedup
~2.91x
Even at 16 people, acceleration is far from 16x. Architecture and org design matter more than raw headcount growth.
Common anti-patterns
Assuming that doubling headcount automatically creates 2x value delivery.
Adding people into an already overloaded system without redesigning roles and team interfaces.
Ignoring communication cost and preserving an "everyone talks to everyone" model as team size grows.
Trying to speed up bottleneck-heavy work with more people instead of removing architectural constraints.
Measuring hiring impact only by task count instead of lead time and outcome metrics.
Practical recommendations
Before hiring, estimate what portion of work is truly parallelizable and what remains sequential.
Split large groups into autonomous units with explicit interfaces and ownership boundaries.
Treat onboarding as an investment: reserve capacity for mentoring, documentation, and shadowing.
Reduce communication coupling with architecture and process boundaries, not with more all-hands meetings.
Track flow-level metrics: lead time, WIP, release predictability, and rework ratio.
For truly hard problems, build a strong expert nucleus first (a crystallization center), then scale around it.
Key takeaway
Team scaling works only when system scaling follows: interaction structure, architectural boundaries, onboarding quality, and management cadence. Without this, additional headcount has diminishing returns.