Decentralized Control

Definition

Drawing on U.S. Marine Corps maneuver-warfare doctrine, Reinertsen argues that organizations should decentralize the authority to act — not just decentralize responsibility — for problems and opportunities that are perishable (they get worse or disappear quickly if not addressed immediately), while centralizing control for problems that are infrequent, large, or benefit from economies of scale. The choice is never all-or-nothing: the right answer, as in the military, is "decentralized execution supported by centralized coordination."

In the Book

Chapter 9 opens by dismantling the assumption that militaries are rigidly top-down: the Marine Corps instead relies on the initiative of subordinates because it treats warfare as inherently uncertain terrain where the side that best exploits uncertainty wins, and because information about the unfolding situation is visible first to troops closest to the front line. Principle D1, "The Second Perishability Principle," uses fires as the illustration — a small fire, addressed immediately by whoever is nearest with a pre-positioned extinguisher, never becomes a big one, and nobody has to seek approval or walk to a supply closet first — and extends this to fleeting market opportunities, citing how Sony and HP beat IBM to the 3½-inch floppy disk standard while IBM was still developing its own next-generation format. Principle D2, the counterweight, argues that big fires need fire trucks, not individuals with garden hoses: centralizing a scarce, expensive resource (like a regulatory-affairs expert shared across many projects) is correct when demand is infrequent and pooling variable demand improves response consistency across the whole organization.

Why It Matters

This reframes "decentralize decision-making" from a blanket cultural preference into a falsifiable test: does the problem age quickly, and is local information decisive? Then decentralize, and pre-position the resources (not just the authorization) needed to act. Is the problem rare, large, or does pooling create economies of scale? Then centralize. The same logic explains why product development organizations that centralize everything "for consistency" pay for it in slow reaction to fast-moving problems, and why cost of delay is the variable that tells you which category a given decision falls into.