Decentralized control

Push control down to the people closest to the work for problems and opportunities that lose value quickly.

A perishable problem — a failing build, a customer about to churn, a test rig that just broke — is cheapest when it is handled in hours, not after a weekly review. Escalating it adds queueing delay at the decision maker, and the cost of delay keeps accruing the whole time.

Keep control central for problems that are rare, large, or that benefit strongly from economies of scale.

Choosing a cloud provider, a chip foundry or a company-wide auth library happens rarely, is expensive to reverse and pays off when done once for everyone. A central decision maker sees the whole system and is not overloaded by such infrequent decisions, so its queue stays short.

Choose the level of control as information about the problem emerges: start local, and escalate when it proves big.

Like a fire department that sends one engine and calls more when the fire grows, a team handles a bug locally and escalates only if it turns out to be a security breach. Triage rules (severity levels, spend limits) make the hand-off automatic instead of political.

Adapt the plan to obstacles and opportunities that the plan did not anticipate.

A plan is a hypothesis built on old information. When a customer interview reveals a better feature or an API turns out to be unusable, the team that can change course without a re-approval cycle captures the value while it still exists.

Be able to pull decentralized resources together quickly when a problem needs concentrated force.

Distributed teams handle everyday work locally, but a pre-agreed mechanism — an incident commander rotation, a swarm protocol — lets them mass on a severe outage within minutes. You get local speed most of the time and central power when it is needed, without a permanent central staff.

Decentralized control is less efficient, but that waste can cost far less than the value of a faster response.

Two teams may solve the same problem twice, and local decisions are sometimes slightly worse. That is acceptable when the alternative is a central decision maker running at high utilization, where queueing delay multiplied by cost of delay dwarfs the duplication cost.

Aligned effort across the whole creates more value than excellence in isolated parts.

Three teams each optimizing their own component can still miss the launch if their work does not converge on the same goal. Decentralization only works if units pull in the same direction, so alignment mechanisms are the price of local autonomy.

State the desired end state and its purpose, and impose as few constraints as possible on how to get there.

The Marines' commander's intent tells units why they are doing something, so they can improvise when the plan breaks. 'Cut checkout abandonment 20% by Q3 so we hit the revenue target' survives a vendor API being deprecated; a task list that says 'integrate vendor X' does not.

Define clear roles and boundaries so that independent units neither collide nor leave gaps.

Military units have sectors; teams need clear ownership of services, interfaces and decisions. Boundaries let a team act fast without coordinating every step, because it knows what is — and isn't — its call.

Name a main effort and make every other activity subordinate to supporting it.

Not every front deserves equal resources; the main effort is where concentrated effort produces decisive results. When a support team must choose between two requests, the one that helps the main effort wins — a decision rule that needs no escalation.

Be ready to shift the main effort quickly when conditions change.

Marines move the main effort to whatever unit finds a weakness. In product work, when one experiment shows ten times the expected lift, resources should flow to it within days, not wait for the next annual plan.

Beyond agreeing on the plan, agree on how you will stay aligned when the plan stops fitting reality.

The first agreement is the plan; the second is the shared intent and set of rules everyone falls back on once events overtake it. With that second agreement, teams that lose contact with each other still make consistent choices instead of waiting for new orders.

Coordinate tactical issues directly between peers rather than routing them through a central node.

Routing every interface question through a project manager doubles the message hops and turns the manager into a queue. Adjacent teams that talk directly resolve issues faster and leave the manager free for the few cross-cutting decisions.

Prefer simple, modular plans that can be reconfigured easily.

A plan with tight dependencies collapses when one step slips; a plan made of independent modules lets units substitute a different route to the same objective. Detailed plans are not useless, but their value is in preparation, not in faithful execution.

Keep some reserve capacity decentralized, close to where problems arise.

A reserve held at headquarters arrives late. A team that keeps 10–20% of its capacity uncommitted can absorb surprises — an urgent customer bug, a failed test — immediately, without pulling people off the main effort.

Engage the real problem early and meaningfully to uncover what the plan does not know.

Marines probe to find where the enemy actually is. Early prototypes, customer tests and integration spikes do the same: they reveal the true difficulty and the true opportunity while there is still time to shift the main effort.

If decisions are decentralized, make the information they need widely available.

Local decision makers can only make good economic decisions if they see priorities, cost of delay, and system state. Visible dashboards, open roadmaps and shared economic decision rules replace the request-for-information round trip to the center.

A system cannot respond to changes faster than its control loop can cycle.

If your observe–orient–decide–act loop takes a month (monthly steering committee), you cannot track a market that changes weekly; you are always acting on stale information. Shorten the slowest stage — usually the decision approval — to raise the frequency response.

When response time matters, measure response time.

Organizations that measure the efficiency of decision makers drive them to high utilization and long queues. If speed of response is what creates value, track time-to-decision and time-to-resolve explicitly, the way support teams track a service-level agreement.

Use internal and external markets to decentralize control.

Prices let people decide locally: if a shared test lab charges a premium for jump-the-queue service, a team decides for itself whether its cost of delay justifies paying, with no central arbiter. Buying outside capacity when internal capacity is congested is the same idea.

Initiative grows when it is used and supported, and withers when it is punished.

People who see their initiative rewarded take more of it; people who are criticized for well-intentioned mistakes stop taking it. Initiative is a capability the organization must cultivate continuously, not a switch it can flip when the plan fails.

Use the speed and bandwidth of face-to-face communication.

A conversation resolves an ambiguity in one round that an email chain needs several days and many messages to settle. Co-location, video calls and short daily meetings keep the coordination loop fast enough for decentralized teams.

Trust is built through experience.

Managers delegate more authority to people whose past decisions they have seen work out, and teams trust peers they have worked with before. Small batches, frequent interactions and stable teams generate many such experiences quickly, which expands the space of decentralized decisions.