Impeding the Flow of Value in Self-Managing Systems

Every leader who has tried to “let go” of control faces the same balancing act: hand teams too little room to navigate and to decide for themselves, and initiative is mired under disaffection, disengagement, and approval chains; give them too much (especially too fast!), and the organization drifts into confusion, localized optimizations, and quietly duplicated effort. As with any balancing act, most advice is binary: centralize or decentralize, control or trust; as if the dial only had two settings, and the problem was as simple as a choice.

In a system, impedance is the opposition a system experiences to the flow of current. There are two parts: resistance, which dissipates energy as waste, and reactance, which controls the storage and release of energy, and controls its timing. A well designed system doesn’t try to eliminate impedance (an unimpeded system overloads and breaks), or maximize it (which grinds everything to a stop). The aim is to match the system’s opposition to the flow, so value travels from source to destination with as little waste as possible. Impedance is the pipe whose size we try to match to the amount (of value) flowing through it.

Our organizations can be viewed, at every level, as systems attempting to move value (a decision, a unit of work, a service) from wherever it’s created to whoever is depending on it (regardless if that’s an external customer, or an internal one two desks over).

Power & control function very much like resistance.
Constraints behave like reactance.
Goals define what value is supposed to flow (a plan, a design, an interface…).
Accountability is the signal that tells you whether it arrived.
And autonomy isn’t a simple dial for us to turn, it’s a capacity that has to be matched to a system built to carry it… or else something breaks.

1. Goals and value: what’s flowing

Before you can tune anything, you have to know what you’re tuning it for. In this model, goals power the source, and value is what moves from the source, to the people who need it downstream (whether internal or external).

Morning Star, the flat structured tomato-processing company (known for having no managers or job titles), builds this directly into its system’s structure. Every colleague writes their own personal mission, (a Colleague Letter of Understanding, or CLOU), and they negotiate their commitments with seven to twelve fellow colleagues whose work is dependent on their own. Each CLOU is, effectively, a supplier-customer agreement between peers: it clarifies what will be delivered, to whom, and by what measure of quality. Goals define what value is before its flow can be assessed.

2. Power & control: what’s resisting

Resistance (like resistors) dissipates energy as wasteful heat. This is valuable in low energy systems where it protects fragile parts of the system from too much force (gatekeeping). But resistance is destructively obstructive in high energy systems, where large amounts of value (decisions, work-volume) would be wasted. Hierarchical power and top-down control behave the same way. Small amounts of control, judiciously applied, protect the organizational system from genuinely catastrophic decisions. Too much, and the organization’s efforts are lost to the friction of approval queues, status updates, and compliance audits.

The aim here isn’t to remove power and control from a system, it’s to find the least amount of resistance necessary to protect the system from itself.

The Gore Lattice Organization, another non-hierarchical structure, permits associates to act freely on all things; except those that can threaten the organization itself. These decisions are made with peers who have relevant experience.

3. Constraints: how reactance empowers

Reactance stores and releases it, shaping its tempo. A well-designed constraint (a spending boundary, a decision-rights line, a fixed point calendared to revisit a particular decision) shapes the timing and direction of the flow of value so it arrives as needed, where it’s needed.

A constraint makes autonomy possible by defining and designing how value flows. It’s a boundary in place to keep value flowing as best it can without breaking things. Poorly designed, nebulous constraints, create an unprotected domain where someone will eventually feel the need to step back in to control it. A good constraint allows a leader to let go of something, without letting that thing fall.

Morning Star’s CLOUs are commitments, deliverables, and performance measures negotiated peer-to-peer. They guide workers as they navigate their own decision-making. Likewise, Gore’s waterline principle (consult before anything that could seriously damage the company) replaces the kinds of structures that produce friction, delays, and wasted effort, with the kinds that monitor and guide the flow of value.

Some practices to keep constraints effective:

A constraint that is never reviewed, becomes friction or gets forgotten.

Set the boundary according to the stakes, not the role. A low-cost, low-stakes decision is easily reversed and needs few boundaries. Gore’s “below the waterline” test is a powerful guide for when a boundary needs to be strong and clear. Political economist Elinor Ostrom, studying centuries-old, self-governing communities, found that when rules are proportional to local conditions, rather than uniform across the board, the institutions endured.
Make the boundary visible and specific. “Use good judgment” isn’t a constraint; it’s a trust fall with only one person in the room. Try “spend up to $2,000/month without sign-offs” or “changes that affect another team’s CLOU require their input and approval.”
Monitor with a signal someone looks at, and can see at all times. Morning Star’s ‘Steppingstones’ (the performance metrics attached to each CLOU) exist to make all constraints visible to the people they affect as well as those that set them.
Respond proportionately, and offer low-cost resolutions for disputes. Ostrom’s research found that the more enduring self-governing systems used graduated responses to boundary violations (a conversation, then a warning, then more severe sanctions) and a conflict-resolution process that was low in cost.
Revisit on a schedule, not under pressure. A CLOU can be revisited, and renegotiated at any time; it’s a living boundary. Fix a time to review constraints, even if nothing goes wrong, before anything does.

4. Network autonomy within a system

Every organizational system is a network of smaller systems. Each locally manages the flow of value for their connections, and acts as stewards of the flow of value for the system as a whole.

In a network built from many stages, each stage is matched to the ones next to it, not to the system as a whole — a subsystem can operate independently as long as what it hands off, and what it expects in return, is well specified at the boundary. Buurtzorg (a Dutch home-care organization) has roughly 900 self-managing teams (ten to twelve nurses, serving fifty to sixty patients). Each team owns its own scheduling, intake, hiring, and budgeting. The team doesn’t need permission from the network to act, because the interface between the team and the network is a layer designed to keep the connections between nodes properly matched as the network grows. It is not designed to run, or be run by, any individual node. Buurtzorg’s roughly twenty regional coaches, each supports forty to fifty teams. They don’t manage teams, they safeguard the framework that lets teams manage themselves. They step in only when a team’s local match to the wider system experiences friction.

Ostrom found the same architecture in the self-governing communities she studied: durable systems were rarely a single flat layer of autonomous individuals, they were many small, locally autonomous units nested within larger structures that coordinated effectively without surrendering their autonomy to the authority of the whole.

The goals of a node orient it primarily toward its own domain. Individual nodes tend to see their own small-picture view of things, more often than the big-picture view of how all the nodes fit together (the forest for the trees). So that vantage has to be built on purpose. Buurtzorg’s coaches aren’t just an escalation layer, they’re a whole-picture view unconstrained by any one domain.

Design autonomy person by person. Design it node by node, and design the interfaces between nodes as carefully as you design what happens inside them.

5. Encouraging autonomy: capacity, accountability, and feedback

Autonomy, for the self-governing team and the systems they are a part of, is predicated on feedback. A node with no path for a signal to return isn’t self-managing; it’s disconnected. Attempting autonomy before structuring feedback is a common failure when trying to flatten an organizational system.

Ostrom’s research suggests durable self-governing institutions consistently built in ways to monitor whether commitments were being kept and low-cost ways to resolve conflict when they weren’t; this is feedback. Morning Star’s CLOU commitments are made directly between colleagues rather than to a manager, the renegotiations and immediate visibility to the internal customer is also feedback.

Autonomy, applied to an organization, is a bit like voltage pushed through a system that was designed for something else. Increase it faster than the structure can handle, and it overheats; the capacity to sustain it is exceeded. When managers ‘wave their hand at it’ and say “we trust you to figure it out,” the flow is changed without the structures to support it, or the feedback to signal the problem early, when it’s cheap to fix.

6. Mastering autonomy: retuning the network over time

A network tuned for one set of conditions is a mismatch for another. What’s proportionate at ten people, is underdeveloped for a hundred. A constraint in a stable organization facing familiar inputs and challenges, is poorly matched during a crisis. A working relationship based on agreements made when two teams sat next to each other in an office, flounders when the teams are distributed and time zones, not walls, sit between them.

Mastery of autonomy, isn’t a fixed state, it’s the capacity to recalibrate, revise, and adapt continuously as conditions inevitably change. Buurtzorg’s coaching layer exists to respond to these changes and to recalibrate from a whole-picture point of view.

Being that the flow (capacity of the channels delivering it, resistance it meets, how the customer responds) of value (what is of value, how it connects the system) and feedback (the return path) can only be understood from a whole-picture full systems perspective, it follows that it can only be assessed by its outcomes (whole-picture) rather than outputs (small-picture). Every node in a well-matched network can be hitting its own local targets (the outputs it’s directly measured on) while the network as a whole has already drifted out of tune; outputs are visible from inside a single node, but whether or not the network is still aligned with the organizational purpose can only be seen from the whole-picture view. This connection is invisible to even the most committed practice of recalibration that only looks at the metrics of the node.

The build system: seven steps

Step 1: Enumerate the goals with the customer. For any team or role, work with the customer (internal or external) to determine what value is needed and how it should be defined. If you can’t name the customer, the outcome will be little more than a guess.

Step 2: Map where value is currently being lost. Walk a handful of recent decisions end-to-end and time them. Where did they stall? Was the delay protective (catching an error, revising a plan to low risk) or just friction? Separate the two. We’re not looking for less structure, fewer constraints, or even more, we’re looking for waste.

Step 3: Set constraints, not permission rules. For each decision area, see if you can replace “ask before you act” with a proportionate (to how costly and reversible the decision is) sized boundary that allows people to act without asking (this is friction). Try to be specific enough that different teams, or contexts, would see it applied the same way.

Step 4: Define the interfaces between nodes. Every team or role depends on someone else’s output. Clarify expectations and means to manage the timing, between teams not just within them. Allowing each node to act autonomously and to manage their own changing needs, without needing to check in with the whole network.

Step 5: Build the feedback path before expanding autonomy. Ensure there’s a visible way to know a commitment was kept, a graduated way to respond if it wasn’t, and a low-cost way to resolve conflicts that arise. Don’t grant more autonomy until this exists.

Step 6: Increase capacity in managed increments. Expand autonomy tied to demonstrated competence, not tenure, political clout, or promises. Match each increase to the customers they affect.

Step 7: Schedule recalibration. Calendar fixed intervals (quarterly, at relevant milestones, by external cues like market seasons) to check whether the current tension settings between goals, constraints, and autonomy need adjusting. Treat this the way Buurtzorg treats their coaching layer: a standing mechanism devoted to the feedback signals that indicate when the flow of value needs to take a different shape.

Common pitfalls

Removing constraints instead of converting them. Flattening hierarchy without refining boundaries creates friction and conflict. Nothing gets defined, shaped, or timed, becoming a worse outcome than the bureaucracy everyone was trying to escape.
Increasing autonomy before the surrounding structure can carry it. Autonomy before competence, clarity, or a working feedback path reliably produces burnout, not engagement. The outcome self-determination research describes when only one of the three basic needs is addressed.
Skipping purpose and going straight to structure. Constraints, interfaces, and accountability mechanisms designed without a clearly named customer often fail despite technically being well-built. When value flows aren’t matched to the customer, the customers are the first to experience it, not the teams or roles creating it.