Why does adding people to a software team often slow it down

Because the work is not divisible in the way a physical task is. Every new person adds communication paths, needs context that only exists in other people's heads, and increases the number of decisions that must be coordinated rather than simply made. Brooks named this in 1975: adding people to a late project makes it later, because the cost of onboarding and coordination is paid immediately while the capacity arrives much later, if at all.

What team size works best for digital product work

Small units of roughly two to four people with genuine domain ownership tend to work well, because they can adjust scope without negotiating and hold the full context of their area. The size matters less than the autonomy: a small team that cannot change its own scope has the coordination cost of a large one without the capacity.

Mass and energy

Some digital product companies achieve remarkable output with tiny teams. Why adding mass to a software organisation so often subtracts energy.

November 20, 2024

Some digital product companies achieve remarkable ratios between team size and results. An economist would say they have enormous productivity.

Bluesky post by Jay: Bluesky's team consists of about 20 full-time employees, a million users per employee

A million users per employee. The relationship between mass and output is not the one you would expect.

Mario shared this other classic example.

Interview clipping: five people worked on the preliminary planning of Super Mario 64 and 20 to 25 in the final stages, averaging 15 to 20 people over roughly two years

Super Mario 64: an average of 15 to 20 people over roughly two years.

We know there is an inverse relationship between mass and energy. And yet product teams often grow abruptly, particularly during hypergrowth, at exactly the moment when the temptation is strongest and the cost is highest.

The nature of digital creation means that imbalances between mass and energy tend to have severely negative effects.

The work does not divide

Because of its non-linear nature — a problem is not a task list — software work rarely benefits from adding people with the intention of going faster. Everything slips, and what could have been an atomic problem ends up systemic.

The Mythical Man-Month remains the classic statement of this, and it is worth being precise about the mechanism, because the book gets cited more often than it gets read. Brooks's claim is not that people are useless. It is that the cost of a new person is paid immediately and the capacity arrives later, if it arrives. Onboarding consumes the time of exactly the people who were already the constraint. Meanwhile the number of communication paths grows quadratically while the work does not.

Herbert Simon's work on the architecture of complexity gives the more general version. Systems become tractable when they decompose into nearly independent parts. When they do not decompose — when everything touches everything — adding parallel capacity buys you coordination, not throughput.

Divide and conquer applies to teams too

The usual engineering reflex works here as well. When organisations grow, the healthy tendency is towards verticals or thematic product teams with their own domain knowledge and small structures — two to four people — with the authority to adjust scope as they go.

The size matters less than that last clause. A team of three that has to negotiate every scope change carries the coordination cost of a team of thirty without the capacity. Skelton and Pais made the useful move of treating team boundaries as an architectural decision rather than an HR one, which is the practical consequence of Conway's law: the system you ship will resemble the communication structure that built it, whether or not anyone intended that. If you want a modular product, you need modular teams, and you need them before the code exists.

Amazon's single-threaded ownership model is the same insight arrived at commercially: one person, one problem, no shared attention. What makes it work is not the headcount but the absence of division in the owner's mind.

Mass generates uncertainty

Because of the nature of software and the uncertainty that accompanies it, handling more mass increases the probability of more uncertainty. This tends to become a vicious circle, and it is the part that gets least attention.

More people means more code, more services, more integration points, more deployment surface, more places where a change has consequences nobody predicted. The reasons software products are so difficult do not scale linearly with the organisation. They compound. The oil-stain quality of software means that mass added at the edge shows up as opacity at the centre.

Reinertsen's queueing arguments explain the visible symptom. Loading a system towards full utilisation destroys its responsiveness long before it destroys its capacity, so an organisation can look busier every quarter while shipping less. It feels like a discipline problem. It is a physics problem.

Ohno arrived at the same conclusion from the factory floor without any of the mathematics: excess capacity hides problems, and hidden problems are the expensive kind. The Toyota instinct was to reduce until the system started to complain, because a system that complains is a system telling you where it actually hurts.

None of which is an argument for staying small as a virtue. It is an argument for knowing what you are buying. Mass is purchased in one currency and paid for in another, and the invoice arrives in the form of a coordination meeting nobody remembers scheduling.