Decentralize Decision-Making: SAFe Principle #9
Decentralize Decision-Making clears SAFe's approval queue, but Samsung's Note 7 recall shows centralization wins instead. Four dials tell you which.
Decentralize Decision-Making sounds like permission granted. In SAFe it’s closer to a diagnosis: Principle #9 exists because centralized approval creates a queue of decision requests no organization can clear fast enough, and pushing authority downward only works once the people receiving it actually use it.
Where this article sits
Journey stage 1 of 7: Readiness
readiness → use-cases → roi → pilots → kpis → operationalize → scale
Your trail so far
The articles you visit light up on this map.
What Decentralize Decision-Making Means as SAFe Principle #9
Principle #9 in SAFe’s ten Lean-Agile Principles instructs organizations to push decisions down to the people closest to the work, on the reasoning that knowledge workers holding local information and technical skill decide faster and better than a centralized authority reviewing from a distance. SAFe states this as a value judgment, but the mechanism underneath it behaves like a design flaw: when the decision doesn’t move, the person who owns the work stalls behind it, and the stall compounds every time another decision joins the same queue.
Principle #9 as SAFe States It: Jim Collins on Pushing Decisions Down
SAFe opens its statement of Principle #9 with an epigraph from Jim Collins, author of Good to Great, Built to Last, and Beyond Entrepreneurship, framing decentralization as a defining trait of organizations that consistently outperform their peers. Collins’s words, as SAFe cites them directly: “The most innovative companies tend to push decisions as far down in the organization as possible, giving people at all levels the opportunity to move fast, utilize their creativity, apply their intellect, and assume responsibility” (SAFe). SAFe frames this as one of ten Lean-Agile Principles, sitting alongside Principle #8’s focus on unlocking intrinsic motivation of knowledge workers. The two are meant to reinforce each other, though the leadership habits that actually connect them go unstated in the principle set itself.
Reading the epigraph as strategy rather than sentiment changes what it asks of a reader. Collins wasn’t describing a values preference; he reported a pattern across companies studied over years, where speed and creativity correlated with how far decision rights had moved from the center. SAFe’s adoption of the line signals that Decentralize Decision-Making isn’t a culture slogan bolted onto agile ceremonies; SAFe positions it with the same status as taking an economic view or applying systems thinking, two of the other Lean-Agile Principles that share the same page.
Why Centralized Authorities Decide Things Knowledge Workers Should
Centralized authorities keep deciding things closer to the work because historical top-down culture, limited trust, and a bias toward control outweigh the local information advantage the people doing the work actually hold. SAFe names three specific causes rather than a general resistance to change: organizations built under command-and-control structures carry the habit forward after the market conditions that justified it disappear; managers who haven’t built trust with their teams default to reviewing decisions themselves; and control gets treated as a proxy for efficiency, even when the review step adds delay without adding accuracy.
The knowledge worker distinction matters here. A knowledge worker closest to a customer interaction, a system dependency, or a technical constraint has current, granular information that a manager one or two levels up usually doesn’t. The gap has little to do with the manager’s ability; information decays as it travels up a hierarchy and gets summarized at each hop. By the time a decision request reaches someone with formal authority to approve it, the person approving is working from a compressed version of what the person requesting already knew in full. Centralizing the decision doesn’t add judgment; it adds a translation step and a wait.
The Decision Queue: SAFe’s Own Bottleneck Mechanism
SAFe names the cost of centralization directly: when managerial input is required for most decisions, it creates a queue of decision requests that blocks progress and delays the people doing the work. The mechanism is structural rather than personal: it doesn’t depend on any manager being slow or any team being incompetent; it depends on the arithmetic of routing every non-trivial call through a small number of approvers while the volume of decisions needing a call keeps growing with the organization’s scope.
The Agile Alliance’s research on decision-making systems supports the same diagnosis from a different angle: decision quality and speed are properties of how a decision-making system is designed, who holds the right to decide, what information reaches them, and how fast the decision reaches the person who needs it, not properties of who individually holds the authority (Agile Alliance). Read against SAFe’s own queue language, this reframes the fix: adding more capable managers to the approval chain doesn’t relieve the queue, because the queue is a property of the chain’s structure, not the people staffing it. Only redesigning where the decision right sits removes the bottleneck.
Why Speed Makes the Old Model Break Down
Centralized approval chains that once absorbed decision volume without much cost now fail structurally, because disruptive technology, high interconnectedness, and intense competition compress the window in which a decision still matters. SAFe frames this as a shift in the operating environment rather than a change in organizational virtue: the same approval chain that was tolerable when competitors moved slowly becomes a liability once a market opportunity or a technical risk can change shape within days.
The Three Forces That Outrun Centralized Structures
Disruptive technology shortens how long any given advantage holds, which means a decision delayed by a week can arrive after the opportunity it targeted has already shifted. High interconnectedness means a problem surfacing in one part of a system, a dependency, a customer segment, an integration, propagates into adjacent parts faster than a status update can travel up a hierarchy and a decision can travel back down. Intense competition removes the margin that used to absorb slow decisions: when several competitors can act on the same signal, the first mover typically keeps the advantage that a slower, better-reviewed decision would have earned.
None of these three forces existed at the same intensity when many enterprise decision-making structures were designed, which is why applying Principle #9 reads as correction rather than innovation. Organizations that keep the old approval chain running under the new conditions don’t get more careful decisions; they get decisions that arrive too late to matter, reviewed by people further from the information than the person who first identified the problem.
What SAFe 6.0 Observed in Digital-Native Leaders
SAFe 6.0’s own Decentralizing Control material reports that DevOps-Agile leaders at digital-native companies carry more autonomy and empowerment than leaders at traditional companies, and traces the difference to how effectively those companies decentralize decision-making rather than to any difference in talent or funding Decentralizing Control (SAFe). The observation lines up with independent research: MIT CISR’s 2022 Decision Rights for the Digital Era survey found that large decentralized organizations sensed and seized opportunities in roughly 244 days, against 566 days for large centralized organizations, with net profit margins 6.2 percentage points higher and revenue growth 9.8 percentage points higher than centralized peers Digital Era (MIT CISR).
The gap isn’t a rounding difference: a decision that takes well over a year to reach the market instead of under nine months has usually already lost the window that made it worth deciding on. SAFe’s own observation about digital-native leaders and MIT CISR’s measured gap describe the same underlying pattern from two directions: the organizations built to decentralize aren’t just more comfortable, they’re faster on the specific metric that determines whether a decision still matters when it lands.
The Architecture Advice Process: Harmel-Law’s Four Supporting Elements
The Architecture Advice Process is a named technique from Andrew Harmel-Law that lets any engineer make an architectural decision without routing it through a central architect, provided they first seek advice from everyone materially affected and from anyone with relevant expertise. Decentralizing a principle is one thing; running a specific decision through a specific method that other organizations have already used is another, and the Advice Process is the clearest example of what “decentralize decision-making” looks like once it’s operationalized rather than declared.
The Advice Process: Anyone Can Decide After Seeking Advice
Andrew Harmel-Law’s Advice Process, published as Scaling the Practice of Architecture, Conversationally (Thoughtworks, December 2021), reframes architecture as a series of conversations rather than a monologue delivered top-down from a centralized few Advice Process (Martin Fowler). The fundamental rule is stated plainly: anyone in the organization can take an architectural decision, on the condition that they first seek advice from everyone who will be meaningfully affected by it and from anyone holding relevant expertise on the topic.
The rule inverts where authority sits without removing rigor from the decision. A decision-maker who skips the advice step hasn’t broken a policy so much as skipped the mechanism that made the decentralized model trustworthy in the first place: the advice-seeking step is what lets an organization decentralize the decision right without also decentralizing away the expertise that used to sit with a central architect. The decision-maker still has to synthesize conflicting input, weigh trade-offs, and own the outcome; what changes is who has standing to make the call.
Harmel-Law’s Four Supporting Elements
Harmel-Law names four supporting elements that make the Advice Process function as a repeatable technique rather than a one-off exception: Decision Records, an Architecture Advisory Forum, Team-Sourced Architectural Principles, and a Technology Radar. Each element handles a different failure mode the Advice Process would otherwise run into; losing the reasoning behind a decision, lacking a venue for the advice conversation, drifting toward inconsistent goals across teams, and losing track of which technologies are safe to adopt.
Decision Records and the Architecture Advisory Forum
A Decision Record is the thinking-and-recording tool Harmel-Law specifies for the Advice Process: a written artifact that captures the decision, the advice sought, who was consulted, and the reasoning that led to the final call. Without it, the advice-seeking step becomes invisible after the fact: a later engineer inheriting the decision has no way to tell whether it was made carefully or made in isolation, and the organization loses the ability to audit or revisit the reasoning when conditions change.
The Architecture Advisory Forum supplies the time and place where those conversations actually happen: a recurring venue where anyone about to take an architectural decision can bring it for advice before committing. The Forum matters because “seek advice from everyone affected” is unenforceable without a concrete mechanism for finding those people and getting time with them; a standing forum turns an abstract obligation into a scheduled habit, which is what keeps the Advice Process from quietly reverting to informal gatekeeping by whoever happens to be senior in the room.
Team-Sourced Principles and a Technology Radar
Team-Sourced Architectural Principles function as the light that illuminates a unified goal across teams making independent decisions: a shared, bottom-up set of principles derived from the teams themselves rather than handed down, so that decentralized decisions still converge on a coherent direction instead of fragmenting into incompatible local optima. Without this element, decentralization risks producing technically sound decisions that collectively pull the architecture in contradictory directions.
A Technology Radar is the tech-landscape sensing tool: a shared, regularly updated view of which technologies the organization is adopting, trialing, assessing, or holding, so a team deciding independently still has current information about what the rest of the organization has already learned. Together, the four elements convert Harmel-Law’s rule, anyone can decide, provided they seek advice, from an aspiration into a technique with recording, venue, direction, and awareness built in.
What Happens When the Advice Conflicts?
The Advice Process doesn’t ask a decision-maker to average competing opinions or defer to whoever is most senior in the room; it keeps the decision with the person who sought advice while holding them accountable for reconciling what they heard. When two people consulted for advice give contradictory recommendations, the decision-maker still has to weigh which concern matters more for the specific call at hand, record that reasoning in the Decision Record, and be ready to explain the choice to anyone who advised differently. This is where the process differs most sharply from a consensus model: it never requires unanimous agreement before a decision can proceed, only that every relevant voice was heard before the decision-maker decided on an answer. A decision-maker who can’t explain why they weighed one piece of conflicting advice over another hasn’t actually used the process; they’ve collected opinions without doing the synthesis the role requires.
Why the “Ivory Tower” Architect Role Doesn’t Scale
The traditional “ivory tower” and “hands-on architect” models for the architecture role don’t scale past a certain organizational size, because both concentrate decision-making in a person or small group that becomes the queue every architectural decision has to pass through. Ben Linders’ InfoQ report on Harmel-Law’s GOTO Copenhagen talk states this directly: both memes for the architecture role create bottlenecks to flow rather than removing them, whether the architect is remote and disengaged from daily work or personally hands-on and therefore a single point of contention for every decision GOTO Copenhagen (InfoQ).
The role change Linders reports follows from the same logic that runs through Thoughtworks’ own Technology Radar practice and Harmel-Law’s advice model: the architect’s job shifts from decision-maker to conversation starter and guide, driving just-enough shared understanding and creating space for teams to learn the judgment an architect used to hold exclusively. An architect operating this way spends less time approving and more time making sure the right people are in the advice conversation: a genuine change in daily work, not a title change layered over the same gatekeeping.
Learning from Slime Mold: A Natural Model for Decentralized Decisions
Physarum polycephalum, slime mold, built a transportation network from purely local decisions that matched a human-engineered rail system in structure and beat it in efficiency, with no central planner involved at any point. The result matters to a skeptic of decentralization for a specific reason: it demonstrates that local decisions made with local information aren’t merely tolerable in the absence of central planning, they can outperform it.
The Tokyo Experiment: How Slime Mold Grew a More Efficient Network Than the Subway
Researchers studying Physarum polycephalum placed food sources at positions corresponding to cities around Tokyo and observed how the organism responded, a case InfoQ’s Peter Hunter cites as a natural-world proof that decentralization can outperform central design rather than just persists without it Peter Hunter (InfoQ). The slime mold spread out from its starting point, sensing nutrients and repellents locally and making local decisions about which direction to grow next: no cell in the organism had access to the full map, and none was coordinating the others.
Over time, the slime mold built a network of nutrient-carrying tubes connecting the food sources that resembled the actual Tokyo rail network in several places, but ran more efficiently by the measures researchers applied. The comparison lands because Tokyo’s subway system is itself the product of extensive centralized planning by transportation engineers working with a full system view; and an organism making purely local decisions converged on a structurally similar solution without ever holding that view. Local sensing paired with local action, repeated across enough independent points, produced a result centralized planning would have needed significant deliberate effort to match.
Disbelief, Excitement, Consequences, Self-Correction: The Four Phases Teams Move Through
Teams that decentralize architectural decisions move through four phases of decentralization, disbelief, excitement, consequences, and self-correction, a sequence Peter Hunter reports from watching the transition happen in practice, which reframes the wobble teams feel midway through as expected rather than as evidence the change is failing. Naming the phases in advance changes how a leader reads the second half of the sequence: consequences and self-correction aren’t a sign that decentralization was a mistake, they’re the part of the pattern that was always going to happen.
Disbelief and Excitement: The Early Reaction
Disbelief is the first phase: teams that have operated under centralized architectural review for years often don’t initially trust that the authority to decide has actually moved, and continue routing decisions upward out of habit even after the formal process has changed. Excitement follows once teams test the new authority and find it real; decisions that used to wait for a review cycle now move immediately, and the pace change itself becomes motivating, sometimes producing a burst of decisions made faster than the advice-seeking discipline can keep up with.
The excitement phase is where organizations most often mistake speed for success, because the volume of decisions being made independently increases before the team’s judgment about which decisions need broader input has caught up. That gap is what the next phase reveals.
Well-Being as a Core Dimension
Consequences arrive as the faster pace produces a decision or two that would have benefited from wider advice, a dependency missed, a team not consulted, a principle overlooked, and the organization has to absorb the cost of that miss rather than a central architect catching it beforehand. Self-correction is the phase where teams internalize which decisions need the advice step and which don’t, arriving at a working equilibrium that moves faster than the original centralized model while catching most of what centralization used to catch.
Organizations that abandon decentralization during the consequences phase, reading the first visible miss as proof the model doesn’t work, never reach self-correction: the same phase sequence that produces the miss is what produces the calibrated judgment that follows it.
Context Maps: Assigning Clear System Ownership
A context map is the practical tool Hunter names for making decentralized ownership concrete: a shared map that assigns clear ownership of specific system areas to specific teams, replacing ambiguous or overlapping ownership with an explicit boundary. Without a context map, decentralizing decision rights runs into a prior problem; teams can’t decide independently about a system area whose ownership is contested or unclear, because every decision first has to resolve who actually has standing to make it.
Context maps solve this by making ownership a documented fact rather than an assumption. A team can move fast inside a boundary it clearly owns; the same team stalls at a boundary it shares ambiguously with another team, because every decision near that boundary risks stepping on a decision the other team also considers theirs. Mapping ownership explicitly is what turns “decentralize decision-making” from a policy statement into something a team can act on without first negotiating jurisdiction every time a decision comes up.
When Not to Decentralize: Samsung’s Note 7 and Highsmith’s Calibration Dials
Some decisions are better made centrally, and Samsung’s handling of the Galaxy Note 7 recall shows what a strongly centralized culture can do that a more distributed decision structure often can’t: kill a failing product decisively before the failure compounds further. Harvard Business Review’s own framework for when to decentralize decision making, and when not to, treats the choice as conditional on the specific decision rather than a fixed organizational stance (Harvard Business Review), which means Principle #9 is not unconditional, and organizations that treat it as a blanket mandate tend to decentralize decisions that needed to stay at the center.
Samsung’s Galaxy Note 7: When a Centralized Call Killed a Failing Product
Samsung’s hierarchical culture, under the controlling Lee family, produced the decision to recall and then permanently terminate the Galaxy Note 7 after battery failures made the product a safety hazard, a case Harvard Business Review’s John Joseph and Ronald Klingebiel use to argue that centralization has a specific, underappreciated strength (Harvard Business Review). The decision to kill the product entirely, not patch it, not phase it out gradually, required overriding the sunk cost, internal momentum, and reputational stake that a more distributed set of decision-makers would each have had reason to protect.
Joseph and Klingebiel’s point is narrow but important: a strongly centralized authority can move decisively to kill a failing product in a way a distributed structure often can’t, because a distributed structure disperses the accountability for the kill decision across enough people that no single one of them owns the call cleanly. Samsung’s centralized authority didn’t produce a slower response to the Note 7 crisis: it produced a faster, more complete one, which is the opposite of what a decentralization advocate might predict.
Highsmith’s Explore and Exploit Modes: Decision Rights Aren’t One Setting
Jim Highsmith, a co-author of the Agile Manifesto, argues in Stop Picking Sides that decision rights aren’t a single organization-wide setting to choose once; they’re a property of the operating mode a specific team is in at a specific time, tuned along explore and exploit Stop Picking Sides (Martin Fowler). A team in explore mode is adaptation-dominant, working under high uncertainty where the right answer isn’t yet known; a team in exploit mode is optimization-dominant, refining a known approach where the risk profile and cost of a wrong call are already well understood.
Highsmith calibrates the choice with four dials rather than a single switch: uncertainty, risk, cost of change, and evidence threshold. High uncertainty and low cost of change favor decentralizing fast, reversible decisions to the team closest to the work; high risk and a high evidence threshold favor keeping the decision closer to the center, where more evidence can be gathered before committing. His instruction, stated as a direct rule rather than a preference: for decision rights, use DARE, not RACI, Decide, Advise, Recommend, Execute, because RACI assigns accountability without addressing who actually holds standing to decide when the stakes and certainty of the decision shift.
| Framework | What it assigns | Best fit | Weak point |
|---|---|---|---|
| RACI | Who is Responsible, Accountable, Consulted, Informed | Stable, low-uncertainty processes | Doesn’t adjust when a decision’s risk or uncertainty changes |
| DARE | Who Decides, who Advises, who Recommends, who Executes | Teams moving between explore and exploit modes | Requires the team to actively diagnose its own mode |
The Four Calibration Dials
Uncertainty measures how much is unknown about the right answer, as opposed to unknown only because no one has checked yet; risk measures the size of the loss if the decision turns out wrong; cost of change measures how expensive it is to reverse the decision once made; and evidence threshold measures how much proof a decision reasonably requires before it’s responsible to act. A decision scoring high on uncertainty and low on cost of change is a strong decentralization candidate: the team can act and adjust cheaply. A decision scoring high on risk and high on evidence threshold, like Samsung’s recall call, belongs closer to the center regardless of how much local information the team closest to it holds.
The four dials give a team a repeatable diagnostic instead of a one-time policy choice, which matters because a single team moves between explore and exploit mode as its work changes: the same team building a new capability under high uncertainty shifts into exploit mode once that capability stabilizes into a maintained system, and its decision rights should shift with it rather than staying fixed at whatever setting the organization chose during the original rollout.
The Handoff Tax: Where Decentralization Breaks at Mode Boundaries
The handoff tax is the specific cost decentralization incurs at the boundary where a team operating in explore mode hands its work to a team operating in exploit mode under a different set of decision rights, and Highsmith cites bimodal IT as the cautionary case for what happens when that boundary isn’t managed. Bimodal IT split organizations formally into a fast, exploratory track and a slow, stable track, on the reasoning that each track could then optimize its own decision rights independently; but the split created exactly the handoff problem it was meant to avoid, because work still had to cross from one track to the other, and the receiving team’s slower, higher-evidence decision rights collided with the sending team’s faster, lower-evidence ones.
The tax shows up as friction that looks like a people problem but is actually a decision-rights mismatch: the exploit-mode team asks for evidence the explore-mode team never needed to gather, and the explore-mode team experiences the request as bureaucratic resistance rather than as a legitimate difference in what each mode’s risk profile requires. Highsmith’s calibration framework treats this as predictable rather than anomalous; decentralization doesn’t fail at the boundary because people are being difficult, it fails because nobody defined how decision rights convert when work crosses from one mode to the other.
Building a Simple Decision-Rights Test
A workable test for whether a specific decision belongs at the center or the edge runs through Highsmith’s four dials in order: check uncertainty and cost of change first, since a decision that’s cheap to reverse under high uncertainty rarely needs central review regardless of its other properties, then check risk and evidence threshold to catch the cases, like Samsung’s recall, where the potential loss is large enough to justify the delay a centralized review adds.
Applying the test consistently also prevents the opposite failure mode, where an organization decentralizes everything on principle and loses Samsung’s advantage: the ability to kill a failing initiative decisively when the distributed teams closest to it each have a reason to keep it alive a little longer. The test isn’t a one-time classification exercise: a decision’s position on all four dials shifts as a project moves from initial uncertainty toward a stable, well-evidenced state, which is why the dials, not a fixed org chart, are what should determine where the decision right sits at any given moment.
Decentralizing Where People Won’t Use the Authority: Risk-Averse and Regulated Organizations
Granting decision authority formally doesn’t guarantee anyone uses it, and in risk-averse or regulated organizations the gap between granted authority and exercised authority is often the entire reason a decentralization initiative stalls. The Lean Enterprise Institute’s research on lean adoption in government names the specific barrier that explains why: it isn’t a policy failure, it’s what people are afraid will happen to them if they decide wrong.
LEI’s Five Barriers, Named
The Lean Enterprise Institute’s “5 Barriers to Lean in Government” names workforce structure, disincentives for risk-taking at all levels, complex stakeholder relationships, and the difficulty of challenging the status quo as the structural conditions that block lean and decentralized practices from taking hold in government and similarly regulated settings (Lean Enterprise Institute). Workforce structure covers civil-service rules, tenure protections, and hiring constraints that make it harder to move authority to where the work is; complex stakeholder relationships cover the number of external parties, oversight bodies, the public, elected officials, whose interests a single decision has to account for; and the status quo barrier covers the institutional inertia that makes any process change, decentralization included, harder to land than in a private organization with fewer external constraints.
Each barrier operates independently, which is why fixing one rarely unblocks decentralization on its own: an organization can rewrite its workforce structure and still fail to decentralize if the risk-taking disincentive is untouched, because that barrier operates on individual behavior rather than organizational policy.
The Barrier SAFe Doesn’t Address: Disincentives for Risk-Taking
Disincentives for risk-taking at all levels is the barrier SAFe’s own Principle #9 material never names directly, and it explains a pattern many leaders find confusing: authority formally granted, and still not used. In organizations where the personal downside of a wrong call permanently exceeds the upside of a right one, a career mark that never clears, a public failure that follows someone for years, people decline to exercise decision authority even after it has been explicitly delegated to them, because the incentive structure they actually operate under still punishes the decision that goes wrong far more than it rewards the one that goes right.
A decision-rights charter changes what people are formally allowed to decide; it does nothing to change what they’re afraid will happen to them if they decide wrong. Charters, RACI matrices, and delegation memos all operate on the same layer, formal permission, while the disincentive for risk-taking operates on a different layer entirely: the lived, informal consequence someone expects to face. The Agile Alliance’s research on decision-making systems makes the same distinction from the systems side: who is allowed to decide and who actually will decide are separate design variables, and a charter that only sets the first one leaves the second unaddressed (Agile Alliance). An organization can rewrite every governance document it owns and still watch decision authority sit unused, because the document never touched the actual fear driving the behavior.
The Cheap Fix: Daily Huddles and Visual Backlog Boards
The Lean Enterprise Institute’s counter-move for organizations stuck on the risk-taking barrier is deliberately cheap and deliberately not a policy change: daily team huddles and visual backlog boards that make it clear where work sits and who is actively working each issue. A daily team huddle gives people a low-stakes, frequent venue to raise a decision or an obstacle in front of peers rather than escalating it formally, which lowers the perceived cost of surfacing a problem long before any formal decision-rights charter would need to change.
LEI credits the mechanism directly: it energizes workers by giving them real agency and control over their work, without waiting for a decision-rights charter to be rewritten (Lean Enterprise Institute / value stream mapping and Obeya). A visual backlog board functions the same way a Japanese Obeya room does; making the state of work visible to everyone in the room removes the ambiguity that made raising an issue feel risky in the first place, because the problem is already visible on the board rather than something one person has to volunteer to name. Neither tool requires rewriting a charter or restructuring reporting lines; both work by lowering the social cost of using authority that was already formally granted.
Auftragstaktik and Intent-Based Leadership: The Command Doctrine Behind Principle #9
Organizations that announce empowerment and watch nothing change are usually missing a specific mechanism that Principle #9 assumes but never states: leaders have to stop specifying methods and start specifying intent. Auftragstaktik, the Prussian and later US Army doctrine of decentralized execution, is where this mechanism was first formalized, and it explains precisely why decentralization fails without it.
Auftragstaktik and Mission Command: Intent at the Top, Execution at the Edge
Auftragstaktik, developed by the Prussian army in the 19th century and formalized in modern US Army doctrine as mission command, delegates execution authority to the lowest competent level while preserving commander’s intent at the top: the doctrine’s own formulation states mission command as the conduct of operations through decentralized execution based upon mission-type orders, where commanders state intent, the why and the what-by-when, and subordinates determine the how US Army (SAFe_Principles cluster research). The doctrine solves a problem centralized command structures ran into repeatedly on a battlefield: by the time a detailed order travels from headquarters to the front and a status update travels back, the situation the order was written for has already changed.
A parallel lineage runs through Toyota rather than the military. Taiichi Ohno’s insight that the people doing the work hold the most accurate and current information was made physical in the andon cord: a cord any factory worker could pull to halt the production line the moment a defect appeared, without first securing a supervisor’s approval. Both lineages, Prussian mission command and Toyota’s andon cord, entered software practice together through the Poppendiecks’ Lean Software Development (2003), which is part of why Principle #9 reads as compatible with both a military decentralization tradition and a lean manufacturing one rather than belonging cleanly to either.
Marquet’s Turn the Ship Around!: Give Control, Build Competence, Clarify Intent
L. David Marquet’s Intent-Based Leadership, developed aboard the USS Santa Fe and published in Turn the Ship Around! (2013), gives command doctrine its modern operational form through three pillars: give control, build competence, and provide clarity of intent rather than specification of method Ship Around (Intent-Based Leadership). Marquet’s model is explicitly leader-leader rather than leader-follower; every person in the structure is expected to think and decide like a leader within their own scope, rather than execute instructions handed down by someone above them.
Giving control without first building competence produces bad decisions made confidently; building competence without giving control produces capable people still waiting for permission. Marquet sequences the three pillars deliberately: competence has to be built before control is meaningfully useful, and both need clarity of intent to aim at, or control and competence produce fast, well-executed decisions that solve the wrong problem. The intent statement does the work a detailed instruction used to do: it tells the person deciding what outcome matters and by when, and leaves the specific method to the judgment of whoever is closest to the situation.
The Missing Mechanism in SAFe’s Own Principle Set
Neither Principle #9 nor Principle #8 contains an explicit instruction about the leadership behavior decentralization actually requires, which is the structural gap that explains why many organizations decentralize decision rights on paper and see no change in practice. SAFe’s Lean-Agile Leadership material describes leaders as expected to lead by example and grow others, but doesn’t name the specific habit that blocks decentralization when it’s absent: leaders continuing to specify how a decision should be made even after formally delegating who gets to make it Lean-Agile Leadership (SAFe).
A leader who delegates the decision right but keeps directing the method hasn’t decentralized anything: the person receiving the delegation still has to guess what the leader actually wants and produce that, rather than exercising independent judgment. Auftragstaktik and Marquet’s Intent-Based Leadership both name the fix directly: state intent, withhold method. SAFe’s principle set states the destination, decentralize the decision, without stating the leadership behavior that gets an organization there, which leaves the gap for each organization to discover on its own, usually after an empowerment initiative has already visibly failed once.
Empowerment Theater, Information Starvation, and the Matrix Authority Trap
Three named failure modes mark the specific ways organizations fail to decentralize decisions even while believing they have: Empowerment Theater, Information Starvation, and the Matrix Authority Trap. Each one produces the same symptom, teams report that nothing changed after empowerment was announced, from a different root cause, which is why diagnosing which failure mode is present matters more than repeating the empowerment announcement louder.
| Failure mode | What it looks like | Root cause |
|---|---|---|
| Empowerment Theater | Town-hall announcement of empowerment; approval process unchanged | Authority never actually moved |
| Information Starvation | Decision delegated without customer, financial, or competitive data | Authority moved, information didn’t |
| Matrix Authority Trap | Team nominally owns the decision; functional manager still controls it | Two authority structures conflict |
Empowerment Theater: When Announcements Don’t Change Approval
Empowerment Theater describes the specific pattern where leaders announce decentralized decision-making in a town hall or all-hands, while the actual approval process a decision has to pass through remains unchanged underneath the announcement: a critique Maarten Dalmijn makes of organizations that treat empowerment as a communications event rather than a structural one. The announcement changes the language people use to describe the organization without changing which meetings a decision still has to persist, which forms and sign-offs still control it, or who still has practical veto power over it.
Teams experiencing Empowerment Theater learn quickly to distrust future announcements, which makes a second, genuine decentralization effort harder to land than the first one would have been. The tell is straightforward to check: ask whether the approval steps a decision used to require still exist under a different name, or whether they were actually removed.
Information Starvation: Delegated Without the Data
Information Starvation describes decision rights delegated without the customer data, financial models, or competitive analysis the decision actually needs; authority moved, but the information required to use it responsibly didn’t move with it. A team newly holding a pricing decision without access to margin data, or a product decision without access to competitive intelligence, hasn’t been decentralized so much as handed a decision it can’t make well, which produces uninformed choices that then get cited as evidence that decentralization doesn’t work.
The fix isn’t returning the decision to the center; it’s tracing the specific information the decision requires and routing it to wherever the decision right now sits: the same diagnostic discipline the Architecture Advisory Forum and Technology Radar apply to architectural decisions, applied to whatever data a given decision class depends on.
The Matrix Authority Trap: Liis Laulik’s Bank Case
The Matrix Authority Trap occurs when functional managers retain real authority over a worker even after a matrix structure has nominally granted decision rights to a cross-functional team: a pattern Liis Laulik documents in a bank case via Equal Experts, where team members reported to the newly empowered team on paper while their functional manager still controlled their performance review, their assignments, and effectively their incentive to comply with the team’s decisions. The team held the formal decision right; the functional manager held the leverage that actually shaped behavior.
The trap is specifically a matrix-structure problem rather than a general decentralization problem, because it requires two competing authority lines pointing at the same person. Resolving it requires picking one authority line as primary for a given class of decision rather than layering a second, informal one on top of the first; otherwise the team’s decision right exists only until it conflicts with what the functional manager wants, at which point the functional line prevails by default.
Summary
Decentralize Decision-Making holds up as a structural fix only when the mechanism underneath the principle gets built, not just declared: the queue SAFe names, the advice process that replaces gatekeeping, and the leadership habit of stating intent instead of method.
The Decision Queue Is a Systems Problem, Not a Trust Problem
Clearing that queue changes what happens downstream rather than just who signs off: decision latency drops in proportion to how many approval hops were removed, and the organization’s effective scope, how many decisions it can process concurrently without one stalling behind another, expands to match. That transfer isn’t automatic: Harmel-Law’s four supporting elements generalize to a non-architecture decision only when an equivalent recording-venue-direction-awareness set exists for that domain, and a decision class missing even one of the four, a pricing call with nothing playing the Technology Radar’s role of tracking what competitors are doing, say, reopens the coordination gap the Advice Process exists to close. Slime mold’s Tokyo network marks the outer edge of how far that transfer reaches: local decisions only match or beat centralized planning when the local decision-maker can sense its surroundings and reverse course cheaply, the same uncertainty-and-cost-of-change pairing Highsmith’s calibration dials use later to route a decision to the edge in the first place.
The four-phase sequence teams move through as architectural decisions decentralize describes the transition cost of rebuilding that routing structure, not a sign the redesign is failing partway through. An organization that reads the consequences phase as proof decentralization doesn’t work stops exactly where the self-correction phase would have paid off the transition cost. The remaining gap is ownership: a queue redesigned around unclear boundaries just relocates the original bottleneck to whichever team has to negotiate jurisdiction before it can act, which is exactly what context maps are built to close.
Where Decentralization Breaks: Calibration, Fear, and Withheld Intent
Not every decision belongs at the edge, and the usable rule looks forward rather than back: centralize a decision when its potential loss is large and a wrong call is expensive to reverse, decentralize everything else, and treat everything in between as the calibration problem the next two tools are built to solve. Highsmith’s calibration dials give a repeatable way to tell which decisions belong at the center and which belong at the edge, and his handoff tax names the specific cost of ignoring the boundary between a team in explore mode and a team in exploit mode.
Even correctly calibrated decision rights fail against two conditions Principle #9 doesn’t name on its own. The first is the disincentive for risk-taking, and it shares a root with the second condition below: both are about what a decision-maker actually expects to happen when they act, not about what a charter formally permits; fear of a wrong call and a leader who withholds method are the same informal-layer failure showing up on either side of the decision. The second is the intent-vs-method leadership habit Auftragstaktik and Marquet’s Intent-Based Leadership both name, and a reader can tell which of its three forms is present with one check apiece: whether the approval steps actually disappeared (Empowerment Theater), whether the data needed to decide moved with the right (Information Starvation), or whether a second authority line still overrides the first (the Matrix Authority Trap). Decentralizing the right without decentralizing the information, the safety to use it, and the leader’s willingness to withhold method produces the appearance of Principle #9 without the mechanism that makes it work.
Related in this cluster
- Safe_principles
- Inherited vs Invented: Per-Principle Intellectual Lineage Audit
- Principle Tie-Breakers: When SAFe Principles Conflict
- Missing Principles: What SAFe Left Out
- Principle-Practice Diagnostic: Symptoms of Principle Violations
- SAFe Framework Version History
- Competing Agile Frameworks: LeSS, Kanban, Scrum, DA