Missing Principles: What SAFe Left Out

Simplicity and emergent design have no SAFe counterpart. Psychological safety, cognitive load, and Larman's Laws expose more gaps the ten never close.

Ask a room of certified practitioners whether SAFe’s ten principles cover everything Agile and Lean thinking has to offer, and most will say yes: the list is official, so it must be complete. It isn’t: two Agile Manifesto principles have no SAFe counterpart, a validated organizational-psychology finding never made the synthesis, and a named critique of SAFe’s own structure argues the framework contradicts one of its own ten. Tracing the missing principles SAFe left out means testing that assumption of completeness against the wider canon SAFe drew from, one gap at a time.

---

Why a Missing Principle Is a Framework Gap, Not a Documentation Gap

A missing principle in SAFe’s ten is a gap in the framework’s operating logic rather than a gap in its paperwork, because the two institutions that jointly define what “agile” means agree the term names a set of principles, not a checklist of practices. The Agile Practice Guide, published jointly in 2017 by the Project Management Institute and the Agile Alliance, is the notable artifact here not primarily for its content but for its authorship: PMI and the Agile Alliance share almost no institutional history, one rooted in waterfall-era project management standards and the other born from the 2001 Agile Manifesto itself. Johanna Rothman and Mike Griffiths, who co-authored the guide, described that convergence directly on the Agile Alliance’s Engineering Culture podcast: two organizations that rarely occupy the same room reached the same conclusion; agile is a mindset built on values and principles, not a fixed set of practices Engineering Culture (Agile Alliance).

That agreement is what raises the stakes of a principle-set gap from cosmetic to structural. If agile is its principles, then a framework’s list of principles is the framework’s actual operating system: the practices are just the interface. SAFe’s own reference material makes the same claim about itself: the ten SAFe Lean-Agile Principles “inspire and inform the roles and practices of SAFe,” described as the immutable tenets everything else is built on SAFe Lean-Agile Principles (Scaled Agile Framework). A hole in that list, by SAFe’s own framing, is a hole in the logic the roles and practices are supposed to express.

What Counts as a Gap, and What Doesn’t

A principle-set gap, as this analysis uses the term, means a topic is absent from all ten principles outright: not merely stated briefly, or covered by implication through a related principle’s language. Something SAFe’s ten touch on lightly, or address through a different lens than the source material uses, is a coverage difference rather than a gap; only a genuine absence, nothing in the ten however indirect, supports the structural claim the rest of this piece makes.

The Agile Practice Guide’s Cross-Institutional Definition

The Agile Practice Guide matters here because two institutions with almost no natural overlap converged on the same definition of what makes work agile: a mindset grounded in values and principles, not a portable checklist of ceremonies. PMI brought decades of waterfall-era project standards to the table; the Agile Alliance brought the 2001 Manifesto’s own lineage; and neither had an obvious incentive to concede ground to the other’s framing.

Rothman and Griffiths’ account of writing the guide together, given directly on the Agile Alliance’s podcast, is the more useful evidence than the guide’s text alone: the interesting fact is not what the guide says, but that co-authors from opposing institutional cultures didn’t have to negotiate that particular point Engineering Culture (Agile Alliance). Once that definition holds, a completeness claim about any framework’s principle set stops being a stylistic preference and becomes a testable claim about whether the framework’s operating logic is actually whole.

SAFe’s Ten as a Curated Selection, Not an Inventory

SAFe’s ten principles are the product of a deliberate synthesis, not an exhaustive inventory of everything the Lean and Agile literature contains; Dean Leffingwell built the list top-down from Agile Manifesto principles, Lean thinking, and systems thinking, selecting the tenets that would generalize across the enterprise contexts SAFe was built to scale into.

Curation of this kind has precedent well outside software: Henri Fayol distilled a century-old body of management observation into fourteen numbered principles, and W. Edwards Deming did something structurally similar with his own list decades later; both were selective compressions of a much larger literature, not attempts to capture all of it Edwards Deming (Lean Enterprise Institute). Leffingwell’s synthesis works the same way: it optimizes for what applies broadly across SAFe’s target organizations, which is exactly the kind of choice that leaves material on the table. What follows here is scoped narrowly to that content gap: not whether organizations actually adhere to SAFe’s ten once adopted, and not the Manifesto’s own twenty-five-year history, only which principles the wider canon carries that Leffingwell’s synthesis left out.

---

The Two Manifesto Principles With No SAFe Equivalent: Simplicity and Emergent Design

Two of the Agile Manifesto’s twelve principles have no direct counterpart anywhere in SAFe’s ten: simplicity, defined as “the art of maximizing the amount of work not done,” and the claim that the best architectures, requirements, and designs emerge from self-organizing teams. Both principles push in the same direction, less imposed structure, which is precisely the direction SAFe’s own scaling machinery runs against.

A direct line-by-line mapping of the Manifesto’s twelve principles against SAFe’s ten showed neither has a match: SAFe optimizes flow, economics, and cadence, but nowhere states a mandate against unnecessary work, and nowhere assigns architectural authority to the team discovering it as they build (Agile Alliance). That absence is worth naming precisely: SAFe’s principles don’t fail to deliver on simplicity or emergent design, because they never asserted either one. A framework can’t violate a commitment it never made: it can only lack one.

Why These Two, and Not Others From the Manifesto’s Twelve

Simplicity and emergent design stand out from the Manifesto’s other ten principles because a full line-by-line comparison finds partial echoes of most of them somewhere in SAFe’s ten, customer focus, iterative delivery, and sustainable pace all show up in some form, while these two have no SAFe counterpart at any level, direct or partial. That makes them the cleanest test case for what “no equivalent” actually means, rather than a difference of emphasis or wording.

Simplicity: Maximizing the Amount of Work Not Done

Simplicity, as the Agile Manifesto states it, is the discipline of maximizing the amount of work not done; treating unbuilt features and unrun processes as a legitimate design outcome rather than a shortfall to be corrected later. The principle targets the backlog itself: not how fast work moves once approved, but whether it should have been approved at all.

That distinction is exactly where SAFe’s ten fall silent. The framework’s economic and flow principles govern sequencing, what order work happens in, and how fast it moves through the system, but none of them asks whether a piece of work should exist in the first place. Simplicity’s Lean lineage reinforces the point: Taiichi Ohno’s original Toyota Production System treated waste elimination as the underlying logic, with specific tools as downstream expressions of it rather than the point itself, and that logic demonstrates it shows portable well beyond manufacturing floors Toyota Production System (Lean Enterprise Institute). SAFe inherited the Lean label without inheriting this particular piece of the Lean argument, leaving a category of waste, work that should never have been started, outside what any of its ten principles govern.

Emergent Architecture From Self-Organizing Teams

Emergent architecture is the Manifesto’s bet that the best architectures, requirements, and designs come from self-organizing teams discovering them during the work, rather than from a role planning them ahead of it. The principle assigns architectural authority to the people closest to the code, on the theory that proximity to implementation detail produces better design decisions than upstream planning does.

SAFe’s ten never assign that authority anywhere. Where the Manifesto trusts emergence, SAFe substitutes intentional, planned architecture work: a difference that matters most at the scale SAFe is built for, where dozens of teams building in parallel can’t safely discover conflicting architectural decisions on their own without expensive rework downstream. The absence isn’t accidental: it tracks directly with team count, and what fills the resulting space is worth naming on its own.

---

What SAFe Substitutes for Emergent Design: The Architectural Runway Trade

SAFe fills the emergent-architecture gap with the Architectural Runway: the existing code, components, and technical infrastructure already in place so that near-term features can be built without requiring disruptive redesign first. Where the Manifesto bets on architecture discovered by the teams building it, SAFe assigns intentional architecture work ahead of time, typically carried through Enablers and a System Architect or Solution Architect role.

That substitution is a genuine engineering trade-off, not a workaround for an oversight. The architecture-and-governance literature on SAFe frames the Runway precisely this way: because agile teams are still empowered under the Manifesto’s eleventh principle to design the architecture they need, SAFe layers Intentional Architecture on top as a lightweight, collaboratively built plan rather than eliminating emergent design outright Intentional Architecture (Architecture & Governance). It buys predictability across many parallel teams, avoiding the coordination cost of independent teams landing on conflicting architectural decisions without knowing it, at the price of the Manifesto’s own wager that proximity to the code produces the best design.

How the Runway Trade Relates to the Simplicity Gap

The Runway trade addresses only one of the two Manifesto principles SAFe leaves uncovered, emergent design, and does so directly, by substituting planned architecture for team-discovered architecture. Simplicity gets no equivalent substitution anywhere in SAFe’s ten: there is no SAFe mechanism that trades away “maximizing the amount of work not done” the way the Runway trades away emergent design, which is why that gap resurfaces later as a separate, unresolved absence rather than one SAFe has addressed differently.

The Architectural Runway, Defined

The Architectural Runway is SAFe’s term for the existing code, components, and technical infrastructure a team already has in place to implement near-term features without excessive redesign: a working foundation rather than a fixed blueprint, extended incrementally as new capabilities demand it. Unlike a traditional up-front architecture document, the Runway is meant to evolve alongside delivery instead of preceding it entirely.

That evolution is what keeps it from collapsing into the same rigidity the Manifesto’s emergent-design principle was written to avoid: the Runway anticipates near-term technical needs without attempting to specify long-term ones, staying just far enough ahead of delivery to prevent teams from hitting a wall. Organizations that let the Runway calcify into a permanent, unrevisited plan lose that flexibility and effectively reintroduce the up-front design risk the Manifesto principle was trying to eliminate in the first place.

Enablers and the Architect Roles That Own Them

Enablers are the work items SAFe uses to make Architectural Runway work visible and plannable alongside feature work; exploration spikes, infrastructure builds, and compliance work that extend the Runway rather than deliver customer-facing value directly. Because Enablers compete for the same backlog slots as features, SAFe gives them explicit visibility rather than letting them get gradually deprioritized behind higher-profile feature requests.

A System Architect (at the Agile Release Train level) or Solution Architect (at the Solution Train level) owns the technical vision that Enablers execute against, coordinating the Runway across teams that would otherwise make independent, potentially conflicting infrastructure decisions. Without a named owner for that coordination, teams building against a shared Runway in parallel risk the exact conflicting-decision cost the Runway substitution exists to prevent; which is why SAFe pairs the mechanism with an explicit role rather than leaving it to emerge from team interaction alone.

What the Trade Buys and What It Costs

The Architectural Runway buys predictability across the many teams operating in parallel under SAFe, at the direct cost of the Manifesto’s own bet that architecture discovered by the people building it beats architecture planned ahead of them. Predictability here means fewer instances of independent teams reaching incompatible technical decisions that become visible only when their work needs to integrate: a cost that scales with the number of teams involved.

That trade-off tracks with team count more than with any judgment about which approach produces objectively better designs. Letting architecture emerge safely gets harder as the number of independent teams grows, because the coordination surface between them grows faster than the team count itself; SAFe was built to operate well past the point where that coordination surface becomes unmanageable without a named owner. Smaller organizations running fewer trains face a real choice here: the Runway’s coordination benefit shrinks as team count drops, while the Manifesto’s proximity argument gets stronger, which is worth testing against an organization’s own team count before assuming SAFe’s default is the right one.

---

The Missing Simplicity Principle: Searching SAFe’s Ten for ‘Work Not Done’

A direct search of SAFe’s ten principles for language matching the Manifesto’s simplicity mandate, maximizing the amount of work not done, turns up nothing: none of the ten states it, and the two closest candidates only partially overlap with what the principle actually argues. Visualize and Limit WIP bounds how much work is in flight at any one time, and Assume Variability and Preserve Options defers some speculative work as a side effect of managing uncertainty; but neither one argues that a given piece of work shouldn’t exist.

That distinction matters more than it looks. SAFe’s economic and flow principles govern the sequencing and pacing of work already accepted into the system; none of them evaluates whether a backlog item should have been accepted in the first place. The practical consequence lands squarely on Product Owners and Product Management: SAFe gives them principle-level language for saying “not yet”, defer this, sequence it later, preserve the option, but no equivalent principle-level language for saying “no” outright.

How the Search Was Run: Testing Each of the Ten Directly

Confirming the absence meant checking each of SAFe’s ten principles individually against the Manifesto’s specific definition, maximizing the amount of work not done, rather than relying on a general impression that SAFe covers simplicity through its flow and economic thinking. Eight of the ten showed no plausible connection to that claim at all; only Visualize and Limit WIP and Assume Variability and Preserve Options were close enough to warrant a direct comparison, and neither survives it.

The Two Partial Matches, and Why Neither Counts

SAFe’s two closest candidates to a simplicity principle both fall short of the Manifesto’s actual claim, because each addresses a different problem than “should this work exist at all.” Visualize and Limit WIP caps how much work is in progress simultaneously, improving flow and reducing the cost of context-switching between parallel efforts; but it says nothing about whether the capped set of work items should have been smaller to begin with. Assume Variability and Preserve Options defers commitment on some work by keeping design and technology options open longer, which incidentally reduces speculative building; but that reduction is a side effect of managing uncertainty, not a direct argument against unnecessary work.

The gap between “manage flow” and “reduce scope” is exactly where simplicity as the Manifesto states it would sit, and SAFe’s ten simply don’t occupy that space. A Product Owner using WIP limits alone can still be running an oversized backlog efficiently; moving too much unnecessary work through the system at a controlled pace instead of eliminating the unnecessary work outright.

Visualize and Limit WIP: Bounding Flow, Not Existence

Visualize and Limit WIP is one of SAFe’s core flow principles, instructing teams to make work-in-progress visible and cap how much of it runs concurrently so that bottlenecks become visible instead of hiding behind busy-looking boards. The mechanism works by constraining capacity: once a WIP limit is reached, no new item enters the system until an existing one completes, forcing attention toward finishing work rather than starting more of it.

That constraint improves throughput and predictability, but it operates entirely on work already accepted into the system: it has nothing to say about whether the accepted set of work is larger than it needs to be. A team with a well-enforced WIP limit can still be running a backlog full of low-value items at a steady, visible pace; the principle optimizes how existing work flows, leaving the separate question of whether that work should have existed at all fully outside its scope.

What a Product Owner Is Left Without

A Product Owner facing a backlog full of technically justified but ultimately unnecessary features has SAFe’s economic sequencing principles to lean on for deferring items, but no principle-level backing for cutting them outright. Economic sequencing supports “this can wait”, reprioritize, defer, hold the option open, because that’s what Assume Variability and Preserve Options and the framework’s cost-of-delay thinking are built to support.

What’s missing is the language to support “this shouldn’t happen,” and that gap has a direct organizational consequence: backlogs grow because every item on them can be economically justified in isolation, while no principle in the framework asks whether the aggregate set of justified items is itself excessive. Product Owners inside SAFe end up borrowing simplicity language from outside the framework, from the Manifesto directly, or from Lean’s waste-elimination lineage, because SAFe’s own ten don’t supply it.

---

Failure Modes That Reveal the Gap: Cohn and Keith’s Taxonomy Against SAFe’s Principle Set

An independently sourced agile failure taxonomy lands on the same gap the direct principle comparisons already found: Mike Cohn and Clinton Keith’s “How to Fail with Agile” (Better Software, 2008) sorts agile failure into four categories; management issues, team issues, product owner issues, and process issues. Product owner disempowerment stands out in that taxonomy as its own first-class category, not folded into general team dysfunction (Mountain Goat Software).

Checked against SAFe’s ten directly, none addresses product-owner authority or individual-role empowerment by name. Decentralize Decision-Making comes closest, but it operates at the systemic level, distributing decision rights across the organization broadly, rather than protecting any specific role’s authority against erosion. A Product Owner can watch their authority get absorbed by program-level ceremony while SAFe’s decentralization principle technically holds at the system level.

Product Owner Disempowerment as a Named Failure Category

Cohn and Keith name product owner disempowerment as a distinct failure category because the pattern they observed didn’t reduce cleanly to team dysfunction or process breakdown: it was specifically about authority draining away from the one role meant to hold it. Their taxonomy treats it as structurally separate from the other three categories precisely because the fix for a disempowered Product Owner looks different from the fix for a dysfunctional team or a broken process.

Checked against SAFe’s ten, that specific failure mode has no named defense. Decentralize Decision-Making is the only principle in the same territory, but it addresses where decision rights sit across the organization as a whole rather than whether any individual Product Owner retains real authority once program-level ceremony, cross-team dependencies, and RTE-driven sequencing start absorbing decisions that role used to make alone.

Three Lines of Evidence, One Convergent Gap

Three independent lines of evidence converge on the same structural finding: SAFe’s ten principles are built stronger for flow and economics than for simplicity and individual empowerment. The direct Manifesto mapping found no counterpart for simplicity or emergent design; the direct search of SAFe’s own ten found only partial, indirect coverage of simplicity through WIP limits and variability management; and Cohn and Keith’s independently documented failure taxonomy names product-owner disempowerment as a first-class failure mode with no principle-level defense against it.

None of these three approaches was designed to establish the others: one is a line-by-line comparison, one is an internal search, one is a taxonomy built from observed project failures years before SAFe reached its current scale. Reaching the same shape of gap from three unrelated directions is what separates a documented finding from a single reviewer’s complaint.

---

The Evidence-Backed Candidates: Psychological Safety, Cognitive Load, and Larman’s Laws

The strongest missing-principle candidates carry named proposers and published evidence rather than wish-list status: Amy Edmondson’s psychological safety research, Matthew Skelton and Manuel Pais’s cognitive load constraint from Team Topologies, and Craig Larman’s structural critique that SAFe’s own prescriptive machinery undercuts its ninth principle, each grounded in a named study or published critique rather than an unattributed best practice. Locating where each candidate would sit inside SAFe’s existing ten is the fastest way to see what kind of principle the framework systematically leaves out.

These three cluster into two distinct shapes of gap. Psychological safety and Larman’s structural critique both describe human-conditions preconditions, trust, consent, and genuine decentralization, that SAFe’s Unlock Intrinsic Motivation and Decentralize Decision-Making principles assume rather than actively secure. Cognitive load describes a system-capacity bound that SAFe’s own flow optimization can run straight through if applied without it.

Edmondson’s Psychological Safety: The Evidence P8 Ignores

Psychological safety is the most evidence-backed missing-principle candidate, defined in Amy C. Edmondson’s 1999 study as a shared team belief that interpersonal risk-taking is safe; and its absence measurably suppresses the learning behavior teams need to improve (Edmondson, 1999). SAFe’s Principle 8, Unlock the Intrinsic Motivation of Knowledge Workers, draws on autonomy, mastery, and purpose, Daniel Pink’s motivational triad, but never names psychological safety as a precondition for any of the three to function.

That’s not a small omission. Edmondson’s research shows intrinsic motivation stalls when fear of interpersonal risk suppresses the learning behavior autonomy and mastery depend on: a team can be granted autonomy on paper and still fail to use it if members don’t trust that raising a concern or admitting an error won’t be held against them. Google’s Project Aristotle later confirmed the pattern at scale, ranking psychological safety the single strongest predictor of team effectiveness across the teams it studied; and Jeff Gothelf’s verdict on the resulting gap is blunt: without psychological safety there is no learning, and there is no agility.

Project Aristotle’s Confirmation

Project Aristotle was Google’s multi-year internal study of what actually distinguishes high-performing teams from underperforming ones, running statistical analysis across dozens of team-level variables rather than relying on manager intuition or self-report alone. Psychological safety came out ahead of every other factor the study measured, including individual talent concentration and team tenure: a result notable precisely because Google had every incentive to find that talent selection mattered most, and the data pointed elsewhere.

That finding matters here because it independently corroborates Edmondson’s 1999 laboratory and field research with a large-scale industry dataset two decades later, closing the gap between an academic claim and a practitioner-recognizable one. SAFe’s Principle 8 cites motivation science but stops short of the precondition both bodies of evidence point to; leaving the framework’s strongest evidence-backed candidate for a missing principle sitting directly beneath a principle that already gestures toward the same territory without naming it.

Cognitive Load: The Team Topologies Constraint SAFe Cites but Won’t Codify

Cognitive load management names the natural limit to how many distinct responsibilities a team can carry before delivery quality degrades: a constraint formalized by Matthew Skelton and Manuel Pais in Team Topologies (2019), which defines stream-aligned, platform, enabling, and complicated-subsystem team types specifically to keep any one team’s cognitive load bounded. SAFe has referenced Team Topologies since version 5.1, but only as supplementary guidance layered on top of the framework rather than as a governing principle among its ten.

The gap is visible in what SAFe’s flow principles optimize for without a counterweight: Make Value Flow Without Interruptions pushes toward moving more work through a system faster, and without a cognitive-load bound sitting alongside it, that optimization can push a team past the point where they can competently own everything assigned to them. Skelton and Pais’s team types exist precisely to bound that load structurally, assigning platform and enabling responsibilities to teams built for them rather than layering everything onto a single stream-aligned team, but the constraint that would make cognitive load a first-class planning input never crossed over from cited guidance into SAFe’s own principle set.

Larman’s Laws: Culture Follows Structure, and Structure Overrides Principle

Craig Larman’s Laws of Organizational Behavior, developed with Bas Vodde through the LeSS lineage, argue that culture follows structure; meaning an organization’s actual behavior is set by its formal reporting lines, roles, and processes far more than by any values statement layered on top of them. Larman’s charge against SAFe follows directly: SAFe’s ten principles function as mindset guidance, but the framework’s own heavy structural prescription, fixed ARTs, mandated PI cadences, and a dense set of named roles, overrides that mindset guidance in practice, because structure always gains the argument against stated intent.

The sharpest version of the charge lands directly on Principle 9. Decentralize Decision-Making asks organizations to push decisions to the people closest to the work, yet PI Planning, the event where an Agile Release Train commits to its quarterly objectives, is itself a centralized, synchronized ceremony that concentrates planning authority into a fixed two-day window rather than distributing it continuously. A principle asking for decentralization sits directly beside a mandatory practice built around centralized, calendar-driven commitment, and Larman’s Laws are the clearest available explanation for why the practice gains out.

The Structural Charge: Centralized PI Planning Against a Decentralized Principle 9

The specific mechanism behind Larman’s critique is that PI Planning concentrates commitment-making into a synchronized event that every team on an Agile Release Train attends together, rather than letting decision rights disperse to wherever the relevant information actually sits. Objectives, dependencies, and capacity trade-offs all get negotiated inside that fixed window, which structurally centralizes authority over what gets built next even while Principle 9 states the opposite intent.

That contradiction is Larman’s Laws working exactly as predicted: a values statement, decentralize decisions, loses to a structural mechanism, a mandatory synchronized planning event, because structure, not stated principle, determines what actually happens inside the organization. Organizations that want Principle 9 to hold in practice, not just on paper, need to examine where PI Planning’s structure is doing the deciding that the principle claims should happen elsewhere: a question worth testing directly against a specific train’s planning cadence rather than assuming the principle is self-enforcing.

Comparing the Three Candidates Side by Side

The three candidates cluster into two distinct kinds of gap, worth holding apart when deciding where to act:

Candidate	Evidence source	What it targets	Closest SAFe principle	Gap type
Psychological Safety	Edmondson (1999); Project Aristotle (2016)	Interpersonal trust as a precondition for learning	P8, Unlock Intrinsic Motivation	Human-conditions precondition
Cognitive Load Management	Skelton & Pais, Team Topologies (2019)	Bounding responsibilities per team	P6, Make Value Flow Without Interruptions	System-capacity bound
Larman’s Laws	Larman & Vodde, LeSS lineage	Structure overriding stated intent	P9, Decentralize Decision-Making	Structural contradiction

Governance research outside the Agile literature makes the same point about diagnosis versus symptom management: plugging individual leaks one at a time rarely resolves an underlying structural weakness, while stepping back to locate the source of the weakness usually does Decentralize Decision-Making (Harvard Business Review). Applied here, that argument favors treating psychological safety, cognitive load, and Larman’s structural charge as a connected diagnosis rather than three separate feature requests layered onto SAFe’s existing ten.

The scale of the documented gap extends beyond these three: nine distinct missing-principle candidates appear across named critics’ published work, with academic sources independently showing missing psychological-safety infrastructure and the absence of any principle governing cognitive load or organizational trust. Organizations often discover these gaps only after they’ve already scaled past the point where retrofitting them is cheap: a pattern broader management research on blind spots recognizes well outside the SAFe literature specifically (Harvard Business Review).

---

Summary

Not every gap traced here calls for the same response. Some are things the Manifesto states that SAFe’s synthesis simply didn’t carry over: those call for a straightforward import-or-don’t decision. Others are preconditions SAFe’s existing principles already lean on without stating outright: those call for hardening what’s already there, not adding something new. Sorting a specific gap into the right one of those two categories is what turns a vague complaint about SAFe into a decision an organization can actually act on.

Locate Which Gap Type Applies Before Adding a Principle

The four gaps traced here split into two distinct shapes, and confusing them leads to the wrong fix. Simplicity and emergent design fall into the first shape, where the only real decision is whether to import the Manifesto’s language for them locally or leave SAFe’s ten as the operating boundary as-is. Psychological safety, cognitive load, and Larman’s structural critique are a different shape entirely: preconditions and capacity bounds that SAFe’s existing principles assume rather than actively secure, meaning the fix isn’t a new principle so much as an explicit constraint layered onto principles already in place; P8 gains a safety precondition, P6 gains a load bound, P9 gains a check against the structures actually overriding it.

Before treating any of these as a mandate to adopt wholesale, locate which type of gap is actually costing an organization something: a Product Owner without language to say “no” to backlog bloat has a simplicity gap; a Product Owner losing authority to program-level ceremony has the empowerment gap Cohn and Keith named; a train where PI Planning visibly overrides Principle 9’s intent has Larman’s structural gap specifically, not a general “SAFe is too rigid” complaint. Naming the specific gap is what turns a diffuse frustration with the framework into an addressable design choice.

Treat the Fix as a Local Experiment, Not a Framework Rewrite

None of the four gaps traced here requires abandoning SAFe’s ten principles; they require organizations to recognize where their own operating context sits relative to each gap and add a targeted constraint locally, then check whether it worked before assuming it should scale further. A Product Owner testing a hard “no” policy against low-value backlog items for one PI can measure whether the change actually reduces the justified-but-unnecessary category Cohn and Keith described, without waiting for SAFe’s official guidance to catch up.

The same logic applies to cognitive load and psychological safety: an RTE who suspects a stream-aligned team is carrying too many Team Topologies-style responsibilities can test a narrower scope for one PI and measure delivery quality against the change, rather than treating cognitive load as an abstract missing principle to debate. Larman’s structural charge invites a similarly local test; examine whether a specific train’s PI Planning cadence is centralizing decisions that Principle 9 claims should sit elsewhere, and adjust the planning structure itself rather than restating the principle more emphatically. In every case, the missing principle is less a verdict on SAFe than an invitation to locate where the framework’s synthesis stopped short of an organization’s actual operating conditions; and to close that distance with an experiment scoped to what’s actually being measured, not a wholesale rewrite of the ten.