Part III — Cultivating Organizational Flow · Chapter 46 · 3 min read · First Public Draft
Constraints
Different Capabilities, Different Conditions
The strictest requirement in the organization has a way of becoming everybody's requirement.
Jump to a chapter
Narrated with Microsoft's neural voice, not me — a recording.
Everyone Carries the Strictest Requirement describes what happens when a constraint written for one part of the organization becomes the constraint for all of it. This is the chapter about telling those needs apart on purpose.
It starts from something the observation only implies: different capabilities are supposed to run under different conditions. A capability handling highly sensitive information may need strong central control, a narrow set of approved technologies and considerable operational oversight. Another may need almost none of that. Both can be entirely right at the same time, in the same building — and an organization that cannot hold both is going to end up choosing one for everybody.
Boundaries are what make different choices possible
This is the less obvious argument for capability boundaries, and the one I now think matters most. They are not only a way of organizing responsibility — they are what lets an organization hold two different answers at once.
But that only works if the organization can actually separate them. If capabilities remain tightly coupled through shared data, shared infrastructure, shared processes and shared decision structures, the strictest requirement will keep spreading across the boundaries regardless of what the diagram says. You will have drawn separate boxes without creating separation.
None of which is an argument for every capability becoming an island.
Quite the opposite, and this is the part that gets lost when people take the argument too far. Shared capabilities, shared infrastructure and shared standards remove enormous amounts of friction. Identity, security mechanisms, platforms, information standards, common services — most of these become both easier and safer when they are shared, and an organization that separates everything has simply chosen a different and more expensive kind of friction.
The question is never sharing versus separating. It is where sharing helps, and where it entangles needs that were never alike.
Share what is genuinely common. Separate where the requirements meaningfully differ.
And this goes well beyond technology. Different capabilities may need different degrees of autonomy, governance, resilience, security and oversight — and the goal is not to maximize any of them. It is to give each capability the conditions it needs in order to create value.
That requires boundaries strong enough to preserve real differences, while keeping the organization connected enough to work as one thing. The balance will never be right, exactly, and it moves. But without the ability to tell different needs apart, an organization ends up designing everything for its most demanding case, and everybody carries the friction.
The shape of the choice
Which is the general form of something this paper keeps arriving at from different directions, and it is worth stating plainly once.
The goal is not maximum autonomy, and it is not maximum control. It is the minimum structure needed to preserve coherence, while letting value be created with as little friction as possible.
Minimum is doing real work in that sentence. Not no structure — an organization with none is not free, it is merely uncoordinated, and it will rediscover why the constraints existed somewhere around month eight. And not the safest possible structure either, because safety applied uniformly is how the most cautious corner of the organization ends up running all of it.
The useful question for any constraint is therefore narrower than is this a good control. It is: which capability does this genuinely belong to, and what is it costing everywhere it has spread beyond that?
This cultivates: Everyone Carries the Strictest Requirement, in Part II.