Naming a capability changes nothing on its own. Someone still has to be arranged around it.

There is more advice available on this than on almost anything else in organizational design, and most of it converges on the same instinct from different directions. 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. Agile orthodoxy lands on seven or eight and calls it experience.

All of them are approximations of one underlying constraint: 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’re responsible for.

Team Topologies gives that constraint its most useful name — cognitive load — and it’s a better sizing rule than headcount, because it measures the right thing. 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.

Which is 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. 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.

The same book is equally useful on what happens between teams. 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 capability elsewhere and then get out of the way. And the ways teams interact are a design choice rather than a personality outcome — close collaboration is expensive and should be temporary; consuming something as a service is cheap and should be the default once the thing is stable.

Both of those are, in this paper’s terms, statements about friction. Collaboration is a handover you’ve chosen to keep. A service is a handover you’ve removed.

Where I’d add something the models mostly leave implicit.

Almost every model in this space was written for technology teams, and it shows in one specific way: the business perspective enters as a role rather than as authority. A product owner. A stakeholder. Someone who represents.

Representation is the problem, not the solution.

A team with a technical product owner has someone who can prioritize, translate and negotiate, and who cannot answer the question that actually blocks the work: should we do this at all, and what happens to the customer if we get it wrong? That answer lives elsewhere, so the team asks, and waits, and the handover the boundary was drawn to remove reappears wearing a different job title.

A team built around a capability needs someone in it who can decide about that capability — not describe what the deciders want. Someone whose judgement about the domain is trusted, who carries the consequences, and who does not have to check.

The clearest version of this I’ve seen wasn’t a technology team at all. A finance team wanted printouts — numbers checked by hand, line by line, against another set of numbers. It worked, in the sense that errors were caught, and it also meant a group of capable people spent days every month doing something a machine could do in seconds, because the people who understood what the checks were for and the people who could automate them were in different parts of the organization, talking through requirements documents.

One person from finance moved. Not as a stakeholder consulted at milestones — close enough to be asked a question and answer it the same hour. The printouts went away. Most of the manual validation became automatic. Quality went up, because once the checks were automatic the team could afford to run more of them than anyone would ever have done by hand.

Nothing else changed. No new technology. No new process. No reorganization. One handover disappeared, and the friction it had been generating, quietly, every week, went with it.

That is what “delivering to the business” actually costs. It sounds like good service. In practice it describes a structural boundary — a specification at one end, an acceptance at the other, and a gap in the middle where nobody truly owns whether the outcome solves the problem it was meant to solve. Both sides can perform perfectly and still deliver something nobody needed.

A team made up only of builders can build almost anything. But it cannot decide very much.

Staffing a team this way is harder than staffing it with a product owner, which is precisely why most organizations don’t. It requires giving up a person the business considers too valuable to embed in one team. And it is usually the single highest-return move available, because it converts the most expensive recurring handover in the organization into a conversation across a desk.

The test is simple enough to run this week. Take a team and ask what they had to escalate last month. If any of it was a question about the domain rather than about money or headcount, the team is arranged around the work but not around the decision.

A team you have to interrupt someone else to run is not a team. It’s a queue with a name.

Drawing the boundary right is necessary and it is not sufficient. Two teams given identical scope, identical headcount and identical authority will not perform identically, and the difference is not talent. It’s the conditions inside the line — which is where this part of the paper goes next.