Apply Systems Thinking

Apply Systems Thinking means managing relationships between parts, not the parts. A M manufacturer and Meadows test show why most teams miss it.

Most SAFe transplants fail after the ceremonies are already running: Iterations get planned, PI boxes get filled, the org chart matches the training deck; yet delivery stalls at the same handoffs as before. Apply Systems Thinking is the principle everyone recites and almost nobody applies, because applying it means managing the relationships between parts, not policing the parts themselves.

---

What Apply Systems Thinking Means as SAFe Principle #2

Principle #2 of the ten SAFe Lean-Agile Principles defines Apply Systems Thinking as a holistic approach to solution development that incorporates every aspect of a system and its environment into that system’s design, development, deployment, and maintenance. That definition reads like a mission-statement platitude until the epigraph that opens the canonical page turns it into an operating instruction rather than a poster line.

Principle #2 as Stated in the Framework

Dean Leffingwell placed Apply Systems Thinking second among SAFe’s ten Lean-Agile Principles, immediately after Take an Economic View, because economic trade-offs only make sense once the boundary of the system being optimized is decided: you can’t calculate cost of delay for a system you haven’t defined.

The Scaled Agile Framework’s canonical page states the definition plainly: systems thinking takes a holistic approach to solution development, incorporating all aspects of a system and its environment into the system’s design, development, deployment, and maintenance. The glossary entry repeats the same core claim in condensed form, which signals that Scaled Agile treats this as a fixed definition, not a phrase open to local interpretation.

Leffingwell’s SAFe 6.0 guidance adds a constraint practitioners routinely skip: the ten principles are underlying reasoning to apply, not a certification checklist to recite. A team that can name all ten principles in order but can’t explain which one governs a specific stalled decision has memorized vocabulary, not adopted the framework’s reasoning. That distinction, reasoning versus recitation, is what the rest of this principle exists to close.

Deming’s Warning: Components That Manage Themselves

W. Edwards Deming’s warning, quoted in full on the canonical Apply Systems Thinking page, states that a system left unmanaged doesn’t drift toward neutral: its components turn selfish and competitive and destroy the system outright. The Scaled Agile Framework’s reads: “A system must be managed. It will not manage itself. Left to themselves, components become selfish, competitive, independent profit centers, and thus destroy the system. The secret is cooperation between components toward the aim of the organization.”

Read that as mechanism rather than motivation, and the sentence contains a diagnosis: unmanaged parts don’t stay neutral, they compete for local advantage, because local advantage is the only signal available to a part that has no visibility into the whole. A team measured only on its own velocity will optimize for its own velocity even when doing so starves the next team in the flow: not from bad intent, but because nothing in its environment rewards anything else.

Deming’s fix, cooperation between components toward the aim of the organization, shows up in role design as well as team design. Agile Alliance’s Product Owner and ScrumMaster partnership paper treats the two roles as a single unit accountable to one shared aim rather than two competing mandates, which is the smallest possible instance of Deming’s cooperation clause: two components, one aim, deliberately wired together instead of left to compete for the same budget line.

The Four Bodies of Knowledge Behind SAFe

SAFe synthesizes four foundational bodies of knowledge, systems thinking, Agile development, Lean product development, and DevOps, and Apply Systems Thinking names the first of the four explicitly, though all four function as one interlocking system rather than four separate checklists to satisfy in sequence.

Systems thinking supplies the boundary-setting discipline: what counts as the system, and what counts as its environment. Agile development supplies the fast-feedback mechanics inside that boundary. Lean product development supplies the flow and waste-elimination discipline that keeps work moving across the boundary instead of pooling at any one part. DevOps closes the loop by extending the system’s boundary all the way to production, so “the solution is a system” includes the pipeline that ships it, not just the code that describes it.

Leffingwell’s SAFe 6.0 positioning treats these four bodies as inputs a leader draws on situationally, not a sequence to complete once. A portfolio stuck on funding decisions needs the systems-thinking and Lean lenses more than the DevOps one; a team stuck on release cadence needs the reverse. Applying Principle #2 well means recognizing which body of knowledge the current stall actually calls for.

---

The Lineage Behind Principle #2: Meadows’ Triad and Ohno’s Accidental System

The systems thinking behind SAFe traces to two independent lineages: Donella Meadows’ formal definition of a system as elements, interconnections, and purpose, and Taiichi Ohno’s Toyota Production System, which emerged from solving problems on the shop baseline rather than from installing a designed methodology. Both lineages converge on the same warning: name a system without checking for interconnection and purpose, and the result is a labeled hierarchy, not a system; which is the exact mistake most framework transplants repeat.

Elements, Interconnections, Purpose: Meadows’ Definition as a Test

Donella Meadows defined a system as “an interconnected set of elements that is coherently organized in a way that achieves something,” a definition worked through in detail by the Lean Enterprise Institute’s Gemba Coach column. The definition sets three tests any claim of “systemness” has to pass: named elements, mapped interconnections between them, and a stated purpose the whole is organized to achieve.

Apply that test to an Agile Release Train that exists on an org chart but hasn’t cleared it: the elements (teams) are named, but if nobody can state the interconnections (dependencies, shared components, transfer points) or the purpose (the specific value stream the train exists to deliver), the ART is a grouping, not yet a system in Meadows’ sense. The gap between grouping and system is exactly where local optimization takes root, because a grouping has no shared purpose to optimize toward; only individual team purposes, which compete by default.

The same column traces “system” back further: the word carries at least two meanings, an interconnected mechanism that is more than the sum of its parts, and an organized method for doing something. SAFe’s Principle #2 uses the first sense deliberately, which is why the canonical definition insists on “all aspects of a system and its environment”; environment is part of the test, not an afterthought.

How TPS Emerged from Problem-Solving, Not Installation

Taiichi Ohno framed the Toyota Production System, in Art Smalley’s translation of Ohno’s original preface, as “a series of related activities aimed at the elimination of waste in order to reduce cost, improve quality, and improve productivity”: a description of activity, not architecture. Nothing in that framing describes a methodology to be installed; it describes what a set of related activities was doing.

Michikazu Tanaka’s account, reported in an Lean Enterprise Institute piece drawing on The Birth of Lean, shows the sequence explicit: Ohno “wasn’t consciously working on any system at first. He was simply [solving problems] and ended up creating a system.” The system was the residue of problem-solving repeated over years, not the starting point.

The same account adds a detail early imitators skipped: not all TPS tools worked even inside Toyota. Some countermeasures Ohno tried failed and were dropped; the tools that endured did so because they solved a real problem in that specific plant, not because a manual specified them. Automotive executives who copied Toyota’s visible tools, the exacting standards, the minimal inventory, the kanban cards, without the underlying problem-solving discipline got the shape of TPS and none of its function, which is precisely what happens when a team runs SAFe’s ceremonies without the reasoning that produced them.

Why Framework Installation Keeps Failing

The mistake early Toyota imitators made outside Japan, copying the visible tools while missing the reasoning that produced them, is the same mistake teams make when they run SAFe ceremonies without applying Principle #2 underneath them. A PI Planning event, a System Demo, a Solution Train sync: each is a tool, and each can be installed correctly while the underlying reasoning about interconnection and purpose stays absent.

An Agile Alliance conference session from Agile2024 names the pattern directly under the title “Traveler, there is no path. We make the road by walking”: a decade of trying to install agile frameworks has not led to the changes organizations hoped for, and the problems from before remain trenched despite ongoing efforts to resolve them through ceremony alone. The session’s proposed corrective, building empathy for the people caught in the middle, and developing a nuanced understanding of the complexity surrounding a transformation, is systems thinking by another name: understand the elements, interconnections, and purpose before touching the tools.

That is the practical cost of skipping Principle #2. A framework installed without it produces the appearance of change, new titles, new meetings, new artifacts, while the relationships that actually determine whether work flows stay exactly as selfish and competitive as Deming warned they would.

---

Local Optimization Destroys the Whole: The Phase 2 Medical Case and the SAFe Evidence

Local optimization is the pattern where each team, facility, or Agile Release Train maximizes its own throughput while the larger system it belongs to stalls or degrades; exactly what happened at Phase 2 Medical Manufacturing, a $25 million precision device maker whose two facilities duplicated manufacturing, engineering, and management because each optimized itself on its own terms. Five years of genuine lean progress inside each building hid the defect until a customer forced the comparison.

Inside the Phase 2 Medical Redesign

Two Facilities, Duplicated Systems, Local Optima

Phase 2 Medical Manufacturing, a 125-employee precision medical device manufacturer in Rochester, New Hampshire generating roughly $25 million in revenue, ran production 25 miles from a Medtronic Advanced Energy facility in Portsmouth making the same class of disposable surgical devices. Each site had built its own engineering team, its own management layer, and its own process improvements. Phase 2 had spent nearly five years on a genuine lean transformation, small-lot production, elements of visual management, ongoing training in lean tools, an open and respectful culture, real capability, built locally.

None of that local capability was visible as waste from inside either building, because both facilities were, by their own internal measures, well run. Duplicated engineering and duplicated management only become legible as waste once someone compares the two sites as a single system rather than as two separately-managed businesses that happen to make similar products. That comparison is exactly what neither site had reason to make on its own.

The Global-Bid Trigger and the Whole-System Response

Medtronic Advanced Energy put the combined volume made across both sites out for global bidding, forcing Phase 2 Medical and Medtronic to stop treating the two facilities as independent operations and instead redesign around a single system with each site holding one core competency; Portsmouth specializing in new product development while also carrying roughly half the volume, Phase 2 specializing in contract manufacturing at larger scale. Losing the Medtronic Advanced Energy work outright would have been a significant hit to Phase 2’s revenue, which made the redesign a survival decision, not an improvement initiative.

The response was sustained through the Lean Enterprise Institute’s “Golden Triangle” model, with Phase 2 president Adam Prime among those leading the change: “It was time to make some big changes and make sure that they would stick.” The redesign didn’t add a new tool to either facility’s toolkit: it redrew the system boundary so that engineering, management, and production decisions were made once, for the whole, instead of twice, for two locally-optimized halves.

What Local Optimization Looks Like in Software Value Streams

The identical defect shows up in software value streams when every Agile Release Train or component team maximizes its own velocity while work stalls at the handoffs between them, because a locally-optimized team is, by definition, not optimizing the value stream that actually delivers to the customer.

A component team that ships its own backlog on schedule while the feature that depends on three other component teams sits half-integrated for a quarter has hit its own targets and missed the system’s purpose entirely. The failure doesn’t show up in any single team’s dashboard, because every team’s dashboard measures the team, not the Scaled Agile Framework’s the team is a component of. Work-in-process piles up invisibly at integration points, the software equivalent of two facilities quietly duplicating engineering, until a release date or a customer commitment forces the same kind of whole-system comparison Medtronic’s global bid forced on Phase 2 Medical.

Evidence from SAFe Adoptions: Nordea and the ICSE-SEIP Findings

Peer-reviewed research on live SAFe adoptions corroborates the pattern with named cases rather than anecdote. A 2022 action-research study published in the Journal of Software: Evolution and Process, examining Nordea’s Core Banking Platform program, documents organizational constraints and corrective actions taken as the bank scaled agile development inside a policy-heavy financial institution across three research cycles; friction that no single team inside the program had the authority or the visibility to resolve on its own.

A companion study, “Issues in the Adoption of the Scaled Agile Framework,” presented at ICSE-SEIP in 2022, reaches a parallel finding from outside the financial sector: SAFe is subject to criticism for being demanding and expensive in terms of human resources and project management practice, and the issues that emerge during adoption tend to be system-level, coordination cost, governance overhead, cross-team dependency, rather than failures traceable to any one team’s execution. Both studies land on the same structural point Phase 2 Medical demonstrated physically: the defect lives in the relationships between parts, so no amount of tuning any single part resolves it.

---

How to Apply Systems Thinking: Two Levers, Causal Maps, and a System View of the Organization

Leaders who want to apply systems thinking day to day have three usable techniques available: Elisabeth Hendrickson’s two-levers diagnostic, where policy and culture are the only levers leadership actually controls and culture wins when they conflict, and her causal-mapping method for tracing relationship failures instead of blaming components. The third is LeadingAgile’s system view of the organization, built from outcomes, structure, and incentives held together over time. Each converts Principle #2 from an abstraction into a decision leadership can actually make this quarter.

The Two Levers: Policy, Culture, and Why Culture Wins

Elisabeth Hendrickson, speaking on the InfoQ Culture & Methods podcast with Shane Hastie in August 2025, argues that leaders have exactly two levers for changing how an organization behaves: policy and culture; and when the two conflict, culture wins every time.

That claim explains a failure pattern most transformation leads have watched happen without naming it: a new policy ships, a definition-of-done, a WIP limit, a mandated ceremony, and behavior reverts within a sprint or two, because nothing about the incentive systems or the recognition patterns underneath the policy actually changed. The policy lever moved; the culture lever stayed exactly where it was, and culture won. Hendrickson’s corollary is practical rather than aspirational: change culture by consistently feeding what leadership wants to see grow, through incentives and recognition, rather than assuming a written policy will do that work by itself.

Causal Mapping: Repairing Relationships Instead of Blaming Components

Hendrickson’s second technique, causal mapping, starts from her finding that software delivery problems most often stem from relationships between parts of the system rather than from any single part failing outright, so the diagnostic question shifts from which team broke this to which relationship broke.

That shift matters because component-blame and relationship-repair point to different fixes. Blaming a component leads to replacing people, retraining a team, or adding a gate; repairing a relationship leads to changing what passes between two parts and when. Hendrickson connects this directly to why shift-left quality practices have underperformed their promise: organizations claim to do Agile and DevOps but still rely on quality gates and inspection after the fact, which creates the exact bottleneck shift-left was supposed to remove; work backs up at the gate instead of quality getting built in at the relationship between development and verification. Causal mapping, applied honestly, keeps surfacing that the gate itself is often the broken relationship, not either team standing on either side of it.

A System View of the Organization: Outcomes, Structure, Incentives

LeadingAgile’s system view for operationalizing strategy names five interlocking dimensions, business outcomes, org structure, incentive systems, work systems, and collaboration systems, and treats every redesign decision as one that reverberates through all five rather than one that can be changed in isolation.

Business outcomes anchor the other four; without them stated explicitly, even senior leaders can struggle to articulate what the org structure is actually supposed to produce. Incentive systems tend to mirror org structure closely, which is why changing the structure without touching incentives usually reproduces the old behavior inside the new boxes. Collaboration systems carry the heaviest lift of the five, because they exist specifically to overcome the friction the org structure itself introduces; two teams don’t need a collaboration system if the structure already puts them in one team.

A 2022 multiple-case study in the International Journal of Information Systems and Project Management, examining changes to team autonomy in large-scale SAFe adoptions, documents this reverberation directly: as organizations scale agile methods and multiple teams coordinate toward a shared goal, teams give up measurable amounts of decision-making autonomy to make that coordination possible. The trade is not accidental, and pretending it doesn’t happen is what produces the gap between the autonomy a team was promised at kickoff and the autonomy it actually retains once several other teams depend on its output.

---

Systems Thinking Beyond SAFe: Team Topologies, Fracture Planes, and the 2025 Revival

Systems thinking applied to Principle #2 shows up well outside SAFe, in Team Topologies’ socio-technical approach to organization design and in a 2025 mainstream management revival, evidence that the principle is a transferable discipline rather than framework-specific dogma.

Fracture Planes: Finding the System’s Natural Boundaries

Matthew Skelton and Manuel Pais’s Team Topologies reads organization design itself as systems thinking, defining four team types and locating fracture planes, the natural boundaries in a system found by examining cognitive load, dependencies, and domain boundaries, as the mechanism for deciding where one team’s responsibility ends and another’s begins.

Team Type	Primary Focus	Interaction Mode	Fracture-Plane Signal
Stream-aligned	End-to-end value for one stream of work	Collaboration, shifting to X-as-a-Service	Work aligns cleanly to one domain boundary
Platform	Reducing cognitive load for stream-aligned teams	X-as-a-Service	Shared capability with a stable, well-defined interface
Enabling	Closing a specific capability gap	Facilitating	Gap is temporary, not a permanent dependency
Complicated-subsystem	Deep specialist domain knowledge	X-as-a-Service	Cognitive load is too high for a generalist team to own

The table’s right-hand column is the systems-thinking test in miniature: a fracture plane is real when the boundary tracks cognitive load and dependency structure, and false when it tracks an org chart drawn for reasons unrelated to how the work actually interconnects. The 2023-2025 wave of platform-team investment, paired with flow-metric instrumentation, is this same test applied at scale; platform teams exist because the cognitive load of shared infrastructure was found to exceed what stream-aligned teams could absorb without their own delivery suffering.

The HBR 2025 Case: Innovation Without Systems Thinking Backfires

Tima Bansal and Julian Birkinshaw argue in “Why You Need Systems Thinking Now” (Harvard Business Review, September-October 2025) that breakthrough and design-thinking approaches to innovation routinely ignore the secondary ripple effects they produce in interconnected systems; and those ripple effects are exactly what Principle #2 exists to catch before they compound.

Their examples are deliberately outside software: plastics solved a cost and convenience problem while creating a marine and terrestrial ecosystem problem; fracking lowered oil prices while damaging water resources and air quality; credit default swaps were invented to hedge credit risk and ended up helping precipitate the 2008 financial crisis. Each innovation solved the problem it was aimed at and broke something the designers hadn’t included inside their system boundary: the same failure mode Meadows’ definition predicts when the “environment” half of a system claim gets skipped.

A companion piece, “Use Systems Thinking to Innovate More Sustainably,” offers the simplified entry point for readers who find the full framework daunting: identify your North Star, look for patterns, connect the stakeholders the change will touch, and guide the change deliberately rather than letting it propagate unmanaged. It’s a smaller version of the same discipline Deming’s epigraph demands; manage the system, because it will not manage itself.

From Principle to Measurement: Where Flow Makes System Effects Visible

Don Reinertsen’s product development flow gives Principle #2 its economic teeth by naming the two places system effects become measurable: queue length and work-in-process limits, both of which expose the coordination cost that team-level metrics hide by design.

A long queue in front of any handover is a system signal, not a team signal: it means more work is arriving at that point than the system can absorb, regardless of how efficiently any single team upstream or downstream is running. Agile Alliance’s guidance on evolving a company using a systems-thinking approach makes the same point at the organizational scale: change efforts aimed at one part without visibility into queue and flow across the whole tend to relocate the bottleneck rather than remove it. Reinertsen’s contribution is turning that observation into something a leader can put a number on; queue length and WIP are where the abstraction of “the system” becomes a metric someone can actually manage against.

---

Summary

Apply Systems Thinking asks leaders to manage the relationships between parts, not just the parts themselves; and every case in this piece, from a $25 million device manufacturer to a mainstream 2025 management argument, shows the same failure when that management is skipped.

Systems Thinking Is a Management Obligation, Not a Mindset

Deming’s epigraph on the canonical Apply Systems Thinking page isn’t decoration; it’s the operating claim the rest of the principle depends on, and both boundary failures this piece documents are what that claim predicts in practice; Phase 2 Medical’s two facilities and the software value stream’s stalled handoffs are each a system whose components had no reason to cooperate toward a shared aim. The Lineage section’s conclusion carries a consequence for rollout, not just retrospective diagnosis: before adding a new Agile Release Train or scaling to another value stream, apply Meadows’ test as a go/no-go gate rather than an after-the-fact explanation for why it didn’t work.

The management obligation traces directly to Hendrickson’s two-levers finding, and it comes with a next action: audit the last policy that reverted within a sprint or two, and name the specific incentive or recognition pattern it lost to. A leader who ships a new definition-of-done or a mandated WIP limit without also changing what gets rewarded and recognized has pulled one lever and left the stronger one untouched. LeadingAgile’s system view makes the same obligation explicit at the organizational level, and its highest-leverage implication for a reader about to act is this: change structure and incentives in the same decision, because changing one without the other reliably reproduces the old behavior inside new boxes. None of this is optional context around the principle; it is what applying the principle means in practice.

The Boundary You Draw Determines What You Can Fix

Every failure documented here traces back to a system boundary drawn too narrowly. Phase 2 Medical’s redraw did more than merge two facilities on paper: it moved engineering and production decisions to a single accountable owner across both sites, replacing two site-level owners who’d never had to reconcile a conflicting call. The generalizable version of that failure is a diagnostic question every reader can run against their own org: which handoff between your component teams or Agile Release Trains does no single team’s dashboard measure? The Nordea and ICSE-SEIP research findings established this isn’t a one-company anomaly: system-level friction in SAFe adoptions consistently traces to relationships no single team had the mandate to fix.

Fracture planes and Reinertsen’s queue-length and WIP metrics are this piece’s two measurement tools, and the place to start, for a leader applying Principle #2 to their own organization, is queue length at the busiest handover: it’s the cheapest signal to collect and the fastest way to test whether a boundary is real or just an artifact of how the org chart was drawn. A leader who can answer that question for their own organization has applied Principle #2. A leader who can only recite its definition has memorized a poster; and Bansal and Birkinshaw’s 2025 argument suggests the cost of that gap is rising, not falling, as the systems organizations operate inside grow more interconnected, not less.