Part II — Seeing Organizational Flow · Chapter 13 · 3 min read · First Public Draft

Team size

How Much Can One Team Hold

Counting people tells you almost nothing. Counting how many separate things they must understand tells you most of it.

Reduces frictionHandoff loss

There is more advice available on how big a team should be than on almost anything else in organizational design, which is usually a sign that nobody has quite settled it.

Amazon’s two-pizza rule sizes a team by how many people you can feed. Dunbar’s numbers size it by how many relationships a person can hold in their head — and those numbers are considerably more contested than their popularity suggests, though the shape of the idea survives the argument. Agile orthodoxy lands on seven or eight and calls it experience, which is at least honest about where it came from.

All of them are approximating the same underlying constraint from different directions: a team should be small enough that everyone in it can hold the whole thing in their head. Not the whole organization. The whole of what they are responsible for.

Which is why headcount is the wrong number, and also the one everybody reaches for, myself included.

Team Topologies gives the constraint its most useful name — cognitive load — and it is a better sizing rule because it measures the thing that actually binds.

A team of five carrying four unrelated domains is overloaded. A team of nine carrying one coherent capability may be entirely comfortable. Counting people tells you almost nothing; counting how many separate things they must understand tells you most of it.

I have watched an organization “fix” an overloaded team by adding two people, which made the load worse — more coordination, more context to share, and the same four unrelated domains still sitting there. Then watched a different one fix it by moving one domain out, with no change in headcount at all, after which the team was visibly faster within a month.

And it explains why the capability is the right thing to draw the boundary around.

A capability is, by definition, coherent — a single thing the organization must always be able to do. Draw the team there and the cognitive load has a natural edge; the things they must understand belong together, so understanding one helps with the next.

Draw it around a technology, a system or a reporting line, and the team inherits whatever collection of unrelated concerns happened to end up in that box. Nothing about them helps with anything else. That is the same nine people, carrying much more.

What happens between teams is a design choice too, and mostly gets made by accident.

Not every team is the same kind of team. Some deliver a stream of value directly. Some provide a platform others build on. Some exist to raise competence elsewhere and then get out of the way — and that last kind is the one organizations forget to disband, at which point it becomes a permanent department looking for something to do.

The ways teams interact are equally a choice rather than a personality outcome. Close collaboration is expensive and should generally be temporary. Consuming something as a service is cheap and should be the default once the thing is stable enough to have an interface at all.

In this paper’s terms both of those are statements about friction. Collaboration is a handover you have chosen to keep, usually for a good reason, ideally for a stated period. A service is a handover you have removed.

The failure is rarely picking the wrong one. It is never noticing there was a choice — inheriting the interaction pattern from whatever the first integration happened to do, and then treating it as the nature of the relationship.

A team is not overloaded because it is small. It is overloaded because somebody drew a box around things that have nothing to do with each other.

Cultivating this: Drawing the Line Around a Team, in Part III.