Role-Specific Principle Application (RTE, PO, SM, Architect, Exec)

Role-Specific Principle Application (RTE, PO, SM, Architect, Exec) tests three roles against one rule: mandate limits, integration gaps, earned authority.

Most people learn SAFe roles as a checklist: what a Release Train Engineer does, what a Product Owner owns, what a Scrum Master facilitates. That checklist gets the causal direction backwards. Role-Specific Principle Application (RTE, PO, SM, Architect, Exec) starts from the ten Lean-Agile principles a role inherits, then asks what changes when a specific person, in a specific title, applies one of them under real constraints: not what a job description says the title should do.

---

Why Roles Inherit From Principles, Not the Other Way Around

Scaled Agile’s own canonical Lean-Agile Principles page states the causal direction directly: SAFe rests on ten immutable Lean-Agile principles that inspire and inform its roles and practices, which makes a role’s daily practice a downstream expression of a principle rather than a freestanding job description. Treat the two as peers instead, and a role’s practices calcify into a checklist that survives long after the situation that justified it has changed; because nobody is checking the practice against the principle underneath it anymore.

Scaled Agile’s Own Claim: Principles Inform Roles, Not the Reverse

Scaled Agile’s own SAFe Lean-Agile Principles page answers the question directly, without hedging: “SAFe is based on ten immutable, underlying Lean-Agile principles. These tenets and economic concepts inspire and inform the roles and practices of SAFe” (Scaled Agile Framework). The page names these ten immutable principles as the foundation everything else in SAFe sits on top of, roles included. That single sentence sets the order for everything else in this piece: a Release Train Engineer’s coordination habits, a Product Owner’s prioritization calls, a Scrum Master’s facilitation choices, all sit downstream of the same ten principles, not beside them as separate rulebooks.

The same page credits synthesizing this body of knowledge across hundreds of deployments with four specific, named outcomes: improved employee engagement, faster time-to-market, better solution quality, and higher team productivity. Those four outcomes matter here because they are the test a role’s practice has to pass: a practice that doesn’t move at least one of them is decoration, not principle application. And the page states its own fallback mechanism plainly: when a role’s specific practice falls short in a given circumstance, the role falls back on the underlying principle, not a different prescribed practice. That fallback is the mechanism this piece traces through three sourced cases below, and it also sets the standard every role-specific claim in this piece is measured against: a practice that cannot point back to one of the ten principles fails the test, whatever a role’s title calls it.

Edwards Deming’s Epigraph: ‘Our Problems Are Different’ as a Disease

Edwards Deming’s epigraph on that same canonical page names the excuse this piece is built to dismantle: the belief that a team’s problems are uniquely different from everyone else’s. Deming states it directly: “The impression that ‘our problems are different’ is a common disease that afflicts management the world over” (Deming, Out of the Crisis, quoted at Scaled Agile Framework). Deming’s full point has two halves, and the second half is the one people skip; problems are different, he grants that much, but the principles that improve quality and service are universal in nature regardless of the specific problem in front of you.

That framing is why role-specific principle application is a different approach from writing a role catalogue. A catalogue answers “what does an Architect do,” fixed and generic. Principle application answers “what does this specific person, doing this specific job, do differently this week because a universal principle applies to a locally different problem.” The disease Deming names is what happens when a role-holder uses “our situation is different” as a reason to skip the principle altogether, rather than as the reason the principle needs local judgment to land. A role-holder who treats the exception as permission to skip the principle entirely has caught exactly the disease Deming diagnosed, and the ten principles this piece keeps returning to are Deming’s universal remedy for it.

What This Article Actually Covers, and Why

The roles treated here with genuine operational detail are three, not five: leadership judgment about what to mandate, executive integration after a role change, and principle application by a role with no formal authority to fall back on. Each of those three draws on a named, sourced case: a practitioner’s own stated rule, a documented Harvard Business Review failure, and a Lean Enterprise Institute claim backed by thousands of interviews. Reading all three side by side is what makes the working comparison later in this piece possible; without the named specifics in each case, a comparison would collapse back into the same generic role language this piece is built to avoid.

Product Owner and System Architect both appear later, in the working comparison, because the same distinction, principle application as a lever separate from a role’s title, applies to them too. But no named, sourced material specific to either role sits behind that claim the way it does for the three roles treated in full below. Stating that limit here, rather than papering over it with generic role-catalogue language, is what separates role-specific principle application from a job-description exercise: the claim is only as strong as what backs it, and a claim without a named case behind it is worth stating honestly rather than dressing up as equivalent to the three that are sourced.

---

The Leadership Role’s Actual Judgment Call: What to Mandate, What to Leave to the Team

Mike Cohn, writing on Mountain Goat Software’s blog, answers a question leaders in Release Train Engineer-adjacent roles ask him constantly: yes, a leader has the standing to mandate a specific tool or coding standard on a self-organizing team, provided the mandate respects a hard, unstated limit on how many rules a team can absorb before it stops organizing itself. Getting the mandate right is not about whether you have the authority: you almost always do. It is about reading, in the moment, how close a specific team already sits to that limit.

Cohn’s Answer: Yes, a Leader Can Mandate a Tool or Standard

Cohn states the answer to the mandate question without qualification: “if you’re a leader in your company and have the organizational clout to make dictates: Go ahead” (Mountain Goat Software). The Agile Practice Guide frames the boundary this answer sits inside: a self-organizing team decides among its own members who does which piece of work and how, which is the decision space a leader’s mandate has to leave intact even while imposing a constraint on top of it Agile Practice Guide (Agile Alliance).

Cohn’s answer only sounds permissive until you read the warning attached to it. A leader mandating a tool is not overriding self-organization; self-organization was never a promise that a team decides everything, only that a team decides how it does its own work inside whatever constraints leadership sets. The judgment call a Release Train Engineer or program leader actually faces is not “can I impose this,” which is almost always yes, but “does this specific team, at this specific moment, have room left to absorb one more imposed rule without the whole arrangement souring.” That second question is the entire content of the judgment call; the first question, standing alone, tells a leader almost nothing about whether a specific mandate will land or backfire.

Cohn’s Named Examples

The Team-Defined Coding Standard and the Shared Testing Tool

Cohn’s own supported examples stay inside a narrow band, and each one governs the interface between teams rather than any single team’s internal process. A coding standard the team itself defines, rather than one handed down externally; one common testing tool required across five teams so people can move between them; one shared JavaScript library so programmers on different teams can help each other directly: each example keeps the mandate aimed at the shared surface where teams meet, not at the internal working habits of any single team.

That distinction is the mechanism, not a footnote to it. A leader mandating a shared testing tool is standardizing the surface where teams meet each other; a leader mandating how any one team writes its own tests would be reaching past that surface into territory Cohn’s answer never actually covers. Reading Cohn’s three supported examples side by side gives a Release Train Engineer a working test for a proposed mandate: does it govern the interface between teams, or does it reach into one team’s internal process: the first is the shape of mandate Cohn defends, the second is the shape his warning targets.

The CEO Who Mandated Java Over COBOL in 2000

Cohn’s sharpest example is a CEO who mandated that her team use Java despite being unable to explain the difference between Java and COBOL. The decision landed in 2000, the same year Sun Microsystems announced a $100 million “Java Fund” of venture capital available to companies that adopted Java, and Cohn says directly that he supported her in it: the CEO had a specific, defensible economic reason for the mandate even though she had no technical grounds for it herself.

That example matters because it separates two things people usually collapse into one: technical competence and standing to mandate. The CEO’s authority to impose the Java decision came from the economic case behind it, the prospect of the Java Fund’s venture capital, not from any personal fluency with the languages involved. A leader applying this principle does not need domain expertise in what they mandate; they need a defensible reason a team can eventually see for itself, even if the team can’t see it on day one.

The Limit: ‘One Rule Too Many’ and the Self-Organization Precipice

Cohn names the exact failure mode a leader risks by stacking mandates on a self-organizing team, one too many at a time. “You can give the team any rule you want,” he writes, “but if you give them one rule too many, they’ll shut down,” pushing a self-organizing team over what he calls a precipice into feeling that “management just tells us what to do” (Mountain Goat Software). The threshold is not a fixed number of rules that applies everywhere; it is specific to each team’s own tolerance, built up or spent down by every mandate that came before this one.

That is why this section frames the mandate decision as a judgment call rather than a formula: a Release Train Engineer weighing a fourth or fifth mandate against a team already stretched sparse is making a different call than the same leader weighing a first mandate against a fresh team. The mechanism a leader actually applies is case-by-case reading of where a specific team sits relative to its own precipice, not a principle-level rule that says mandates are always fine or always forbidden. Miss that reading once, on the wrong team at the wrong moment, and the team doesn’t negotiate the next mandate: it stops organizing itself at all.

What Does Recovery Look Like Once a Team Has Shut Down?

Cohn’s precipice metaphor implies a team can be pushed past the point where it re-engages voluntarily, and neither of his named examples addresses what a leader does once that has already happened. The practical answer sits inside the same logic Cohn already lays out rather than outside it: because the threshold is specific to each team, not a fixed count of rules, recovery means handing a specific team back a piece of decision space it can name, not applying a more precise formula to the mandates already stacked on top of it. A leader who has already pushed a team past the edge does not fix the outcome by counting the next round of rules more carefully; the fix is visibly restoring some piece of the internal process the team lost, then reading, again, case by case, whether that specific team starts organizing itself around it again. The self-organizing decision space the Agile Practice Guide protects is the same space a leader has to be seen giving back, not merely stop encroaching on, before a team’s trust in its own authority returns.

---

Installing a Role Is Not Applying It: The Executive Integration Gap

Mark Byford, Michael Watkins, and Lena Triantogiannis, writing in Harvard Business Review, document an executive who received every logistical piece of onboarding a new hire is supposed to get and still failed within his new role because none of it amounted to integration into how the business actually operated. Their case draws a line this section generalizes past one executive: a title, systems access, and an introduction to the team install a role’s paperwork, not its principle-level fluency, whatever the role happens to be called.

The Energix Case: Lucas Jacobsen’s Move From a Fortune 100 Firm

Byford, Watkins, and Triantogiannis document an executive they call Lucas Jacobsen, who left a Fortune 100 diversified manufacturing firm after more than a decade in the role. He moved to head up R&D at Energix, a smaller, rapidly growing manufacturer of power system instruments (Harvard Business Review, May-June 2017, HBR). Jacobsen’s prior firm had given him a decade to absorb its scale and its politics gradually; Energix gave him none of that runway.

The outcome the case documents is specific: Jacobsen’s hard-driving style, combined with misconceptions his new peers held about what his mandate actually was, led to friction with those peers and, ultimately, his departure. Nothing about his competence changed between the two jobs. What changed was the size and culture of the system he was operating inside, and nothing in his transition addressed that gap directly. The case reads less like a story about one difficult executive than a story about how little “installed correctly” guarantees about “operating correctly,” a distinction the next two sections carry past this single case. Byford, Watkins, and Triantogiannis frame the case as typical rather than unusual: a competent, well-regarded leader, moved into a materially different operating environment with no mechanism built to translate between the two.

What Energix Gave Him, and What It Didn’t

Energix’s onboarding covered the logistics cleanly; every item a standard onboarding checklist would mark complete. HR and IT set Jacobsen up in their systems, his boss introduced him to the team, and he received a brief overview of the role. What Energix left out was any cultural integration into how this much smaller business, with its consensus-driven culture, actually operated day to day; Jacobsen was left to figure out how things “really worked” on his own, with no one assigned to translate the difference between his old firm’s scale and this one’s.

That gap resembles a mismatch HBR’s own guidance on applying for a role you’re overqualified for names directly: the guidance’s core advice is to acknowledge the seniority mismatch openly rather than assume years of experience transfer automatically to a smaller, differently structured environment (HBR). Jacobsen’s situation ran the same risk in reverse. A decade of Fortune 100 seniority did not automatically translate into fluency with a consensus-driven culture a fraction of that firm’s size, and nobody at Energix built a bridge for that translation. The two pieces of guidance point at the same failure from opposite directions: one warns the candidate to name the mismatch before it becomes a liability, the other shows what happens when nobody, candidate or employer, names it at all.

Onboarding Versus Integration: The Distinction This Article Generalizes

The Jacobsen case draws a distinction that holds for any newly installed role, not only an R&D executive: role onboarding and role integration measure two separate things, not one thing at two depths. Onboarding covers systems access and a team introduction; integration covers how things actually work, and a role can receive full onboarding logistics while still failing at integration entirely. Completing one axis says nothing about progress on the other.

Generalized past Jacobsen, the point is this: a title, systems access, and an introduction to the team install a role’s paperwork. They do not install a role’s principle-level fluency, the judgment about which principle applies to a given local situation and how, whatever the role is called or how senior the person filling it. A Product Owner moving between organizations, an Architect moving between value streams, faces the identical gap between being installed and being integrated that Jacobsen faced, even though neither shows up in a sourced case the way his does. The practical test a newly installed role-holder can run on themselves is simple: can you name, specifically, how this system’s culture differs from the one you came from, or are you still assuming your last environment’s defaults still apply here.

What Would a Genuine Integration Mechanism Have Looked Like?

Byford, Watkins, and Triantogiannis’s case names what Energix left out, cultural translation, without spelling out what filling that gap would actually have required. The shape of a fix follows directly from the shape of the gap: a genuine integration mechanism looks less like an item added to an onboarding checklist and more like a person assigned to do for Jacobsen what nobody at Energix did, translate the operating differences between a Fortune 100 manufacturer and a much smaller, consensus-driven one, explicitly and early, rather than leaving him to infer them from friction after the fact. Nothing about that mechanism requires new authority or a new title; it requires someone treating cultural translation as a defined task with an owner, the same way HR and IT already treated systems access as a defined task with an owner. That a company can install a title flawlessly while leaving integration entirely to chance is the asymmetry the Jacobsen case documents, and closing it costs a good deal less than the departure it produced instead.

---

Applying Principles Without Positional Power

A Lean Enterprise Institute author, its Learning Activities Manager, draws on more than 2,500 interviews conducted across eight companies in three countries to state a claim this section turns into an operating rule: applying a lean practice visibly and repeatedly is what earns a role authority, even when that role carries no positional power at all. That claim inverts the usual assumption about influence, that authority has to exist first, before a practice can be applied credibly, and gives a role like Scrum Master, famously light on formal authority inside SAFe, its actual lever.

The LEI Claim: Earning Authority Without a Title

The Lean Enterprise Institute author states the claim directly, drawn from more than 2,500 interviews across eight companies and three countries. A3 Management practice, the author writes, lets someone “lead by example and earn the authority to lead change, even when or if we’re not in a role with positional power” (Lean Enterprise Institute). The same source frames the practice as broader than problem-solving alone: “a method through which we can coach and mentor others,” better understood as A3 Thinking than narrowly as A3 Problem Solving, engaging scientific thinking as a way of discovering and learning together rather than a template for writing reports.

For a role without formal authority, that approach changes what the actual lever is. A Scrum Master cannot mandate the way a Release Train Engineer can; the practice itself, done visibly and repeatedly enough that colleagues start to recognize the pattern, is the only mechanism available for building standing. Authority in this shape isn’t granted at the start: it accumulates, one visible instance of applying the practice at a time, until colleagues start deferring to the pattern rather than to a title. The 2,500-interview base behind the claim matters here too: it is a pattern the Lean Enterprise Institute author observed repeatedly across companies, not a single anecdote generalized past what it can support.

Two Named Warnings About Practice Without Embrace

Womack: Tools Need a Lean State of Mind to Work

Jim Womack, in a related Lean Enterprise Institute piece on A3 reports, warns that a tool by itself cannot deliver the result it promises. Tools, he writes, “can’t achieve their potential results, and often can’t achieve any results, without managers with a lean state of mind to wield them” (Lean Enterprise Institute). Womack’s warning targets a specific failure people commit constantly with A3s and similar tools; treating the document as the mechanism, when the document was only ever a vehicle for the thinking underneath it.

For a role applying a principle without positional power, Womack’s warning sharpens the earlier claim about earned authority: the practice has to actually be a practice, mind attached, not a form filled out to demonstrate compliance. A Scrum Master who fills out A3 forms without engaging the underlying scientific thinking is going through motions that will not accumulate into the authority the LEI claim describes: the form alone convinces no one.

Shook: Unembraced Practice Becomes Corporate Wallpaper

John Shook, quoted in the same piece from his book Managing to Learn, names the specific failure mode when an organization never embraces a practice at scale. Without that embrace, he writes, the practice “degenerate[s] into a check-the-box exercise” and joins “unused SPC charts, ignored standardized work forms, and disregarded value-stream maps as corporate wallpaper” (Lean Enterprise Institute). Wallpaper is decoration everyone has stopped seeing: the artifact still hangs there, technically present, doing no work.

Shook’s warning and Womack’s warning point at the same failure from two directions: Womack names what an individual tool needs to work, and Shook names what happens organization-wide when that requirement goes unmet at scale. For a role building authority through visible practice, the two together set a bar higher than simply doing the exercise once: a single A3 written and filed does nothing to build standing; only a pattern the organization can’t help but notice, repeated past the point where it could be mistaken for a one-off, does that work.

The Combined Rule for Roles Without Positional Power

For a role like Scrum Master, which starts with essentially no positional power to mandate anything, the combined rule from the claim and the two warnings above is specific. The practice, done visibly and repeatedly enough that it can’t be mistaken for a check-the-box exercise, is the only lever available for building standing. There is no shortcut through title or org-chart position, because for this role-shape none exists to take: the leadership role’s mandate authority and the executive’s installed title are both simply unavailable here, which is exactly why the practice has to carry the entire weight on its own.

That rule reframes what a Scrum Master without formal authority is actually doing when they run a retrospective well or coach a team through a structured problem-solving cycle for the third or fourth time. They are not performing a ritual the org chart requires; they are running the only mechanism this role has for earning the standing a Release Train Engineer starts with by title. Skip the repetition, and the practice reads as corporate wallpaper before it ever builds anything: one well-run session convinces no one, and the difference between a habit and a one-off is exactly what colleagues are watching for, whether they say so or not. A Scrum Master who understands this rule stops asking whether they have permission to lead and starts asking whether their last few weeks of visible practice have actually accumulated into something colleagues would call a pattern.

---

Applying the Same Principle Differently by Role: A Working Comparison

Three role-shapes emerge from the sourced material above, and putting them side by side shows a practitioner something none of the three sections alone can show: which shape a given decision actually puts them in, regardless of what their SAFe title says. Knowing your title tells you almost nothing about which of these three shapes governs your next decision; knowing the decision does.

When the Decisive Moment Arrives: Recurring, Once Up Front, or Accumulating

The three sourced role-shapes differ first on timing; when the moment that determines success actually lands. The leadership role’s mandate judgment recurs on a clock that never resets, but unlike the other two axes, each well-read mandate banks confidence into the next one, so the recurring call gets easier to make correctly even though it never stops recurring. The executive role’s gate, as the Energix case showed, closes early and does not reopen: a harder deadline than the leadership clock’s recurring one, which forgives a bad read as long as the next read is better. The role without positional power runs the slowest fuse of the three: it never slams shut the way the executive’s window does, and it never resets the way the leadership clock does either, so patience substitutes for the vigilance the other two shapes demand.

Those three clocks explain why the same person can feel confident in one role-shape and exposed in another within the same week. A leader who has already earned trust through a dozen well-judged mandates still faces a fresh judgment call on the thirteenth; timing never stops recurring for that shape. An executive who nails the case-by-case judgment perfectly still only gets one shot at the integration gate; there is no thirteenth try. And a role with no positional power gets no single test to pass at all, only a slow accumulation that either builds or doesn’t. None of the three clocks is inherently harder to satisfy than the others: each simply demands a different kind of attention, recurring vigilance for one, a single high-stakes window for the second, patient consistency for the third.

What Each Role-Shape Can and Cannot Impose

The Three Mandate Positions Side by Side

The second axis is mandate; what each role-shape can and cannot impose on the people around it. The leadership role can impose team-facing constraints, inside the limit that role’s own judgment has to read case by case. The executive’s axis is title and logistics, not standing: those install on day one, while credibility with new peers cannot be imposed at all. The role without positional power can impose nothing at all; the checkable signal to watch for is a peer citing the practice unprompted, without being asked to weigh in: the first sign standing has accumulated rather than merely been performed.

Role-shape	When the moment that determines success lands	What it can impose	What it cannot impose
Leadership / RTE-adjacent	Recurs with every new mandate	Team-facing constraints, within a read tolerance	A rule past the team’s absorption limit: the one constraint of the three that eases as trust rebuilds, unlike the executive’s non-renewable window or the no-power role’s slow accumulation
Executive	Once, up front, before peers form a view	Title, systems access, logistics	Credibility with new peers
No positional power (e.g. Scrum Master)	Accumulates across repeated practice	Nothing by position	; standing has to be earned, not imposed

Something still has to happen inside every one of these three shapes regardless of what a role can or cannot impose: a real conversation between the people involved. Agile Alliance’s own glossary entry for the Three C’s, Card, Conversation, Confirmation, names that conversation as the part no role-shape here can skip or delegate away Three C (Agile Alliance). A leader can impose a testing tool, but the conversation about how the team actually uses it still has to happen; an executive can have a title installed, but the conversation that builds peer trust still has to happen separately.

Which Shape a Given Decision Puts You In, Whatever Your Title

A practitioner works out which of the three shapes a specific decision puts them in by asking three questions in sequence. Can I impose this outcome directly, am I new to this room, and does my standing here rest on repetition rather than position? The answers, not the SAFe title on a badge, determine which of the three clocks and which of the three mandate positions actually applies to the decision in front of them right now.

A Release Train Engineer is the clearest example of how fluid this can get inside a single role. In a decision about whether to impose a shared Definition of Done across every train on the ART, that RTE occupies the leadership shape; recurring judgment, team-facing mandate authority, a limit to read case by case. In a decision about whether a newly formed cross-ART working group trusts their judgment on a matter outside their usual remit, the same RTE occupies the no-positional-power shape: no ability to impose trust, only the option to earn it through visible, repeated practice. The title on the badge never changes; the shape the decision puts them in does.

The Coverage Limit and the Single Test for Any Role

The same distinction this comparison runs, principle application as a lever separate from role title, applies to a Product Owner or a System Architect exactly as much as it applies to the three role-shapes sourced above. No named, sourced material specific to either of those two roles backs that claim here the way Cohn’s mandate rule, the Energix case, and the Lean Enterprise Institute’s authority claim back the three role-shapes already covered. Stating that limit plainly is more useful to a practitioner than inventing detail the sourcing doesn’t support, and it leaves the Product Owner or System Architect reading this with an honest starting point rather than a false sense that their role has been fully mapped.

What carries across every role this comparison covers, sourced or not, is a single test; call it the role application test: what does the role-holder do differently in their very next specific decision when applying the principle, rather than what a title’s job description says they should do in general. A Product Owner asking that question about their next prioritization call, or a System Architect asking it about their next design trade-off, is running the identical mechanism Cohn’s mandate judgment, Jacobsen’s integration gap, and the Lean Enterprise Institute’s practice-based authority all demonstrate in roles where the sourcing already exists.

---

Summary

Role-specific principle application is not a role catalogue with extra detail bolted on; it is a test run against a role-holder’s next specific decision, and the three sourced cases above show that test taking a different shape depending on what a role can and cannot impose.

The Test Replaces the Catalogue

A role catalogue answers what a title is supposed to do in general. The test this piece has run through three sourced cases answers something more specific: what does a person do differently on their next decision, when a principle rather than a job description is what actually drives the choice. Cohn’s mandate rule shows the test running on a recurring clock, checked fresh against a specific team’s tolerance every time a leader considers imposing something new. The Energix case shows the same test failing quietly, every onboarding box checked, the integration test never actually run, which is why Jacobsen’s departure reads as a role installed rather than a role applied. The Lean Enterprise Institute’s authority claim shows the test running on the slowest clock of the three, accumulating across repeated visible practice rather than resolving in any single moment.

What ties the three together is that none of them can be satisfied by holding the title. A Release Train Engineer’s actual task on the next mandate is narrower than the title suggests: read this specific team’s remaining tolerance before adding to it, not just confirm you have the authority to add to it. An executive is still working inside the one-shot window the Energix case describes, and the role-application test above is what tells them whether that window is still open or already closed. A role with no positional power should treat that same test as a standing question about next week specifically: what visible instance of the practice, run in the next few days, adds to the pattern colleagues are already watching for. The working comparison above turns that shared structure into something usable: ask which of the three clocks and which of the three mandate positions a specific decision puts you in, and let that answer, not the badge, decide what you do next.

What Stays Untreated, and Why That Boundary Matters

Product Owner and System Architect both sit inside the same principle-application logic traced through the leadership, executive, and no-positional-power roles above. Neither carries a named, sourced case here the way Cohn, Jacobsen, and the Lean Enterprise Institute’s interview-backed claim do for the other three, and that gap is stated directly rather than papered over with generic role-description language, because the alternative, inventing a Product Owner case or an Architect anecdote to round out a five-role set, would trade a real, checkable claim for a decorative one, and decorative claims are exactly what Deming’s epigraph and Shook’s corporate-wallpaper warning both target.

The practical consequence for a reader in either of those two roles is not that the test above doesn’t apply to them, it applies identically, but that they have to run it without a documented case to check their instincts against. A Product Owner reading this has three worked examples of what running the test well or badly looks like in adjacent roles, and no substitute for doing the same reading, case by case, inside their own decisions. As SAFe implementations mature past their first rollout and move toward operating at scale, that case-by-case habit, checking a specific decision against a principle rather than against a remembered rule, is the difference between a role that keeps working as conditions shift and one that quietly reverts to reciting a job description once nobody is watching closely enough to notice the difference.