Skip to content

Complexity tax

The complexity tax is the share of an organisation's capacity spent keeping itself in step rather than doing the work. It rises faster than the organisation does, because the number of connections between people grows faster than the number of people. Nobody is charged for it and everybody pays it.

Add a person to a group of ten and you add ten new relationships that have to be kept in step.

Why it matters when the plan changes

Capacity is planned as if it were additive. Two teams doing related work are assumed to have roughly twice the output of one. What actually arrives is twice the output minus the cost of the interface between them, and that subtraction is invisible in every plan because no line item holds it. Its size depends on how tightly the work is linked, not on how many people are added.

The tension is that the tax is usually paid deliberately. Splitting a function, adding a region or standing up a new product line all buy something real and all cost coordination. Studies of coordination neglect find that people routinely underestimate this cost when designing the split, and one estimate puts the resulting loss at 21% of an organisation's productive capacity. The question is never how to avoid the tax but whether the plan can afford the amount it is about to incur.

In practice

A single product team is split into three to move faster. Each team is measurably quicker on its own work. Delivery slows anyway, because every release now needs three sequencing conversations that used to happen in one room. The speed gain was real and smaller than the coordination cost it created.

Evidence

What it cannot tell you

The complexity tax describes a cost, not its cause; it does not say whether a given set of interfaces is necessary or wasteful. It is silent on which specific coordination to cut, and it cannot distinguish a plan that under-invests in coordination from one that over-invests, without separate analysis of the work itself.

How Atlas reads it

The tax is read at the dependency layer rather than counted in the abstract. What matters is which interfaces this plan runs through and whether each one is owned and sequenced, not how many interfaces exist. A structural change that adds interfaces to the critical path is marked as a cost the plan has to be able to carry.

Questions

Because the cost sits in the connections, not the people. Brooks's law, from Frederick P. Brooks's The Mythical Man-Month (1975), shows the number of communication channels rises rapidly with group size, so ten people create forty-five pairs and eleven create fifty-five. Each addition compounds the coordination already owed.

Not removed, only chosen. Any structure that divides work creates interfaces, and interfaces cost something to maintain. What can be changed is how many of them sit on the critical path of the current plan, and whether each of those has a named owner and a sequence.

Individual teams report good throughput while delivery slips anyway, often because commitments crossing functions are unreliable: Donald Sull, Rebecca Homkes and Charles Sull found in Harvard Business Review (2015) that only nine per cent of managers trust colleagues in other units all the time. That gap is the tax.

Sometimes, and rarely as cleanly as it looks. Recentralising removes interfaces and adds queueing at the centre, which is a different cost with a different shape. The useful comparison is which cost this specific plan can better afford, not which structure is generally superior.

By naming the interfaces the plan actually depends on and putting an owner and a date on each, before the structure changes rather than after. Most of the cost becomes visible at that moment, and most of it is avoidable only at that moment.