Organize Around Value

Organize Around Value fails when the org chart survives a rename. This breaks down why Conway's Law makes architecture mirror the old silos anyway.

Most reorganizations that call themselves value-stream transformations never touch the mechanism that actually blocks flow: the org chart underneath the new labels. Teams get renamed Agile Release Trains, roadmaps get renamed epics, and the same handoffs that stalled work under the old structure persist intact; because Organize Around Value is a structural claim, and renaming a department doesn’t make it true.

---

What Organize Around Value Means as SAFe Principle #10

SAFe’s tenth Lean-Agile principle instructs enterprises to structure Agile Release Trains, funding, and governance around the end-to-end flow of customer value rather than around the functional departments a business grew to run itself: a deliberate structural choice SAFe frames as a dual operating system, not a naming exercise. The gap between stating that choice and living inside it is where most transformations quietly fail: leadership approves the principle in a slide deck, then leaves the reporting lines that actually decide who talks to whom completely untouched.

Principle #10 as SAFe States It: Mik Kersten’s From Project to Product Epigraph

SAFe opens its own page for Principle #10 with a warning from Mik Kersten’s From Project to Product: applying management frameworks from a hundred years ago to organizations competing in the digital age is futile. The line names SAFe’s own target directly, before the principle’s content even starts: the industrial-era management structure most enterprises still run on (Scaled Agile Framework).

That structure, SAFe’s authors argue, was never built for what a digital-age enterprise needs to do, which is sense and respond to customer demand faster than a hierarchy of approvals can move. Kersten’s book, cited as the epigraph for a reason, makes the case that the artifacts of software work, projects, tickets, sprints, obscure the thing that actually matters to a business, which is whether value is flowing to a customer at all. SAFe borrows that lens wholesale: a project-centric organization measures activity, and an organization built around Principle #10 measures flow instead. Reading Kersten’s warning as SAFe’s chosen opener sets the terms for everything that follows: the wrong structure produces the wrong economics, quarter after quarter, without anyone being able to point to a single decision that caused it, and by the time the pattern is visible in the numbers, the structure producing it has usually been in place for years.

The Dual Operating System: Why the Hierarchy Overtakes the Network

SAFe describes every growing enterprise as running two systems at once: an entrepreneurial Network optimized for speed and adaptability, and a Hierarchy optimized for efficiency and stability, both required to be Agile despite opposite purposes (Scaled Agile Framework). Early in a company’s life the Network runs the show by default; people cooperate directly around customer needs because there’s no formal structure yet to get in the way, and staying close to the customer is survival rather than a discipline, so without it the business fails fast.

Success changes the incentives. As the enterprise grows, it builds the Hierarchy it needs to support HR, finance, governance, and operations at scale: the “time-tested management structures” every functioning enterprise eventually requires. The failure mode SAFe names directly is what happens next: the work of maintaining the Hierarchy overtakes the work of the entrepreneurial Network, and the organization’s ability to deliver the right product to the right customer at the right time quietly erodes. Nobody decided to slow down. The org chart simply started rewarding the people who kept the Hierarchy running smoothly over the people who kept customers served, and the two operating systems stopped pulling in the same direction. SAFe’s answer isn’t to dismantle the Hierarchy, stability still matters, but to restore the Network’s speed and innovation as a parallel, permanent structure rather than a phase the company outgrows. That parallel structure has its own name, which the next section takes up directly.

Development Value Streams and Operational Value Streams: Allen Ward’s Distinction

SAFe organizes the flow of value into two named categories, and knowing which one you’re looking at determines what “organize around value” concretely requires of a given team. Allen Ward’s line from Lean Product and Process Development, “the aim of development is, in fact, the creation of profitable operational value streams”, sits as the epigraph on SAFe’s own Development Value Streams page for exactly this reason: it states the economic purpose behind the whole distinction before defining either term Development Value Streams (Scaled Agile Framework).

Development Value Streams

A Development Value Stream is the sequence of activities needed to convert a business hypothesis into a digitally-enabled solution that delivers customer value, and each one comprises one or more Agile Release Trains. It starts from an idea or a requirement and runs through design, coding, testing, and deployment; everything a team does to turn “we think customers want this” into a shipped, working solution.

The reason SAFe maps this sequence out explicitly is to find where waste hides: a DVS mapped end to end shows exactly which transition is slow, which approval queue is long, and which step adds nothing a customer would pay for. Teams that never draw this map keep optimizing the steps they can see, their own sprint velocity, their own backlog, while the actual bottleneck sits in a transfer between two teams that neither one owns.

Operational Value Streams

An Operational Value Stream describes the activities that deliver a product or service to a customer once it exists; fulfilling an order, admitting and treating a medical patient, underwriting a loan. Ward’s line is the bridge between the two categories: development work only earns its cost when it produces an operational value stream that is itself profitable and ongoing, not a one-time deliverable that gets thrown over a wall.

That distinction matters because it stops teams from treating “we shipped it” as the finish line. A Development Value Stream that produces a feature nobody in the operational value stream actually uses has organized around output, dressed in Principle #10’s language, rather than around value. The two value stream types stay linked through every Agile Release Train launch that follows this principle, and the workshop that draws those lines is where the abstraction turns into an org chart.

Principle #10 Among the Ten SAFe Lean-Agile Principles

Principle #10 sits last in SAFe’s numbered list of ten Lean-Agile Principles, and its position undersells its role: the other nine principles assume the structure this one produces is already in place. Taking an economic view, applying systems thinking, decentralizing decision-making: each of those principles presumes a team boundary that lets a decision get made locally instead of escalated across three departments, and that boundary only exists if the enterprise has actually organized around value rather than around function.

Reading Principle #10 in isolation is where most misapplication starts. A portfolio can decentralize decision-making on paper and still route every meaningful choice through a functional silo that Principle #10 was supposed to dissolve, because decentralization only works inside a structure that puts the people with the context next to the people with the authority. The dual operating system just described functions as the precondition beneath the rest of SAFe’s Lean-Agile Principles: the systems thinking, fast learning cycles, and decentralized authority they each describe all depend on a structure like this already being in place.

That ordering has a practical consequence for anyone auditing a transformation that already claims to have adopted all ten principles. Checking whether an organization has genuinely organized around value is a faster diagnostic than auditing all ten principles individually, because most of the visible symptoms of the other nine failing to take hold, decisions escalating instead of being made locally, systems thinking staying theoretical because no one owns the whole system, fast learning cycles stalling because feedback has to cross departmental lines to reach the people who could act on it, trace back to the same root cause. An enterprise that gets Principle #10 right tends to find the rest of the list easier to apply: the other nine don’t become automatic, but the structural obstacle that was blocking all of them at once is finally gone.

---

Why Functional Silos Break Value Flow

Functional silos block value from flowing because a valuable increment requires collaboration across departmental boundaries built for specialization rather than speed, and that collaboration cost gets paid on every piece of work regardless of what the org chart calls the teams involved. Most leaders can name their own silos in ten seconds; the harder part is recognizing that the Agile transformation already running inside those silos left the walls standing and simply gave them better job titles.

The Named Silos: Business, System Engineering, Hardware, Software, Testing/QA, Operations

Scaled Agile’s own customer-centricity guidance names the specific silos value gets trapped in: business, system engineering, hardware, software, testing/QA, and operations (Scaled Agile). These aren’t arbitrary categories: each one exists because specialization lets an organization grow and manage its people effectively, which is exactly why so many enterprises are built this way in the first place and why the structure persists long after it stops serving the customer.

The persistence is the point. Even organizations actively pursuing business agility keep this shape, because from a change-management perspective it’s far easier to keep the current departmental structure and layer Agile ceremonies on top of it than to redraw the boundaries entirely. That shortcut shows up in two familiar forms: Agile teams built to map onto specialized components or subsystems, and Agile Release Trains built around entire departments or functions. Both preserve the org chart’s real shape while adopting Principle #10’s vocabulary, which is precisely why the next question, does an Agile team inside a silo actually fix anything, has to be asked directly rather than assumed.

Each of these six silos evolved for a defensible reason on its own terms. System engineering specialists shouldn’t have to relearn testing discipline every time a release ships; operations staff shouldn’t have to become hardware experts to keep a production environment running. The specialization inside each silo is genuinely valuable, and Principle #10 targets something narrower: the assumption that grouping people by specialty already answers the separate question of how to group them around the customer outcome they jointly produce. Those are two different organizing questions, and most enterprises answer only the first one, then act surprised when the second one goes unaddressed for years.

Why an Agile Team Inside a Silo Doesn’t Fix the Silo

An Agile team formed inside an existing functional silo inherits that silo’s boundary along with its ceremonies, so it can run flawless two-week sprints and still fail to deliver anything a customer experiences as valuable. This is the mechanism behind the most common Agile-transformation disappointment: value doesn’t flow in silos, regardless of how well any single silo executes, so leadership sees stand-ups, retrospectives, and burndown charts running on schedule and assumes the underlying problem is solved, while the thing that actually determines whether customers get value, cross-silo collaboration, never changed shape.

The failure emerges as a specific, recognizable pattern rather than a vague sense of slowness. A component team owning “the payments module” or “the search service” delivers its increment on time, every sprint, and the increment sits unintegrated because the team that owns the checkout flow it plugs into is two sprints behind on its own committed work. Neither team is failing by its own local metrics. What’s failing is the system connecting them, which no team’s Agile ceremony was ever designed to fix, because the ceremony operates inside the silo’s boundary, not across it.

The deeper cost is that these so-called Agile teams struggle to see how their work builds up to something valuable for the customer at all. A system-engineering team optimizing its own throughput has no direct line of sight to whether the customer’s order actually shipped, admitted patient actually got treated, or loan actually got underwritten: the silo’s walls are exactly what cut off that sightline, so the team has no way to tell whether a spec it shipped on schedule actually solved the customer’s problem until the gap surfaces downstream, usually as rework nobody budgeted for and nobody inside the silo saw coming. Local optimization inside a silo, at any speed, produces local metrics that improve while the customer-facing outcome stays flat or degrades, and that gap is exactly what Principle #10 is written to close.

The Value Stream Network: Development Value Streams Running Parallel to the Hierarchy

SAFe’s structural alternative to the silo is the Value Stream Network, a layer that runs parallel to the organizational hierarchy rather than living inside it, built from Development Value Streams as its organizational construct (Scaled Agile). It’s where the essential work of defining, implementing, and supporting digitally enabled solutions actually happens. The word “parallel” is doing real structural work here: the hierarchy that runs HR, finance, and governance doesn’t get dismantled, and the Value Stream Network doesn’t report up through it as one more department: it exists alongside it, with its own boundary defined by the flow of value rather than the flow of budget approvals.

That parallel placement is what lets a Development Value Stream cut cleanly across business, system engineering, hardware, software, testing/QA, and operations without asking any of those functions to give up their own internal structure. A well-formed DVS pulls the specific people it needs from each function, for the duration the value stream requires them, rather than waiting for those functions to reorganize themselves first. The portfolio-management literature backs this up at scale: an Agile Alliance experience report on managing a shared portfolio backlog across a large organization documents exactly this challenge, coordinating many teams pulling from a common backlog without collapsing back into functional queues (Agile Alliance). Defined correctly, a Development Value Stream is what makes the promise of Principle #10 operational rather than aspirational: not a rename of the silo, a structure the silo now has to feed.

Art Byrne’s Wiremold Case: From ‘One Man-One Machine’ to Small Teams

Art Byrne’s account of leading Wiremold’s lean turnaround predates Agile software development by three decades: moving from batch to flow meant shifting from “one man-one machine” to small teams responding directly to customer demand Art Byrne (Lean Enterprise Institute). Byrne was describing a manufacturing baseline organized the same way SAFe describes a pre-transformation enterprise: specialists doing their piece, handing it downstream, with nobody accountable for whether the finished product actually reached the customer on time.

Byrne’s shop-floor experience sits inside a longer lean lineage than SAFe usually credits directly. Womack and Jones’s five-step lean thinking process, specify value from the standpoint of the end customer, identify the value stream, make value flow without interruption, let the customer pull value from upstream, and pursue perfection by repeating the cycle, is the intellectual ancestor of both Byrne’s factory-floor fix and SAFe’s own value stream language Womack and Jones (Lean Enterprise Institute). Specifying value before mapping the stream that delivers it is the same discipline Bain’s pyramid supplies, value gets defined before a stream gets mapped around it, and identifying, then flowing, the value stream is the same discipline the workshop runs on. Principle #10 didn’t invent this sequence: it gave a decades-old lean discipline a name inside a software-delivery framework.

One Man-One Machine to Flow

The “one man-one machine” model optimizes each individual station: a machine operator runs their equipment at maximum utilization, a department head keeps their team fully booked, and every local metric looks productive. What that model can’t see is the finished product waiting in a queue between stations, because no one’s job description includes the queue; only the stations on either side of it. Byrne’s shift to small, flow-based teams meant reorganizing people around the product’s actual path through the standard rather than around the machines they were trained to run, which is a direct manufacturing-floor precedent for what SAFe later formalized as a value stream.

Level-Loading vs. Large Batch Orders

Byrne’s own illustration of what local optimization costs is concrete: sales soliciting large batch orders while the plant is trying to level-load production. Sales hits its quota by landing a big order; the plant, which had smoothed its schedule to produce steadily and avoid the waste of large batch swings, now has to break that rhythm to absorb the spike, and the resulting disruption shows up as cost nobody in the sales function ever sees or answers for. That’s local optimization in its purest form; two functions each doing their job well, in ways that actively work against each other, because the organization never gave anyone responsibility for the value stream connecting them. It is the pre-software version of the exact pathology Principle #10 targets, which means the fix Byrne found on a factory baseline in the 1990s and the fix SAFe formalizes for software delivery are, structurally, the same fix.

---

How to Run a Value Stream Identification Workshop

A Value Stream Identification workshop is the facilitated session SAFe practitioners run to draw the actual boundaries of a value stream before launching an Agile Release Train around it, replacing the default instinct to reuse existing org-chart lines with a deliberate look at where value genuinely flows. Getting the boundary right here determines almost everything that follows: an ART launched around the wrong boundary inherits the silo problem on day one, no matter how well the workshop itself was run.

Looking Outside Existing Organizational Boundaries to Launch an ART

When deciding where to launch an Agile Release Train, Principle #10 requires resisting the temptation to look within existing organizational boundaries and instead finding a team more optimally focused on delivering value Agile Release Train (Scaled Agile). The candid caveat that comes with this advice is that doing it well is genuinely uncomfortable; in light of organizational politics, looking outside your comfort zone to draw a value stream boundary can be scary, because the boundary you draw determines whose team gets bigger, whose gets smaller, and whose reporting line disappears entirely.

That discomfort is precisely why the org-chart default persists even among teams that know better. A workshop facilitator who lets the room default to “let’s just use the current department structure” has already failed the exercise, because the question a value stream identification session is supposed to answer isn’t “which teams do we have” but “where does value actually flow, regardless of who currently owns which piece of it.” Every subsequent step in the workshop depends on the room being willing to sit with that discomfort long enough to answer honestly.

Facilitators who skip this step tend to discover the cost later, at ART launch, rather than during the workshop itself, when it would have been cheap to fix. A boundary drawn from comfort rather than from the actual flow of value produces an ART whose roster looks reasonable on a slide and whose actual work still routes through the same cross-departmental approvals it always did, because the people who could have redrawn the line chose the easier conversation over the accurate one.

Who Facilitates the Workshop: SPCs and the Skill Threshold

SAFe Program Consultants are the practitioners trained to facilitate a value stream mapping activity, and doing it well is an art mastered only after in-depth study and several events run under a skilled practitioner’s guidance Agile Release Train (Scaled Agile). That candor matters for anyone about to run their first session: the workshop is genuinely harder to facilitate well than the training course makes it feel, and treating it as a checklist to execute rather than a skill to develop is where first attempts tend to go sideways.

SAFe Program Consultants as Facilitators

Every SPC completes training that covers how to facilitate a value stream mapping activity, which means the baseline capability to run a session exists broadly across any organization that has invested in SAFe certification. What the training doesn’t fully transfer is judgment under organizational pressure; knowing when to let a difficult boundary conversation run longer because the room is close to a real answer, versus when a group has gotten stuck relitigating the org chart and needs to be redirected back to the actual question.

Karen Martin’s Value Stream Mapping as the Study Path

For SPCs who don’t get the chance to co-facilitate an event before running their first one solo, Scaled Agile points to two specific resources: Karen Martin’s book Value Stream Mapping and SAFe’s own Value Streams article. Martin’s book supplies the deeper mapping discipline. It covers the actual mechanics of tracing a value stream’s steps, cycle times, and handoffs: the parts a certification course only has time to introduce. A new facilitator who studies it before their first session walks in with a vocabulary for what they’re seeing in the room, instead of discovering the relevant distinctions live in front of the group they’re supposed to be guiding.

Concept to Cash: The Baseline Value Stream Definition

Every workshop in this format runs from the same baseline definition: a value stream is the set of actions that add value to a customer from initial request through realized value, always beginning and ending with a customer Agile Release Train (Scaled Agile). Concept to cash, in shorthand. That definition is doing more work than its brevity suggests; “begins and ends with a customer” rules out drawing a value stream boundary around an internal process step, a technology platform, or a department, since none of those are customers, and a value stream that starts or ends at one of them doesn’t qualify by this definition, whatever it gets called afterward.

Anchoring the whole session on concept-to-cash keeps the room from settling for a partial map. It’s common for a first attempt to stop at “concept to launch”, mapping only the development activity, because that’s the part the room in front of the facilitator actually controls. The definition forces the map further: through delivery, through support, all the way to the moment the customer actually realizes the value they were promised. A value stream that stops short of that moment has been sketched, not identified, and the gap between a sketch and an identified value stream is exactly the gap an ART launched from it will inherit.

Your Operational Value Stream Is Probably Bigger Than You Think

Scaled Agile’s leading facilitation tip is a warning against under-scoping: your operational value stream is probably bigger than you think, and most first-time facilitators draw the boundary too narrow before they ever draw it too wide Agile Release Train (Scaled Agile). The instinct to under-scope comes from the same place as the instinct to default to the org chart: the room finds it easier to reason about the piece of the process they can see from their own department than to trace the full concept-to-cash path through functions they don’t directly work with.

Under-scoping has a specific, predictable cost: the ART that gets launched from a too-narrow value stream inherits a boundary that excludes some step the customer’s value actually depends on, which means that step stays outside the ART’s authority and reintroduces exactly the cross-boundary transfer the whole exercise was meant to eliminate. Correcting for this bias is simple to state and hard to execute under time pressure; push the room past its first answer, ask what happens immediately before the process they’ve mapped and immediately after it ends, and keep extending the boundary until it genuinely starts and ends with the customer, not with the limits of who happened to be in the room.

---

Defining Value Before You Organize Around It: Bain’s Elements of Value

SAFe’s own material tells teams to organize around value without ever supplying a taxonomy of what customer value concretely consists of, which leaves most value stream conversations arguing in the abstract until someone brings in a framework built to answer exactly that question. Bain and Company’s Elements of Value pyramid fills that gap directly, and it comes with a worked example specific enough to resolve arguments a generic “focus on the customer” mandate never could.

Bain’s Elements of Value Pyramid: 30 B2C and 40 B2B Elements

Bain & Company organizes 30 elements of consumer value and 40 of business value into a pyramid modeled on Maslow’s Hierarchy of Needs, running from functional value at the base to aspirational value at the top (Harvard Business Review). Published in Rotman Management Magazine in May 2018, the pyramid shape is the useful part: it treats value as a stack of distinct, separately deliverable elements rather than one thing a product either has or lacks, and a product can be strong on the functional layer while being completely absent from the aspirational one.

That stacking is what makes the framework usable for a value stream conversation rather than just a marketing exercise. Two teams disagreeing about whether their product “delivers value” are usually disagreeing about which layer of the pyramid they mean: one is talking about whether the thing works reliably, the other about whether it makes the customer feel something. Bain’s own stated use case names the practical output directly: compare your value offerings against competitors, identify the specific value gaps that comparison reveals, and look for new combinations of elements competitors haven’t assembled yet. That’s a concrete audit a value stream team can actually run, instead of a values statement they can only agree with in principle.

The iPhone Example: 11 of 30 Consumer Elements Covered

Bain’s own worked example makes the pyramid’s abstraction concrete: Apple’s iPhone covers 11 of the 30 possible elements of value for consumer products (Harvard Business Review). The number matters more than it first appears to; even one of the most commercially successful consumer products in history doesn’t claim all 30 elements, and Bain’s point in choosing this example is that trying to cover every element is neither necessary nor realistic. A product succeeds by covering the specific combination of elements its customer segment actually weights, not by maximizing coverage across the whole pyramid.

That reframes what a value stream team should actually be measuring itself against. Instead of asking “are we delivering value” as a yes-or-no question, a team using this framework can ask which specific elements, of the 30 or 40 available, their current increment targets, and whether that combination matches what their customer segment weights most. A value stream that has never had this conversation is organizing around a word, “value,” that every person in the room is quietly defining differently.

Running this audit against an existing value stream usually surfaces a mismatch worth acting on. A B2B platform team might discover its roadmap is entirely weighted toward functional elements, reliability, cost reduction, integration, while its highest-churn customer segment is actually buying on elements from a different tier of Bain’s pyramid, like reduced risk or simplification of a process the customer used to manage manually. That gap doesn’t show up in a sprint retrospective, because a retrospective asks whether the team delivered what it committed to, not whether what it committed to was the right thing to build in the first place. Locating that gap is the entire point of pairing a value stream’s structural boundary with an actual definition of value before assuming the two automatically line up.

LeSS’s Organizing by Customer Value: The Same Logic Outside SAFe

The Large Scale Scrum (LeSS) framework runs its own Organizing by Customer Value guidance, listing customer-centric thinking and feature teams among its core structural principles for scaling, independent of anything SAFe prescribes Customer Value (LeSS). LeSS arrives at the same structural conclusion from a different starting point: rather than SAFe’s dual-operating-system argument about hierarchy overtaking network, LeSS reasons from Scrum’s own team-level principles scaled up, and lands on the same answer; teams organized around a customer-facing slice of value outperform teams organized around a technical or functional specialty.

Seeing the same structural pattern converge from two independent scaling frameworks is itself evidence worth weighing. It’s easier to dismiss a structural claim as one vendor’s methodology when only one framework makes it; it’s harder to dismiss it once a second framework, built on different foundational assumptions, arrives at the identical structural recommendation through its own reasoning. Feature teams in LeSS and value-stream-aligned Agile Release Trains in SAFe are different vocabularies pointing at the same underlying mechanism: cross-functional ownership of a customer-facing slice beats functional specialization organized around technical layers, regardless of which framework’s terminology a given enterprise happens to use.

LeSS’s own core principles go further than naming feature teams as a structural preference, they list whole-product focus alongside customer-centric thinking, and that focus converges with Bain’s pyramid in a specific way: a team scoped to one specialty’s fragment of the product can usually see and improve the functional layer at the base of Bain’s stack, the elements that make something work reliably, cost less, or save time, but the higher tiers, the ones that depend on experiencing the product as a coherent whole rather than a component, are structurally invisible from inside a fragment, because no single specialty owns enough of the product to know whether those elements are even present. The org chart itself is only ever the mechanism for getting there. A LeSS feature team and a SAFe value-stream-aligned ART are answering the identical design question with different vocabulary, which is exactly why an enterprise running SAFe can borrow LeSS’s diagnostic without adopting any of its ceremonies: ask whether a given team can see the whole product, or only its own layer of it.

---

Making the Reorganization Stick: Change Management and the PMO

Reorganizing from functional silos into value streams is itself a change initiative, and it has to be organized around the purpose and benefits it delivers or it becomes one more entry in a well-documented failure statistic; Principle #10 applied to its own rollout, whether or not the people running the rollout recognize that. Treating the reorg as a structural announcement rather than a change initiative with its own success criteria is the single most common reason a value-stream transformation stalls after the org chart gets redrawn.

The Failure Data: 85% More Change Projects, Only 31% Succeed

The scale of the risk is measurable, and it’s larger than most transformation leads assume before they see the numbers.

Nieto-Rodriguez’s 85% Finding: Change Projects Are Multiplying

Antonio Nieto-Rodriguez’s Harvard Business Review research, published in May 2023, surveyed 1,284 executives and project management professionals and found that 85% had seen the number of change projects in their organizations increase over the previous five years, with 56% of those respondents reporting an increase of more than 25% (Harvard Business Review). A value-stream reorganization lands inside an organization already running more concurrent change than it was five years earlier, competing with every other initiative for the same finite attention and goodwill.

The Standish Group’s 31%: Why Success Is Rare

Nieto-Rodriguez cites the Standish Group’s finding that only 31% of projects are considered successful; meaning 69% of change effort results in wasted resources, blown budgets, or benefits that never materialize. That change project failure rate is the actual backdrop a value-stream reorganization launches into. A transformation lead who treats the redraw of the org chart as the finish line, instead of the start of a change initiative that has to earn its own success against a 31% base rate, is repeating the exact mistake the data describes.

The Reorg Is Itself a Change Initiative

Nieto-Rodriguez’s actual argument goes further than naming change projects as risky: the ones which succeed are organized around the purpose and benefits they deliver, the same discipline Principle #10 asks of a value stream itself. A reorganization announced as “we’re now organized around value streams” without a stated purpose the people affected can see themselves in is structurally identical to a value stream with no customer at either end: activity without a destination.

That structural identity gives a transformation lead a concrete test to run before announcing anything. Ask the same question of the reorg that the workshop asks of every value stream it identifies: who is the customer of this change, what request are they making, and what does realized value look like to them once the change lands? For a value-stream reorganization, the candid answer is usually the people currently working inside the silos being dissolved; their request, whether stated or not, is to spend less time on handoffs and more time on work a customer actually experiences, and realized value is a measurable drop in the cross-team coordination overhead their day previously ran on. A reorganization that can’t answer that question in concrete terms is announcing a structural change without having done the purpose-and-benefits work Nieto-Rodriguez’s research says separates the minority of change projects that succeed from the majority that don’t.

That parallel is worth taking literally rather than treating as a rhetorical flourish. The workshop discipline covered earlier, concept to cash, always beginning and ending with a customer, has a direct analog for the reorg itself: the change initiative should begin with a clearly stated business reason and end with a benefit the organization can actually observe, not simply announce. Skipping that discipline for the reorg while insisting on it for every value stream the reorg produces is the kind of inconsistency people inside the organization notice immediately, even when leadership doesn’t.

Who Loses Power: The PMO’s Scattered Responsibilities and Its Resistance

Naming who loses authority in a value-stream reorganization is more useful to a transformation lead than any generic change-management advice, because unnamed resistance tends to get misread as inertia instead of addressed as a rational response to a real loss.

Mike Cohn’s Diagnosis: Scattered Responsibility and PMO Resistance

Mike Cohn’s account of what happens to project governance under Scrum applies directly to a value-stream reorganization: Scrum scatters traditional project management responsibilities among the ScrumMaster, the Product Owner, and the team itself, leaving project managers questioning what role remains for them Product Owner (Mountain Goat Software). A Project Management Office left out of that transition becomes a source of resistance, defending the current process rather than improving it, because the change is both personally and professionally frightening to the people whose job description the reorganization is quietly rewriting.

That resistance has a rational structure worth taking seriously rather than dismissing as change-averse behavior. A PMO’s traditional value came from centralizing visibility across projects that otherwise ran independently; a value-stream structure distributes that visibility down into the value streams themselves, which genuinely does eliminate the coordination problem the PMO used to solve. The Agile Alliance’s own work aligning the Agile Practice Guide with PMI’s standards points at the same tension from the standards side: a PMO that gets involved early enough to help redesign its own role around value-stream governance persists through the transition; one that gets bypassed until the reorg is announced has every rational reason to defend the ground it’s about to lose Agile Practice Guide (Agile Alliance).

---

Conway’s Law and the Org-Chart ART: Why Your Structure Decides Your Architecture

An enterprise’s software architecture ends up shaped like its communication structure whether or not anyone plans it that way, which means a value-stream reorganization that changes team names without changing who actually talks to whom will still produce the old architecture under the new org chart. SAFe’s Principle #10 material never cites the researcher who proved this thirty years before Agile existed, and that omission has a real cost: teams can align to value streams on paper while their communication topology stays exactly as siloed as it always was.

Conway’s Law (1968): Communication Structure Becomes System Design

Melvin Conway stated the underlying law in 1968, in a paper called “How Do Committees Invent?”: organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations Do Committees Invent (Melvin Conway). Conway wasn’t writing about Agile, SAFe, or even software specifically at first: the paper’s claim was general enough to apply to any design activity, and its author noted decades later that its broader applications, in domains far outside software, were the part he found most interesting about his own thesis.

The mechanism behind the law is almost mundane once it’s named: a system’s parts have to be designed by people who communicate with each other about the interfaces between those parts, so the boundaries that exist in the communication structure inevitably show up as boundaries in the system design. Two teams that rarely talk will produce two components with a crude, poorly negotiated interface between them, regardless of what the architecture diagram says that interface should look like; because the diagram doesn’t build the system, the conversations do. Applied to a value-stream reorganization, this means the org chart redraw is necessary but not sufficient: the architecture will keep mirroring the old silo boundaries for as long as the people inside those silos keep talking mostly to each other and only occasionally to anyone outside.

The Inverse Conway Maneuver and Team Topologies: Skelton and Pais’s Bridge to SAFe

The Inverse Conway Maneuver is the deliberate counter-move to Conway’s Law: design the team structure first, specifically to produce the architecture the organization actually wants, rather than letting architecture fall out of whatever communication habits already exist. Matthew Skelton and Manuel Pais popularized the technique in their book Team Topologies (2019), which has become the primary working bridge between Conway’s Law and value-stream-aligned organizational design (Team Topologies). Where Conway’s original observation is descriptive, this is what happens by default, the maneuver is prescriptive: stop treating team structure as a downstream consequence of the architecture and start treating it as the lever that produces the architecture you want.

Skelton and Pais’s contribution is naming the mechanism precisely enough to act on. A platform team, a stream-aligned team, an enabling team, and a complicated-subsystem team each produce a predictably different shape of software, because each communicates differently with the teams around it: a stream-aligned team talks constantly with the customer-facing feedback loop and rarely with a complicated-subsystem team it depends on, and that asymmetry shows up directly in how cleanly the interface between them is designed. Applied to Principle #10, this is the missing mechanism: drawing a value stream boundary on an org chart is the input to Conway’s Law, not a substitute for understanding it, and a value-stream reorganization that ignores the maneuver is gambling that the architecture will follow the new boundary instead of the old communication habits.

The Org-Chart ART and the Silo Regeneration Pattern: When the ‘Value Stream’ Is the Org Chart Renamed

Two named failure modes describe what happens when a value-stream reorganization skips the Inverse Conway Maneuver and simply relabels the existing structure. Both are worth diagnosing by name, rather than dismissed as a vague sense that “the transformation didn’t really take.”

Dimension	Org-Chart ART	Value-Stream-Aligned ART
Boundary drawn from	Existing management span of control	Concept-to-cash flow of customer value
Architecture produced	Mirrors the department structure it replaced	Mirrors the value stream’s own steps
Cross-team handoffs	Multiply every Program Increment, tracked on a growing dependency board	Minimized by design; the team owns an end-to-end slice
What governance actually manages	Dependency-management ceremony that conceals the silo underneath	Flow metrics, lead time, WIP, time to realize value
Legitimate use case	None, this is the failure mode itself	Platform and component ARTs serving internal teams as customers

The Org-Chart ART

An Org-Chart ART is formed by drawing a circle around an existing management span of control and calling the result a value stream, with the actual value stream identification step hand-waved rather than genuinely worked through, a pattern practitioner Mike Hall has diagnosed directly in reviewing failed launches, and one documented at length in failure-mode research specific to this anti-pattern Mike Hall (SAFe Principles research). The tell is almost always visible in the launch itself: the ART’s roster matches a department’s existing headcount almost exactly, the Release Train Engineer reports into the same management chain the department always had, and the “value stream” boundary was never stress-tested against the concept-to-cash definition covered earlier. It’s a renamed department, not a value-stream-aligned team, and Conway’s Law guarantees its architecture will keep looking like the department it came from.

The Silo Regeneration Pattern

The Silo Regeneration Pattern is the compound, self-concealing failure that follows from an Org-Chart ART launch: the architecture mirrors the silo structure exactly as Conway’s Law predicts, cross-ART handoffs interrupt flow at every boundary the old department lines used to sit on, and each Program Increment the dependency board grows a little larger while the ceremony of managing those dependencies creates the appearance of governance. That appearance is what makes the pattern dangerous rather than merely disappointing: a growing dependency board looks, to leadership reviewing a status report, exactly like active management of a hard problem, when what it’s actually showing is the same problem reproducing itself on schedule, once per PI, with a fresh set of tickets to prove it’s being handled.

The Legitimate Exception: When the Internal Development Value Stream Is the Right Boundary

Not every ART that looks like it’s organized around an internal function is actually an Org-Chart ART in disguise, and treating platform and component-centric teams as automatic violations of Principle #10 misreads what the principle actually requires. For genuinely platform or component-centric products, shared infrastructure, developer tooling, common services, the “customer” is other internal teams, not an external buyer, and organizing around that internal Development Value Stream is the correct application of the principle rather than an exception to it.

The distinction that separates a legitimate platform ART from an Org-Chart ART in disguise is whether the team’s boundary was drawn from a candid value stream identification exercise, with the internal teams it serves treated as real customers whose concept-to-cash journey gets mapped just as rigorously, or whether it was simply inherited from an existing infrastructure department’s reporting line without that exercise ever happening. A platform team that can name its internal customers, trace what those customers need from concept to realized value, and measure flow against that map has organized around value. A platform team that exists because “infrastructure has always been its own department” has an Org-Chart ART wearing a platform label, and the difference only becomes visible once someone actually runs the value stream identification workshop covered earlier.

---

Summary

Organize Around Value asks an enterprise to make its structure answer to the flow of customer value rather than to the convenience of its own departments, and every mechanism involved answers to a single underlying test: does the structure produce the architecture and the flow it claims to, or does it just describe the org chart in new words. The dual operating system, the workshop that draws a value stream’s real boundary, Conway’s Law, and the failure patterns that follow when a boundary is faked are each one piece of that same test, applied at a different point in the process.

Where Structure Becomes Strategy

The dual operating system, the concept-to-cash workshop discipline, and Bain’s Elements of Value pyramid are three different tools pointed at the same decision: what boundary should this value stream actually have, and what does “value” concretely mean inside it. Treating them as sequential rather than optional is the practical takeaway: an enterprise that skips straight to launching Agile Release Trains without first running the workshop, and skips the workshop’s concept-to-cash discipline without first having a shared vocabulary for what value means, ends up with a boundary nobody can defend when the first hard trade-off arrives. The sequencing matters because each tool answers a question the next one assumes is already decided: Bain’s pyramid resolves what value means before the workshop tries to trace it, and the workshop traces the boundary before an ART gets launched around it. Skip a step and the gap stays open: it simply resurfaces later as a dependency nobody planned for.

Every structural decision described so far ultimately answers to the same closing test, already established in economic terms under Development Value Streams and Operational Value Streams: does the structure shorten the distance between a customer’s request and that customer realizing value from it, or does it merely leave that distance unchanged behind a relabeled org chart; regardless of how agile the team feels while working inside it.

The Failure Modes That Demonstrate the Principle

The Org-Chart ART and the Silo Regeneration Pattern function as the clearest evidence that Principle #10 describes something mechanically real rather than an aspirational value statement bolted onto a transformation kickoff deck. A pattern that only fails when it’s faked, and fails in a specific, nameable, Conway’s-Law-predicted way every time it’s faked, has actual mechanical teeth: it makes a testable prediction about what a faked reorganization will look like eighteen months later, and that prediction holds regardless of which enterprise runs the experiment.

That gives anyone about to launch a value stream reorganization a direct, practical diagnostic to run, and it’s a cheaper one than surveying teams about how empowered they feel: the dependency board, already covered above under the Silo Regeneration Pattern. What’s worth stating plainly here is the action that diagnostic implies once the board turns up growing rather than shrinking; better dependency management only manages the symptom; the actual fix is rerunning the value stream identification workshop against the specific boundary that’s failing, this time without defaulting to the org chart the enterprise already had on file.

That diagnostic is also the frank answer to why this principle sits at the end of SAFe’s list rather than the beginning. Take an economic view, apply systems thinking, decentralize decision-making; every principle ahead of it in SAFe’s numbering describes a capability an organization is supposed to have. Organize Around Value describes the structural precondition for actually having it, which is why a transformation that gets every other principle right on paper still stalls the moment its Agile Release Trains turn out to be departments in new clothing. The dependency board doesn’t lie about that the way a survey can.