Part III — Cultivating Organizational Flow · Chapter 39 · 5 min read · First Public Draft

Team boundaries

Drawing the Line Around a Team

Where the boundary goes decides how much a team has to hold, how often it has to ask, and whether anybody chose any of it.

Reduces frictionCreates valueHandoff loss

How Much Can One Team Hold makes the case that headcount is the wrong number and cognitive load is the right one. The Team That Has to Ask shows what it costs when the judgement a team needs sits on the other side of the line. This is the chapter about drawing that line deliberately, which is cheaper than almost anything else in Part III and gets done less often.

Count what they have to understand, not who they are

The move is unglamorous. Sit with a team and list the separate things they have to understand well enough to be trusted with — not the systems they touch, the domains they have to reason about. Four unrelated ones in a team of five is a heavier team than one coherent domain in a team of nine.

Then look for the one that does not belong. There usually is one, and it usually arrived because somebody needed a home for it at short notice and this team had a person who knew about it.

Moving it out costs a negotiation and no headcount. I have watched that produce a visibly faster team inside a month, and watched the alternative — adding two people to an overloaded team — make the load worse, because now there was more context to keep in sync and the four unrelated domains were still sitting there.

A capability is the boundary worth reaching for, because a capability is coherent by construction. The things inside it belong together, so understanding one helps with the next. Draw the line around a system, a technology or a reporting line instead, and the team inherits whatever collection of unrelated concerns happened to land in that box.

Put the judgement inside the line

This is the one I would reach for first, and it is a staffing decision rather than a process one.

Find the person the team keeps waiting on — the one whose judgement is needed before anything can be called finished. Move them inside the team. Then let them decide without checking, which is the half that gets skipped and the half that matters.

It will cost somebody a person they consider too valuable to embed. That objection is genuine and usually wrong: the specialist spread across six teams is not being leveraged, they are being queued, and the leverage everyone believes they are getting is mostly other people waiting politely.

Nothing else I have tried converts a recurring handover into a conversation across a desk. And when the competence genuinely cannot be embedded — there are three of them in the company and eleven teams need them — the honest answer is not a better queue. It is to look at what they are actually being asked for, and how much of it could be settled once, written down, and stop being a question.

Choose the interaction rather than inheriting it

Teams are not all the same kind of team, and the way two of them work together is a design choice that mostly gets made by accident — inherited from whatever the first integration happened to do and then treated as the nature of the relationship.

Close collaboration is expensive and should generally be temporary, with a stated end. Consuming something as a service is cheap and should be the default the moment the thing is stable enough to have an interface at all.

In this paper’s terms that is a statement about friction rather than about org design. Collaboration is a handover you have chosen to keep, usually for a good reason. A service is a handover you have removed.

So the useful review is short: for each pair of teams that work together regularly, ask which of the two this is, whether anybody chose it, and — if it is collaboration — what would have to be true for it to end.

Let people place themselves, when the ground can take it

The best version of this I have been part of took less than two days. Everyone in a room, one rule — every product needs a team with all the competences required to succeed — and no manager deciding who went where. What they optimized for was the products, not themselves. Every team left knowing why it existed and what it owned, and nobody could say management put them there.

I would recommend it, with one caution I would rather give than leave out: the self-selection was not the active ingredient. Run the same exercise where the last three reorganizations were announced rather than discussed, and you get a room waiting to be told the right answer, followed by a quiet renegotiation afterwards by whoever has the most political capital.

What made it work sat underneath. People were trusted visibly, in a way that would have been embarrassing to walk back. They understood the purpose well enough to trade off against it. And they built the structure together rather than being handed one and asked for comments.

Which suggests the honest sequence. If the conditions are there, self-selection is the cheapest way I know to convert them into ownership. If they are not, the exercise will tell you so within an hour, and that is worth knowing too.

The smaller version works in almost any organization and is worth doing more often: whenever a boundary is about to move, bring the people it will move into the room while the decision is still genuinely open. The earlier distinction matters here: responsibility is much easier to take when you had some part in shaping the decision.

What this does not fix

A well-drawn team boundary removes handovers. It does not, on its own, tell the team what it is for, and it does not survive the next reorganization unless somebody is tending it — which is why the boundary worth drawing is the one that matches something durable rather than something current.

Boundaries drawn around capabilities tend to survive. Boundaries drawn around projects, systems or the current leadership arrangement get redrawn with them, and every redraw spends the understanding the last one built up.

This cultivates: How Much Can One Team Hold, The Team That Has to Ask and Nobody Could Say Management Put Me Here, in Part II.