Headcount Adds Paths Faster Than Output

Every hire adds a person. It also adds a conversation with everyone already there.

THE IDEA IN ONE LINE

Headcount grows in a line. Coordination grows in a curve.

After a funding round, the plan is usually the same: hire. More engineers to ship faster, more sellers to close more, more people to take work off the founders. The logic looks simple. Twice the people should do roughly twice the work.

Six months later, the company is bigger and not much faster. Meetings have multiplied. Decisions wait for someone who is in another meeting. The new hires are capable, and the founders still feel busier than before.

Nothing has gone wrong with the people. What has changed is the arithmetic. Output grows with headcount, at best in a straight line. The paths between people grow much faster.

The arithmetic of a team

Every pair of people who may need to coordinate is a path. With n people there are n(n-1)/2 of them. Five people have 10 paths. Fifteen have 105. Fifty have 1,225.

Fred Brooks set this out in 1975, writing about software projects: if each part of a task must be coordinated with each other part, “the effort increases as n(n-1)/2” (Brooks, 1975). J. Richard Hackman, who studied teams at Harvard for decades, found that the number of links to be managed “goes up at an accelerating, almost exponential rate”, and that managing those links is what gets teams into trouble. His rule of thumb was “no double digits” (Coutu, 2009).

Take a payments startup that doubles from 20 to 40 people in the year after its Series A. If every hire ramps up perfectly, its capacity doubles. Its possible paths go from 190 to 780, four times as many. Not every path is used, but each is a place where work can wait, be duplicated or be decided twice.

Where the time goes

The cost of a path rarely appears as a line item. It shows up as the meeting that exists so three teams hear the same update, the decision that needs one more person in the room, the engineer who spends a morning finding out who owns a service. Each is small. Across hundreds of paths, they fill the working week.

People consistently underestimate this. Bradley Staats, Katherine Milkman and Craig Fox asked teams to build the same Lego model. Four-person teams used 52.64 person-minutes on average, against 36.33 for pairs, and the larger teams underestimated the effort by more. The same pattern appeared in data from 594 software projects. They called it the team scaling fallacy: the bigger the team, the more people underestimate the labour a project needs (Staats et al., 2012).

There is a human cost too. Jennifer Mueller studied 212 knowledge workers in 26 teams and found that people in larger teams performed worse, largely because they felt less support was available to them (Mueller, 2012). More colleagues can mean less help.

In the efficiency equation, every hire moves two terms at once.

THE TWO TERMS A HIRE MOVES
η=(Pₛ × I) + (R × A)eᵁ + N

A hire adds to resources (R) in the numerator and to network complexity (N) in the denominator. Hiring pays only while the first grows faster than the second.

The Entrepreneurial Efficiency Equation (η) · Dr. Hafiz Muhammad Ali

Customers add to N as well, through the exceptions you agree to. Headcount is the part you add yourself.

Structure bends the curve

The formula describes the worst case, in which everyone may need everyone. Structure is how you stop that from being true. Not every path has to exist, and the ones that do can be designed.

Group 48 people into eight teams of six, and let the team leads connect with one another. Inside the teams there are 15 paths each, 120 in total. Between the leads there are 28. That is 148 paths instead of 1,128, for the same headcount.

Same headcount, different paths

COORDINATION PATHS04008001,20011224364815 people · 105Everyone connected · 1,128Teams of six, leads connected · 148HEADCOUNT

Every person you add can connect to everyone already there. Structure decides how many of those paths actually have to exist.

This was the logic behind what Jeff Bezos called two-pizza teams: autonomous groups of fewer than ten people, small enough to be fed with two pizzas and meant to need little communication with the rest of the company (Stone, 2013).

Small teams only work with clear boundaries: what each team owns, what it promises the others and who decides when they disagree. A team without a boundary is not a team. It is a crowd with a smaller name.

Some paths are the point

Structure has a cost of its own. In a company of ten, everyone talking to everyone is not overhead. It is how a customer complaint reaches the engineer who can fix it before lunch, and how the founders hear bad news early. Cut those paths too soon and you lose the speed that made a small team worth joining.

So the aim is not the fewest paths. It is the right ones. Keep paths dense where the work is still being discovered and information has to move fast. Thin them where the work is understood and a handoff can be written down. Hackman’s “no double digits” is a useful signal: once one conversation can no longer include everyone, the company needs structure, whether or not anyone draws it.

Hire into a structure

The practical change is in how you hire. Before adding a person, decide where they sit, which paths they need and which paths the role should remove. A new engineering manager should reduce the paths between engineers and the founders, not add a layer on top of them. A second salesperson should take a territory, not join every deal.

The same test applies to a reorganisation. If it adds more paths than it removes, it is not a simplification, whatever the new chart looks like.

BEFORE THE NEXT HIRE

Which paths will this role add, and which will it remove?

  1. Who will this person need to work with every week?

    Count them. That number is the paths you are adding.

  2. Which existing paths does the role remove?

    If none, you are adding capacity and coordination in the same move.

  3. Which team does the role belong to?

    If the answer is everyone, the role needs a boundary before it needs a person.

  4. Who decides when this person’s work conflicts with another team’s?

    Without a clear tiebreaker, every disagreement becomes a meeting instead of a decision.

  5. Could a written handoff replace a standing meeting?

    Documents scale. Standing meetings multiply.

Headcount is the easiest number in a startup to raise and one of the hardest to reverse. Raised with the paths in view, each hire adds more than it costs to coordinate.

Hire people for the work. Design the paths before they arrive.

References

  • Brooks, F. P., Jr. (1975). The mythical man-month: Essays on software engineering. Addison-Wesley.
  • Coutu, D. (2009). Why teams don’t work [Interview with J. R. Hackman]. Harvard Business Review, 87(5), 98–105.
  • Mueller, J. S. (2012). Why individuals in larger teams perform worse. Organizational Behavior and Human Decision Processes, 117(1), 111–124.
  • Staats, B. R., Milkman, K. L., & Fox, C. R. (2012). The team scaling fallacy: Underestimating the declining efficiency of larger teams. Organizational Behavior and Human Decision Processes, 118(2), 132–142.
  • Stone, B. (2013). The everything store: Jeff Bezos and the age of Amazon. Little, Brown.
CONTINUE READING
THE FOUNDER LETTER

Think past
the obvious.

A monthly note on founder judgement, structural constraints, and building companies that remain coherent as they change.

Monthly. Considered. No noise.