This way of thinking is useful. In many situations, it is necessary.

But it is also incomplete.

Some problems cannot be understood only by taking them apart. Their behavior comes from relationships, feedback, timing, incentives, assumptions, and interactions. The issue is not always in the parts themselves. Sometimes the issue is in the pattern the parts are creating together.

That is where systems thinking begins.

Systems thinking is the ability to move from parts to patterns. It is a way of seeing how things connect, influence one another, and produce outcomes over time. It does not reject analytical thinking. Instead, it gives analysis a wider frame.

Before we break something down, systems thinking asks: what whole are we looking at?

Share

From disconnection to interconnectedness

The first movement of a systems thinker is from disconnection to interconnectedness.

At first glance, many things appear separate. One decision. One delay. One mistake. One behavior. One result. We often treat these as isolated events, each with its own cause and owner.

But systems thinkers pause before assuming separation.

They ask what is connected to what. They look for influence, dependency, sequence, and consequence. They notice that a visible problem in one place may have been created by pressure somewhere else.

A recurring issue may not be a standalone failure. It may be a signal. It may be pointing to a relationship, a constraint, or a pattern that has not yet been seen.

The systems thinker asks:

• What else does this affect?

• What affected this before it appeared?

• Which connections are visible?

• Which connections are hidden?

• Where might a small change travel farther than expected?

Interconnectedness changes the nature of problem-solving. Instead of rushing to fix the visible part, we begin by understanding the web around it.

From linear to circular

The second movement is from linear to circular.

Linear thinking is attractive because it feels clean. A causes B. Input creates output. Action produces result. Problem leads to solution.

Sometimes this is enough. But many systems do not behave in straight lines. They behave through loops.

Share

An action creates a reaction. That reaction changes the conditions. The changed conditions influence the next action. Over time, the loop may strengthen, weaken, accelerate, or stabilize the pattern.

This is why a solution may work once and fail later. The system has changed in response to the solution.

Circular thinking helps us notice feedback.

Some feedback reinforces a pattern. The more something happens, the more it continues to happen. Trust builds trust. Mistrust builds mistrust. Delay creates pressure, and pressure can create more delay.

Other feedback balances a pattern. The system pushes back. Growth slows. Behavior adjusts. Resources become constrained. A correction appears.

Share

The systems thinker asks:

• What feedback loop is operating here?

• Is this pattern reinforcing itself?

• Is something pushing the system back toward balance?

• What happens after the solution is introduced?

• How does the result become a new cause?

Circular thinking teaches humility. It reminds us that action does not end when we act. The system responds.

From silos to emergence

The third movement is from silos to emergence.

Silos make the world easier to manage. They divide responsibility. They create focus. They allow people to specialize. Without some boundaries, everything becomes too broad to handle.

But silos can also hide the most important thing: what happens between the parts.

Emergence is what appears when parts interact. It is the behavior of the whole that cannot be fully explained by looking at each piece separately.

A group may have capable individuals and still produce confusion. A process may have well-defined steps and still create delays. A plan may look reasonable in sections and still fail when the sections meet.

Share

The problem is not always inside one silo. It may be in the interaction among silos.

Emergence asks us to look at the spaces between things: the handoffs, assumptions, incentives, timing, informal habits, and unspoken rules. These spaces often shape outcomes more than the formal structure does.

The systems thinker asks:

• What is happening between the parts?

• What outcome is emerging from these interactions?

• Are local successes creating wider problems?

• Are people optimizing their own area at the expense of the whole?

• What behavior is no single person controlling, but everyone is helping create?

Emergence is difficult because it challenges blame. It suggests that outcomes may arise not from one broken part, but from the structure of interaction itself.

From parts to wholes

The fourth movement is from parts to wholes.

Analysis often begins by breaking things down. This is useful. We need detail. We need distinctions. We need to understand components.

But a system is not just a collection of parts. It is a whole formed by relationships among parts.

A puzzle piece has meaning because of the picture it belongs to. On its own, it may be interesting. In context, it becomes intelligible.

The same is true in systems. A part cannot be fully understood apart from the whole that gives it function, role, and meaning.

When we focus only on parts, we may improve something locally while weakening the larger system. We may optimize one measure and distort the broader purpose. We may solve a narrow problem while creating a wider one.

Share

Seeing wholes means asking what the system is for.

The systems thinker asks:

• What whole does this part belong to?

• What role does this part play in the larger pattern?

• Are we improving a part while weakening the whole?

• What purpose is the system actually serving?

• Does the whole behave differently than the parts suggest?

The movement from parts to wholes does not reject detail. It places detail in context.

From analysis to synthesis

The fifth movement is from analysis to synthesis.

Analysis separates. Synthesis integrates.

Analysis asks: what are the components?

Synthesis asks: how do they fit together?

Analysis gives clarity. Synthesis gives meaning.

Both are necessary. But many of us are trained more deeply in analysis than synthesis. We become skilled at breaking down problems, identifying variables, and naming categories. Yet when the pieces multiply, we may struggle to put them back together.

Share

This is where an important distinction matters.

Systems thinking should often come before analytical thinking in complex situations. Not because analysis is wrong, but because analysis needs direction. Before we break a problem into pieces, we need some sense of the whole. We need to understand the boundary of the system, the relationships that matter, and the pattern we are trying to explain.

Without a systems frame, analysis can become fragmentation. We may analyze the wrong parts. We may measure what is easy to isolate instead of what actually matters. We may produce detailed explanations that do not improve understanding of the whole.

Systems thinking frames the inquiry. Analysis investigates the parts. Synthesis brings the learning back together.

The systems thinker asks:

• What whole are we examining before we break it apart?

• What have we learned from examining the parts?

• What pattern appears when these parts are brought together?

• Which relationships matter most?

• What meaning emerges from the details?

Synthesis is not summary. It is not simply listing what has been found. It is the act of forming a coherent understanding from complexity.

From isolation to relationships

The sixth movement is from isolation to relationships.

Isolation treats things as independent. Relationships reveal influence.

A person, process, decision, or event may look one way in isolation and another way inside a network of relationships. Behavior that seems irrational alone may make sense when we see the pressures around it. A recurring problem may persist not because people fail to notice it, but because relationships in the system keep reproducing it.

Share

Systems thinkers pay close attention to relationships because relationships carry energy, information, constraint, and possibility.

The quality of relationships often determines the behavior of the system. Strong relationships can create trust, learning, adaptation, and resilience. Weak or distorted relationships can create confusion, delay, defensiveness, and fragmentation.

This applies not only to relationships between people. It also applies to relationships between ideas, incentives, processes, rules, resources, and outcomes.

The systems thinker asks:

• What relationships shape this behavior?

• Where does information flow or get blocked?

• Which relationships reinforce the current pattern?

• Which relationships could change the system if strengthened?

• What is being held in place by the current structure of relationships?

To see relationships is to see the living structure of a system.

The missing tool: choosing the right boundary

There is one more tool that sits beneath all the others: the ability to choose the right boundary.

Every system has a boundary, but boundaries are not always obvious. If the boundary is too narrow, we miss important relationships. If the boundary is too wide, the problem becomes impossible to work with.

Share

A systems thinker knows that the way we draw the boundary shapes what we can see.

Draw the boundary around one task, and the problem may look like execution.

Draw it around a process, and it may look like coordination.

Draw it around incentives, and it may look like behavior.

Draw it around time, and it may look like a feedback loop.

The boundary determines the story.

This is why systems thinking requires judgment. It is not simply about seeing everything. No one can see everything. It is about seeing enough of the relevant whole to understand the pattern.

The systems thinker asks:

• Where have we drawn the boundary?

• What falls inside it?

• What falls outside it?

• What changes if we expand the boundary?

• Are we excluding something that explains the behavior?

Good boundaries do not make complexity disappear. They make it possible to work with.

The discipline of seeing patterns

Systems thinking is often presented as a set of tools: diagrams, maps, loops, models, and frameworks.

These tools matter. They help make invisible patterns visible.

But before systems thinking becomes a diagram, it is a discipline of attention.

It is the habit of asking better questions.

Not just: what happened?

But: what pattern is this part of?

Not just: who is responsible?

But: what relationships shaped this behavior?

Not just: what is the fix?

But: how might the system respond?

Not just: what are the parts?

But: what whole are they creating?

Not just: what do we know?

But: how does it fit together?

Share

The systems thinker does not ignore parts, plans, categories, or analysis. They use them. But they do not stop there.

They move from disconnection to interconnectedness.

From linear to circular.

From silos to emergence.

From parts to wholes.

From analysis to synthesis.

From isolation to relationships.

And beneath all of these movements, they keep asking where the boundary should be drawn.

That is the real toolset of a systems thinker. Not a box of techniques, but a way of seeing. The goal is not to make the world simple. The goal is to understand complexity well enough to act with wisdom.

Nicole

Subscribe now

Share

Leave a comment

Share

They largely do not. And the paper’s four propositions explain why.

Proposition 1: Learning does not arise from routine operations.

Organizations tend to assume that experience accumulates automatically. It does not. Learning requires deliberate design: structured after-action reviews, accessible knowledge repositories, intentional handoff protocols. Without that infrastructure, institutional experience evaporates at the end of every project. The next team starts from near-zero.

Proposition 2: Learning is unevenly distributed inside organizations.

An organization can improve its execution mechanics, how it runs procurement, tracks milestones, manages vendors and still keep failing at the strategic level. Lower-level learning and higher-level outcomes operate in different loops. Getting better at the wrong things is still getting worse at what matters.

Share

Proposition 3: Distance degrades transfer.

As cultural, administrative, geographic, and economic distance increases between a reference project and a new one, performance deteriorates and variability grows. What worked in Tokyo does not transfer cleanly to Paris. What worked in Paris does not transfer cleanly to Los Angeles. Context is not a footnote. It is a load-bearing variable.

Proposition 4: Time gaps kill institutional memory.

Projects with long intervals between iterations perform worse than frequent ones. The mechanisms are straightforward: records get lost, team composition changes, and tacit knowledge walks out the door with the people who held it. Frequency is a prerequisite for learning to compound. The Olympics come every four years. That is enough time for an organization to forget almost everything.

The through-line across all four propositions is the same: learning is not a byproduct of doing. It is a system. And most project organizations do not have that system. They have history. History and learning are not the same thing.

Share

This matters beyond the Olympics. IT modernization programs, large infrastructure initiatives, enterprise platform migrations — they share the same structural conditions. Long gaps between major investments. High staff turnover. Cross-agency and cross-contextual distance. Almost no formalized knowledge transfer infrastructure. Flyvbjerg’s propositions are not abstractions for those programs. They are a diagnostic.

The question worth sitting with: in your organization, what is the actual mechanism by which one project’s hard-won knowledge reaches the next project’s team?

If the answer is “people remember” or “it’s in the documentation somewhere,” you already know what Flyvbjerg would say.

Nicole

https://www.tandfonline.com/doi/pdf/10.1080/14719037.2026.2650426

Subscribe now

Share

Leave a comment

That is one kind of world. The practitioners who read this publication tend to work in another kind entirely.

Share

PM Researcher exists to meet them there.

I. Complexity is the ground condition, not the exception.

Large-scale programs operate inside adaptive, nonlinear systems. Stakeholder interests shift mid-execution. Environments evolve faster than plans do. Decisions made years ago shape options available today in ways that no risk register anticipated.

None of this is aberrational. All of it is structural. The question is whether your mental models are adequate to the environment you are actually navigating, and whether you have the frameworks to tell the difference.

Frameworks like Cynefin, Ashby’s Law, and complex adaptive systems theory are not academic ornaments. They are diagnostic instruments. They tell you what kind of problem you are actually holding before you decide how to hold it.

Share

This publication takes that seriously. Not as an intellectual posture, but as a professional commitment. A program manager who can distinguish a complicated problem from a complex one brings a fundamentally different quality of judgment to the work.

II. Governance is a design problem.

Program outcomes are shaped as much by governance architecture as by execution quality. Organizations that build governance structures adequate to the complexity they manage create the conditions for programs to succeed. That is a design choice, and it can be made deliberately.

Ashby’s Law is precise on this point. Requisite variety is not a suggestion. An organization whose internal structures match the complexity of its environment can govern that environment. One that builds for simplicity will find itself governed by complexity instead.

This is diagnosable. It is correctable. Program managers who treat governance architecture as a design discipline, rather than a compliance exercise, are the ones positioned to make it so.

Share

III. Digital systems are infrastructure. Govern them accordingly.

The platforms and systems that organizations build to deliver on their missions are not back-office projects. They are the operational substrate through which strategy becomes reality. How they are designed, governed, and sustained determines what is actually possible.

Treating digital systems as infrastructure means bringing long-horizon thinking, architectural stewardship, and genuine accountability to how they are built and maintained. It means understanding that platform decisions made today will shape organizational capacity for a decade.

PM Researcher takes that framing seriously because the quality of governance applied to these systems is a measure of institutional seriousness about the mission they serve.

IV. Theory earns its place by illuminating something real.

This publication leads with problems, not frameworks. A concept is introduced when it explains something that practice alone cannot. The sequence matters: problem first, framework second, always in service of the practitioner who has to make a decision in a real context with real consequences.

Rigor and accessibility are not in tension. Dense ideas, stated plainly, reach people. When practitioners share something peer to peer, without an algorithm prompting them, it is because the idea was true and the writing did not get in its way.

Share

Systems thinking is not a supplement to analytical thinking. It is a prior condition. You have to understand what kind of system you are in before you can know which analytical tools apply.

That conviction runs through everything published here. Not because systems thinking is fashionable, but because understanding the nature of a system before choosing your tools is simply better practice.

V. What this publication is for.

PM Researcher is written for practitioners who are serious about the work: program and project managers, governance leads, policy-adjacent technologists, strategists, problem solvers, leaders, and thinkers who believe that better conceptual tools lead to better institutional outcomes.

It is an ongoing argument, made in public, that complexity science and systems thinking belong in the working vocabulary. That the stakes of large-scale programs warrant that level of intellectual investment. And that rigorous thinking, clearly expressed, is one of the most useful things a publication can offer.

Every issue is an attempt to narrow the gap between the mental models practitioners carry and the systems they are responsible for, by one concept, one case, one framework at a time.

That is the work. It continues.

PM Researcher publishes at the intersection of complexity science, systems thinking, program governance, and digital infrastructure.

Share

Leave a comment

The strategy is clear enough in the deck. The initiative has an owner. The meeting notes say everyone is aligned. The roadmap looks reasonable. The next steps are written down. The work begins. Then the system starts to reveal itself.

A decision that was “already made” gets reopened. A team discovers a dependency no one had fully owned. A stakeholder who agreed in principle objects when the work becomes concrete. A handoff that looked straightforward turns out to require interpretation, negotiation, and another meeting. Someone asks, “Wait, who is actually deciding this?” Someone else says, “I thought we agreed on that last month.”

Nothing is obviously broken. Everyone is busy. Everyone is competent. The meetings are happening. The documents exist. The problem is harder to name.

The organization is paying coordination debt.

Coordination debt is the future cost created when teams avoid clarifying ownership, decisions, dependencies, assumptions, and escalation paths in the present.

It is the unpaid work behind the work.

Technical debt slows down software. Coordination debt slows down organizations.

The problem is not always communication

When work gets stuck, organizations often reach for the easiest diagnosis: communication problem.

People say:

- “We need better communication.”

- “We need more alignment.”

- “We need to get everyone on the same page.”

- “We need clearer updates.”

- “We need another sync.”

Sometimes that is true. But often, the problem is not that people failed to communicate. The problem is that communication is being asked to compensate for missing structure.

More meetings cannot fix unclear decision rights. Better updates cannot fix hidden dependencies. Longer documents cannot fix conflicting incentives. Friendlier collaboration cannot fix work that has no real owner. A new dashboard cannot fix a system that does not know which trade-offs matter.

Communication is not the same as coordination.

Communication moves information. Coordination moves work through a system of people, decisions, constraints, dependencies, and consequences.

An organization can communicate constantly and still coordinate poorly.

That is why coordination debt is so expensive. It hides inside normal work. It looks like meetings, follow-ups, clarifications, status updates, stakeholder management, escalation, and “just checking in.” It rarely appears as a single failure. It appears as organizational drag.

The symptoms are familiar

Coordination debt shows up in patterns like these:

- Decisions are made verbally but not recorded.

- The same topic returns every few weeks with no memory of the previous trade-off.

- Teams agree at a high level but disagree when implementation begins.

- Ownership is distributed so widely that accountability disappears.

- Dependencies are known socially but not managed structurally.

- Escalation happens only after delay becomes visible.

- People attend meetings as insurance because absence creates risk.

- The organization relies on a few “glue people” who remember everything.

- New contributors need oral history to understand why things are the way they are.

- Work is blocked not by lack of effort but by lack of clarity.

The dangerous part is that coordination debt can coexist with high activity.

A team can be responsive, hardworking, well-intentioned, and still trapped in a system where work requires too much interpretation to move. The busier the organization gets, the more expensive the debt becomes.

This is why smart organizations keep re-deciding the same things. They are not stupid. They are operating without enough institutional memory, decision clarity, dependency design, and ownership discipline.

The work keeps returning because the system never fully absorbed the decision.

The five types of coordination debt

Read more

A 2018 review article by San Cristóbal, Carral, Diaz, Fraguela, and Iglesias, “Complexity and Project Management: A General Overview,” published in Wiley/Hindawi, offers a clean starting point. Not a long read. It is not a radical paper. It is a literature synthesis. But embedded in it is a diagram that does something useful: it separates the two root causes of project complexity, traces what each one produces, and then shows what happens when they converge.

That convergence is where most complex programs actually live. And it is where the standard PM toolkit stops working.

The Diagram Worth Sitting With

The authors propose that project complexity has two distinct sources: structural complexity and uncertainty.

Structural complexity is what most people mean when they say a project is complicated. It has two components: the sheer size and number of elements involved, and the interdependence of those elements. A large interagency IT modernization is structurally complex. Many systems. Many stakeholders. Many handoffs. The parts are individually understandable; the coordination is not.

Share

Here is the insight the diagram makes explicit: structural complexity, on its own, produces something that goes beyond coordination difficulty. When many interdependent elements interact in complex ways, the behavior of the whole cannot be predicted by analyzing the parts. The total is more than the sum of its parts. This is emergence, and you cannot manage emergent behavior with a Gantt chart.

Uncertainty is the second source, and it has its own two components: uncertainty in goals and uncertainty in methods. These are the “what” and “how” of ambiguity. Sometimes we do not fully know what we are building. Sometimes we know what we want but not how to get there. Often both are true.

The diagram then shows these two streams converging into a single final condition: structural complexity compounded by uncertainty. The arrow moves downward. The implication is directional. This is not merely the sum of two hard things. It is a qualitatively different environment that requires a qualitatively different response.

This Is Cynefin’s Complicated/Complex Distinction, Grounded

If you have read the piece in this series on the Cynefin framework, this diagram will look familiar. The authors are drawing the same boundary that Cynefin draws between its Complicated and Complex domains, from a project management literature base rather than a complexity science base.

Structural complexity without significant uncertainty maps to Cynefin’s “Complicated” domain. The system has many parts and requires expert analysis, but the parts are knowable, the relationships are traceable, and good analysis produces reliable answers. This is where traditional PM methods, including work breakdown structures, earned value, and dependency mapping, are appropriate. The domain rewards rigor.

Share

When uncertainty in goals or methods enters the picture, you have crossed into Cynefin’s “Complex” domain. In Complex, cause and effect are only visible in retrospect. Goals are not fully specifiable in advance because they are partly discovered through the work itself. Methods cannot be selected upfront because the environment responds to interventions in ways that shift the landscape. This is where analysis, however sophisticated, reaches its limits.

The San Cristóbal diagram makes this concrete. The compounded condition is not just harder. It is different in kind. You cannot analyze your way to stable outcomes in an environment where the outcomes themselves are still emerging.

This is also why I have argued, in the earlier piece on systems thinking versus analysis, that the two are not interchangeable tools on the same continuum. Analysis is the right instrument for Complicated territory. Systems thinking, which means holding patterns, relationships, feedback loops, and emergence in view simultaneously, is the instrument for Complex territory. The diagram gives you the map. Cynefin gives you the orientation. Systems thinking gives you the practice.

The DPI Case

Almost every shared digital infrastructure program operates in the compounded condition the diagram describes. Consider any multi-agency platform that has to serve heterogeneous stakeholder communities, absorb legacy systems from predecessor programs, navigate funding uncertainty, and remain coherent across administrations that may have fundamentally different priorities.

Goals in these programs are uncertain, not because program managers are unclear, but because the institutional environment is plural. Multiple agencies. Multiple oversight bodies. Multiple definitions of success that are not always reconcilable. What counts as done is negotiated, not specified.

Share

Methods are uncertain for a parallel reason. Emerging technology, interagency coordination dynamics, regulatory constraints, and workforce capacity all shift during execution. The path forward is discovered through engagement with the system, not selected from a menu of known options.

And structural complexity is inherent. The interdependencies are not a design flaw. They are the point. Shared infrastructure exists precisely because no single agency can or should build and maintain it alone. The value is in the shared structure. But shared structure is complex structure, by definition.

This is what I mean by DPI Stewardship as a distinct governance challenge. It is not program management at scale. It is program management in the compounded condition, sustained over time, across political cycles, without the stability conditions that traditional PM methods assume.

What the Paper Gets Right (and Where It Stops)

The San Cristóbal review is careful and thorough within its scope. It synthesizes decades of PM complexity literature, traces the intellectual lineage back to Morris, Bennet, Gidado, and others, and lands on a direct observation: the application of traditional tools and techniques developed for simple projects has been found to be inappropriate for complex projects.

Share

That sentence carries weight. It is an acknowledgment, in the academic PM literature, that the tool mismatch is not a practitioner failure. It is a category error. The tools are not wrong. They are wrong for this domain.

Where the paper stops short is in prescription. It identifies the problem clearly. It does not go far in telling you what governance models are appropriate for the compounded condition. That is where the complexity science literature takes over: Snowden on Cynefin, Meadows on systems thinking, Ashby on requisite variety.

That is also the argument of this entire canon series. The PM literature knows something is wrong with the standard approach in complex environments. The complexity science literature explains why, and shows what else is possible. The gap between the two bodies of knowledge is where practitioners actually work.

Closing that gap is the project.

Share

Where This Fits in the Canon

This article is part of the Complexity Canon series, which reads foundational complexity science concepts against the practice of project and program management.

- Ashby’s Law and Requisite Variety – Why governance capacity must match the variety of the environment it governs.

- The Cynefin Framework – How to orient in uncertain terrain before choosing a management approach.

- Systems Thinking vs. Analysis – Why these are not interchangeable, and when each one is the right instrument.

- Emergence Science – How complex systems produce behavior that no component produces alone.

Each piece in the series can stand alone. Together, they are building a case: that governing complex programs, especially shared digital infrastructure, requires fluency in complexity science, not just mastery of PM methodology.

Nicole

San Cristóbal, J. R., Carral, L., Diaz, E., Fraguela, J. A., & Iglesias, G. (2018). Complexity and Project Management: A General Overview. Wiley/Hindawi. https://doi.org/10.1155/2018/4891286

Subscribe now

Share

Leave a comment

Complexity science tells you how complex systems behave. It does not tell you how to act wisely inside one, under pressure, with incomplete information, in the presence of people whose cooperation you need and whose behavior you cannot control.

That gap between knowing the framework and knowing what to do is where governance actually lives. And it is where this canon has been pointing all along.

What frameworks cannot do

Frameworks are maps. They describe the territory with more or less fidelity. They give you a language for what you are seeing and a structure for organizing your response.
But maps are not territory. And the practitioner who mistakes the map for the territory, who believes that naming the domain resolves the uncertainty, that identifying the feedback loop eliminates its risk, that running the diagnostic closes the variety gap has learned the framework without developing the judgment it requires.

This is not a criticism of frameworks. It is a description of their proper role. A framework makes judgment more precise. It does not replace it.

The question this article addresses is: what does judgment look like in complex governance environments and how do you develop it?

Three capacities the wise governor cultivates

The first is tolerance for ambiguity.
Complex systems produce ambiguous signals. The feedback is real but interpretable in multiple ways. The domain boundaries are permeable and shifting. The cause-and-effect relationships are only visible in retrospect which means that in the moment of decision, you are always acting on incomplete information.

Most governance instincts run in the opposite direction. The pressure to resolve ambiguity, to make the situation legible, to name the problem precisely, to commit to a plan is enormous. It comes from stakeholders, from reporting requirements, from the organizational cultures that reward confident decisions and punish visible uncertainty.

Share

The wise governor resists that pressure without becoming paralyzed by it. They hold ambiguity as information as a signal that the situation requires a different kind of knowing than the one the governance model was built for. They act, because inaction is also a choice with consequences. But they act with what complexity science calls requisite uncertainty – a confidence calibrated to what the system actually allows you to know.

The second is pattern recognition across time.
Complexity science describes feedback loops, emergence, and non-linearity in structural terms. Developing the capacity to see these dynamics in real programs in real time, before the outcomes materialize is a different skill entirely. It is built through experience, reflection, and the deliberate practice of reading programs as systems rather than as collections of tasks and milestones.
The practitioner who has seen a reinforcing loop lock in who has watched early delays compound into program collapse through the precise mechanism complexity science describes recognizes the early signals differently the next time. Not because the framework told them what to look for, but because the framework gave them a language for what experience had already shown them.

This is why the complexity canon matters most to practitioners with depth. The frameworks do not substitute for experience. They make experience more transferable more legible across contexts, more precise in its lessons, more useful in the moment of decision.

Share

The third is the governance of self.
This capacity is the least discussed and the most consequential. Complex systems respond to the behavior of their governors. The program manager who escalates in panic changes the system differently than the one who escalates with clarity. The leader who receives bad news as a threat changes the feedback architecture of their program because people adapt. They learn what the governance system rewards and punishes. They route their signals accordingly.
This means that the quality of governance in a complex environment is inseparable from the quality of the governor. Not their technical competence though that matters. Their capacity to remain steady when the system is turbulent. Their willingness to receive honest signals without punishing the messenger. Their ability to distinguish between the urgency the situation demands and the anxiety the situation produces.
These are not soft skills. They are structural determinants of whether the feedback loops in your program run toward honest signal or toward managed impression.

The Healthcare.gov case is a governance failure. It is also a leadership failure specifically, the failure to create conditions where honest feedback could survive the political environment.
The wise governor knows that their own behavior is a governance intervention. Every time.

On the relationship between theory and practice
There is a version of complexity literacy that stays at the level of vocabulary. The practitioner who can name the domains, describe the feedback types, and identify the failure modes but who has not integrated those concepts into the moment-to-moment practice of governance has acquired knowledge without developing capacity.

Share

The integration happens through deliberate application. Not just reading about Cynefin but stopping in the middle of a difficult program situation and asking: which domain am I actually in right now? Not just understanding feedback loops – but mapping the actual loops running in your current program and asking which ones are accelerating in a direction you have not addressed. Not just knowing that governance systems lose requisite variety but running your own diagnostic and sitting with what it tells you.
This canon has given you the maps. The territory is your own work.

What the complexity lens ultimately demands
Complexity science is not a pessimistic framework. It does not say that complex systems cannot be governed only that they cannot be controlled. The distinction is significant.
Control assumes that the governor’s intention determines the system’s outcome. Governance assumes something more modest and more honest: that the governor’s choices shape the conditions within which outcomes emerge. You cannot design emergence. You can create better and worse conditions for it.

That reorientation from control to governance, from designing outcomes to shaping conditions is the deepest shift the complexity lens demands. It requires a different relationship with uncertainty. A different definition of success. And a different kind of confidence, one grounded not in the certainty that the plan will hold, but in the capacity to respond when it does not.
That capacity is what this canon has been building toward. Not a set of tools to apply though the tools are real and useful. A way of seeing that makes the work of governance more honest, more precise, and more wise.

A note on what comes next
This article closes the first arc of the complexity canon. It moves from complexity as a lens for understanding governance to complexity as a lens for understanding the governance of digital systems specifically the infrastructure, the data architectures, the AI-enabled services, and the public institutions that depend on them.

Nicole

Subscribe now

Share

Leave a comment

The number lands in the status deck. Someone highlights it yellow. The project manager explains that the team hit some resource constraints last month but expects to recover. The sponsor nods. The meeting moves on. The number is noted. Nothing changes.

This is how Earned Value Management dies; not in the formula, but in the meeting room.

Schedule Variance, as most programs use it, is a performance score. It tells you how many budget-dollars’ worth of scheduled work did not get done. Negative SV: you are behind. Positive SV: you are ahead. The score gets recorded, discussed, and filed. What it almost never does is trigger a correction. That absence is not a governance failure in the ordinary sense. It is a systems failure, a control mechanism receiving a signal and producing no response.

Share

EVM was not designed as a scorecard. The Earned Value Management System standards that emerged from the U.S. Department of Defense in the 1960s and were formalized through decades of defense acquisition policy were designed to give program managers early, quantified visibility into cost and schedule deviation early enough to act. The “E” in EVM is the operative concept: the earned value is a proxy for work actually accomplished, which lets you compare plan to reality before the end date arrives and makes the divergence undeniable. The original design intent was detection followed by response. The gap between that intent and contemporary practice where detection is treated as the endpoint is where most programs forfeit the tool’s actual value.

To understand what SV is actually measuring, it helps to think in Donella Meadows’ terms. In Thinking in Systems, Meadows identifies the strength of negative feedback loops as one of the highest-leverage intervention points in any system. A negative feedback loop is a self-correcting mechanism: it senses deviation from a goal and applies corrective force proportional to the gap. Thermostats, immune systems, and well-run programs all operate on this principle. Schedule Variance is precisely the measurement that tells you whether your program’s corrective loop is activating. It is the gap signal. It is the thermometer reading that should trigger the furnace.

Share

When SV deteriorates week over week, the natural interpretation is that the project is falling further behind. That is true but incomplete. The more important interpretation is structural: the system’s corrective mechanisms are not functioning. Either the loop is absent, no one is accountable for responding to the variance, or it is too slow, because the cadence of review and response is longer than the cadence of deviation accumulation, or it is being actively suppressed. The program has a sensing mechanism. It lacks response capacity.

This is the distinction that separates a lagging indicator from a feedback signal, and it matters more than it sounds. A lagging indicator confirms what happened. It is retrospective by definition. A feedback signal tells you about current system behavior and, more importantly, about the system’s trajectory. Schedule Variance used as a lagging indicator is status reporting is useful, even necessary, but fundamentally backward-looking. Schedule Variance used as a feedback signal is governance intelligence. The shift is not in the metric. The formula does not change. What changes is the question you are asking of it: not “how far are we behind?” but “is the system correcting?”

The most useful analytical frame for SV is trend, not level. A single reading in a single period tells you almost nothing about system behavior. An SV of negative two hundred thousand dollars could mean a one-time disruption fully absorbed by a functioning recovery mechanism, or it could be the fifth consecutive decline in a system that has lost its corrective capacity entirely. You cannot tell from a single number. You can tell from three to five consecutive periods. A negative SV that is improving — becoming less negative over time — means the corrective loop is active and the system is recovering. A negative SV that is stable means the system has reached an equilibrium, but the equilibrium is dysfunctional: deviation has been normalized rather than corrected. A negative SV that is worsening means the feedback loop is broken, too slow, or suppressed. That is the condition that should escalate. That is the condition that typically does not.

Share

Which brings us to the organizational suppression problem, and it is worth being direct about it. Most programs with deteriorating Schedule Variance do not lack corrective capacity in an engineering sense. The work could be resequenced. Resources could be reallocated. Scope could be renegotiated. The corrective options exist. What is absent is corrective permission. The project manager hesitates to raise the trend because raising it surfaces a failure narrative. The sponsor does not want to hear it because the conversation that follows is expensive. The PMO records the number because recording the number satisfies the compliance requirement and does not require anyone to make a difficult decision. Meadows frames this precisely: it is an information flows problem. The signal exists. The pathway from signal to corrective action is blocked — not by technical failure but by organizational dynamics that treat an uncomfortable number as a problem to be managed rather than a mechanism to be activated.

This is not a criticism of any individual project manager. It is a description of a structural condition that is nearly universal in programs governed by status-reporting cultures. The variance is measured. The variance is reported. The variance continues to deteriorate. The end-of-project retrospective attributes the outcome to factors that were visible in the SV trend six months before the deadline.

EVM was designed as a control system. A control system that receives a feedback signal and takes no corrective action is not a control system. It is a measurement system wearing a control system’s name badge.

The question worth sitting with is not whether your program measures Schedule Variance. The question is whether your program is designed to respond to it — whether the information pathway from variance detection to corrective decision is open, fast enough, and carries enough organizational authority to actually change behavior.

Most programs are not. The next post in this series examines lighter-weight metrics such as burn-up/burn-down, throughput, cycle time, milestone confidence, OKRs, benefits realization, and risk-adjusted roadmaps.

Nicole

Subscribe now

Share

Leave a comment

The Domain Shift Problem: Hurricane Katrina

In the days before Katrina made landfall, the governance environment was Complex. Levee integrity was uncertain. Storm surge projections carried wide variance. Evacuation compliance was uneven and unpredictable. The interactions between these variables were not calculable in advance. The appropriate posture was probe-sense-respond: position resources, monitor emerging conditions, and adapt as the picture clarified.

That was not the posture FEMA and DHS held.

Both agencies were organized for Complicated problems – situations where expert analysis, established protocol, and coordinated execution could produce reliable outcomes. That organizational logic is not wrong in the domains where it applies. It was catastrophically wrong here.

When Katrina made landfall and the levees failed, the domain shifted. The situation moved from Complex to Chaotic. Cause and effect became locally severed. Information was fragmentary, contradictory, and arriving faster than any coordination protocol could process it. The appropriate response in Chaotic conditions is act-sense-respond: impose any stabilizing action, observe what it produces, and adjust. Speed of action matters more than completeness of information.

The governance system did not shift with the domain. Requests moved up chains of command designed for legible conditions. Coordination waited on information that the situation could not supply. Resources staged in positions calibrated to a different threat profile than the one that materialized.

The forensic finding is not that FEMA was slow. It is that FEMA was operating in the wrong domain while the situation was happening in another one entirely. The gap between the governance model and the actual system was not a resource gap. It was a structural misread.

Share

Ashby makes this precise: the variety of the response system must match the variety of the situation it is managing. When the levees failed and the city flooded, the variety of the situation expanded catastrophically and instantaneously. The regulatory variety on the other side of that event did not expand with it. That asymmetry is what produced the governance collapse, not individual failure, not political neglect alone, but a variety deficit that the institutional architecture had no mechanism to close.

The False Confidence Problem: The 2008 Financial Crisis

Katrina is a failure of speed. 2008 is a failure of visibility, and it is the more dangerous kind.

By the mid-2000s, financial regulators believed they were governing a Complicated system. Complex instruments, yes, but modeled, rated, stress-tested, and supervised by credentialed professionals using sophisticated frameworks. The confidence itself was part of the architecture. Risk was not unknown; it was measured, distributed, and priced. That was the official account of the system.

The system was not Complicated. It had been drifting into Complex territory for years.

As mortgage-backed securities compounded into collateralized debt obligations, as credit default swaps created webs of counterparty obligation that crossed institutional and national boundaries, as ratings agencies applied Complicated-domain models to instruments whose behavior was fundamentally emergent, the aggregate system developed properties that no individual actor’s model could see. The interdependencies were not linear. The failure modes were not decomposable. The system had become more complex than the governance model designed to oversee it.

Share

This is where CAS logic becomes forensic. Each agent in the system was behaving locally and rationally. Mortgage originators were responding to demand and incentive structures. Ratings analysts were applying established methodologies to the instruments in front of them. Traders were optimizing within the rules they operated under. No single actor was the failure. The failure was emergent: produced by the interaction of locally rational behaviors within a system whose aggregate dynamics no one’s regulatory variety was calibrated to see.

The Cynefin misread here is distinct from Katrina’s. In Katrina, the domain shifted and governance didn’t move. In 2008, the domain had already shifted and governance didn’t know. The regulators were not watching a Complex system and choosing Complicated-domain tools anyway. They genuinely believed the models were adequate. That epistemic confidence is structurally more dangerous because it forecloses the adaptive response before the problem is visible enough to trigger one.

By the time the variety gap became legible, it was 2008.

Share

What Both Cases Reveal

The surface reading of these failures runs toward individual culpability and political failure. Both are present. Neither is the structural explanation.

The structural explanation, read through the full canon, is this: in both cases, the governance system was designed to see and respond to complicated problems with decomposable parts and knowable solutions. In both cases, the actual system had properties that made it something other than complicated. And in both cases, the gap between what the governance model could see and what the system was actually doing produced the conditions for catastrophic emergence.

Katrina: agents on the ground adapted to local conditions faster than the governance system could integrate those adaptations. The emergent reality outpaced the official model of the situation.

2008: agents throughout the financial system optimized locally within their incentive structures. The emergent systemic risk was produced by the interaction of those optimizations, not by any single actor’s failure or intention.

Locally rational. Globally catastrophic. In both cases, the governance architecture was not designed to detect or respond to that class of outcome.

Share

The Reorientation

This is not an argument for pessimism about governance. It is an argument for precision about what governance is actually doing when it works.

Effective governance of complex systems is not better analysis of the same model. It is the continuous calibration of the governance model to match the actual variety of the system being governed. That requires mechanisms for detecting domain shift. It requires organizational structures that can expand their variety under pressure rather than contracting into protocol. It requires the epistemic discipline to question domain assignments even when the current model feels adequate, especially when it feels adequate.

Ashby called this requisite variety. Snowden called this sensemaking. Complexity science calls the failure mode maladaptation.

Practitioners can call it what they encounter it as: the moment when the system stops behaving the way the plan said it would, and the governance model has no mechanism for that.

That is not a management problem. That is a structural one. And structural problems require structural diagnosis before they can be addressed.

The framework is the forensic tool.

Nicole

Subscribe now

Share

Leave a comment

This article is that foundation.

What complexity science actually is
Complexity science is not a single discipline. It is a convergence – of physics, biology, economics, computer science, and systems theory – around a common observation: that many of the most important systems in the world cannot be understood by analyzing their parts in isolation.

The whole behaves differently from the sum of its parts. And the gap between those two things is where most governance models break down.
The field emerged formally in the 1980s, anchored by the Santa Fe Institute, where researchers from wildly different disciplines found themselves describing the same phenomena in different languages. Economies, ecosystems, immune systems, cities, and software architectures all exhibited behavior that linear analysis could not predict and reductionist methods could not explain.
What they shared was structure. And that structure has a name: complex adaptive systems.

Share

Complex adaptive systems
A complex adaptive system – CAS – is a system composed of many agents that interact with each other and with their environment, adapt based on those interactions, and produce collective behavior that no single agent controls or fully anticipates.

Your program is not a complex adaptive system in the technical sense. But the environment your program operates in almost certainly is. The stakeholder ecosystem, the policy landscape, the technology market, the regulatory context – these are all CAS. And the behavior of your program is shaped, constrained, and sometimes overwhelmed by the dynamics of the systems surrounding it.

Four properties define how a CAS behaves. Each one has direct governance implications.

Property one: Emergence
Emergence is the production of system-level behavior that cannot be predicted from the properties of individual components. It is not a failure of analysis. It is a structural feature of complex systems.

Traffic jams emerge from individual driving decisions. Market crashes emerge from individual trading behavior. Policy failures emerge from individually rational organizational responses to individually rational incentives. No single actor caused any of these outcomes. All of them produced them together.

For governance, emergence means that outcomes cannot be fully designed – only influenced. The governance question shifts from “what will happen if we do this?” to “what conditions are we creating, and what kinds of outcomes do those conditions make more or less likely?”
This is a profound reorientation. Most program governance is built on the assumption that outcomes are designed. In complex environments, that assumption produces the confidence to proceed and the inability to recover when emergence produces something the plan did not anticipate.

Share

Property two: Feedback
Complex systems are defined by feedback loops – circular chains of cause and effect where outputs become inputs. Two types matter for governance.
Reinforcing feedback amplifies change. A program that builds early credibility attracts better stakeholder engagement, which produces better outcomes, which builds more credibility. The same dynamic runs in reverse: early delays erode confidence, which reduces cooperation, which produces more delays. Reinforcing loops accelerate in both directions. They are the engine of both program momentum and program collapse.

Balancing feedback resists change and maintains stability. Regulatory constraints, budget ceilings, and organizational capacity limits are all balancing feedback mechanisms. They prevent runaway amplification but they also resist the acceleration your program needs when conditions change and adaptation is urgent.

Governance that cannot read feedback loops cannot govern complex systems. It can only react to the outcomes those loops produce – after the loop has already run.

Property three: Non-linearity
In linear systems, small inputs produce proportionally small outputs. In complex systems, that relationship does not hold.
Small changes can produce large effects. Large interventions can produce negligible results. The same action taken at different points in a system’s evolution can produce completely different outcomes. And the relationship between cause and effect may be invisible until the effect has already materialized.

This is the property that makes complexity science counterintuitive for practitioners trained in linear project management. Effort does not scale with outcome. Intervention does not guarantee response. And the search for the single root cause of a complex failure is almost always the wrong question – because complex failures are almost always the product of multiple interacting causes, none of which was sufficient on its own.

Share

Non-linearity demands a different relationship with governance data. Not just what happened – but where in the system’s feedback structure it happened, and what that location tells you about what is likely to happen next.

Property four: Adaptation
Complex adaptive systems learn. Their components respond to feedback, adjust their behavior, and change the system’s future dynamics in the process.

Stakeholders adapt to governance decisions. Technology markets adapt to regulatory signals. Organizational cultures adapt to incentive structures – sometimes in ways the incentive designers explicitly did not intend. Every governance intervention changes the system it is governing. And the changed system responds to the next intervention differently than it would have before.

Share

This is the property that makes static governance models progressively less fit over time. A governance model calibrated to the system at program initiation is governing a system that no longer exists by the time execution is underway.
Adaptation demands iterative governance design. Not as a best practice – as a structural necessity.

Three failure modes complexity science predicts
Complexity science does not just describe how complex systems work. It describes, with uncomfortable precision, how governance of complex systems fails.

The first failure mode is mistaking complexity for complication. The tools are different. The governance response is different. The confidence required is different. Programs that bring expert analysis to genuinely complex problems do not fail because the analysis is wrong. They fail because analysis, however sophisticated, cannot resolve genuine uncertainty it can only describe it more precisely.

The second failure mode is intervening at the wrong leverage point. Complex systems have high-leverage points – places where small interventions produce large, lasting change. They also have low-leverage points where large interventions produce little effect or produce effects opposite to those intended. Governance that does not understand system structure cannot distinguish between them. It pushes hard where the system is rigid and ignores the places where a light touch would move everything.

The third failure mode is governing the past. Feedback loops have delays. Effects materialize long after their causes. By the time a complex system failure is visible in program data, its structural cause may be months or years upstream. Governance systems that respond to visible outcomes are always governing the system as it was not the system as it is.

What this means for program governance
Complexity science does not offer a new set of tools to replace the ones you have. It offers a different way of seeing; one that makes the existing tools more precise and more honestly limited.

Share

Risk registers become more useful when they capture feedback structure, not just probability and impact. Stakeholder maps become more useful when they show interdependence and adaptation potential, not just position and influence. Governance cycle design becomes more useful when it is calibrated to the system’s rate of change, not the organization’s reporting rhythm.

And the hardest shift: governance confidence has to become epistemically honest. In complex environments, the appropriate governance posture is not certainty about outcomes. It is clarity about conditions, vigilance about feedback, and the structural capacity to respond when emergence produces what the plan did not.

What comes next
This canon has now moved from Ashby’s Law through governance design, through Cynefin’s sense-making domains, and into the structural logic of complex adaptive systems. Each layer has added precision to the same core question: what does it actually take to govern a system that is more complex than your governance model?
The next article answers that question from a different angle. Not by adding more theory, but by looking at what happens when complex systems fail at scale. Real institutional failures, read through the lens of everything this canon has built.

That is where the framework becomes a forensic tool.

Nicole

Subscribe now

Share

Leave a comment

What Cynefin is and what it is not
Cynefin is a sense-making framework developed by Dave Snowden at IBM in the late 1990s. It does not tell you what to do. It tells you what kind of situation you are in and why that distinction determines everything that follows.
Most practitioners first encounter it as a quadrant model. That reading is not wrong, but it is incomplete. Cynefin is less a categorization tool and more a way of reasoning about the relationship between cause and effect and how much of that relationship you can actually know before you act.

Share

The framework identifies five domains. Four of them describe conditions your program may operate in. The fifth – Disorder – describes the condition of not knowing which domain applies. That condition is more common than most governance models acknowledge.

The Clear domain
In the Clear domain, cause and effect are obvious. Best practices exist. The right response is to sense the situation, categorize it, and respond according to established procedure.
Most governance frameworks are designed for this domain. SOPs, templates, checklists, compliance requirements – these are Clear domain tools. They work precisely because the relationship between action and outcome is stable and well understood.

The governance failure in the Clear domain is not incompetence. It is complacency. Systems that appear stable can shift without warning into complexity or even chaos. Programs that govern as though everything is Clear are the ones that get surprised and stay surprised longest.

The Complicated domain
In the Complicated domain, cause and effect are knowable but not obvious. They require analysis, expertise, and time. Multiple right answers may exist. The right response is to sense, analyze, and respond. This is the domain most senior program managers operate in most of the time. The problems are real, the expertise is available, and the solutions are discoverable if you ask the right questions and give analysis the time it needs.

Share

The Requisite Variety framework lives here. So do most risk management methodologies, architecture reviews, and structured decision processes. Expertise is the currency of the Complicated domain. The governance failure here is not ignorance it is the wrong kind of expert. Bringing a Clear domain tool to a Complicated problem produces false confidence. Bringing a Complicated domain tool to a Complex problem produces something more dangerous.

The Complex domain
In the Complex domain, cause and effect can only be understood in retrospect. No amount of analysis will predict how the system will behave. The right response is not to analyze and then act: it is to probe, sense, and respond.

This is the domain that breaks most governance models. Programs operating in Complex territory need something their standard governance architecture was not built to provide: the capacity to run safe-to-fail experiments, read emergent signals, and adjust course before the pattern becomes irreversible.

Share

The word that matters here is emergent. In Complex systems, outcomes are not designed, they surface. Governance cannot prevent emergence. It can only create the conditions for good emergence and limit the damage of bad emergence.

For program managers, this means the governance questions shift. You stop asking: what is the right plan? You start asking: what are we learning, and how fast can we act on it?

The Chaotic domain
In the Chaotic domain, there is no perceivable relationship between cause and effect. The system is in crisis. Analysis is not possible and waiting for it is itself a decision with consequences. The right response is to act, sense, and respond. Not to plan. Not to convene a working group. To act decisively, visibly, and with the explicit goal of moving the system out of chaos and into complexity, where sense-making becomes possible again.

Chaotic conditions in programs look like vendor collapse, data breach, sudden leadership loss, or political reversal of a program’s mandate. The governance instinct to escalate, document, and wait for direction is precisely wrong in this domain. The governance imperative is to stabilize first and understand second.

The leader who mistakes Chaos for Complexity will analyze while the situation deteriorates. The leader who recognizes Chaos acts and creates the conditions for recovery.

Share

The domain your program actually lives in
Here is the governance question Cynefin demands: which domain does your program actually operate in and which domain does your governance model assume?

That gap is where programs fail. A program managing a novel AI-enabled service delivery platform is not operating in the Complicated domain, no matter how many architecture reviews it commissions. It is operating at the boundary of Complex and Complicated with episodes of Chaos when integrations fail and political conditions shift.

A program managing a regulatory compliance migration is not operating in the Complex domain, even if the stakeholder landscape is difficult. It is primarily Complicated, with pockets of Clear. The expertise exists. The right governance tools are analytical, not experimental.

Misreading the domain does not just produce the wrong governance response. It produces a governance system that cannot learn because it is not designed for the kind of knowing the domain requires.

What Cynefin changes about governance design
The Requisite Variety framework gives you a way to close the gap between governance capacity and system complexity. Cynefin tells you that the nature of that gap changes depending on which domain you are in.

In the Clear domain, the gap is a process gap. Close it with standardization.

In the Complicated domain, the gap is an expertise gap. Close it with analysis and specialist authority.

In the Complex domain, the gap is a learning gap. Close it with experimentation, fast feedback loops, and the governance structures that make safe-to-fail probing possible.

In the Chaotic domain, the gap is a stability gap. Close it with decisive action and worry about understanding later.

Share

Not sure which domain your situation actually falls in? I built a five-question diagnostic that maps your situation to the right framework: Cynefin, Ashby’s Law, CAS Theory, or Systems Thinking.

Use the framework here - Framework Finder

Nicole

Subscribe now

Share

Leave a comment

The science means something more specific than that. And the specificity matters for how we understand what programs actually produce, and why they so often produce something other than what was planned.

What Emergence Actually Describes

In complexity science, emergence refers to properties that appear at one level of a system that are not present in, and cannot be predicted from, the properties of the system’s components.

Temperature is the classic example. Individual molecules do not have temperature. Temperature is a property of a collection of molecules in interaction. It is real. It is measurable. But it does not exist at the level where you would look for it if you were studying molecules in isolation.

This is not a mystical claim. It is a structural one. The property is generated by the pattern of interactions between components, not by the properties of the components themselves.

A January 2026 paper published in *Patterns* (Cell Press) by Erik Hoel of the Allen Discovery Center at Tufts formalizes this. Hoel introduces a theory of emergence that distinguishes which scales of a system irreducibly contribute to its causal workings. The finding: macroscales are not just compressed summaries of microscales. They add genuine causal information. What happens at the program level is not reducible to what happens at the project level. The program level has its own causal logic.

This is not an academic point. It is the strongest intellectual case for why program management is a distinct discipline, not a scaling of project management.

Share

What Programs Produce That Projects Do Not

When organizations manage a set of related projects without program-level governance, they typically find that the projects succeed individually and the program fails collectively. The individual projects deliver on time and on budget. The intended outcome does not materialize. The benefits are not realized. The capability the program was supposed to build is either absent or fragmented across teams that cannot interface with each other.

This is an emergence failure. The program-level outcome was supposed to emerge from the interaction of the projects. But without governance that actively manages those interactions, what emerges is something else entirely. Each project optimizes locally. Dependencies go unresolved. Integration is deferred until it is too late. The program achieves project success and outcome failure simultaneously.

This failure mode has a recognizable signature: strong project reporting, weak benefits realization. Milestones hit, value not captured. The metrics look fine until the program closes.

The scientific framing clarifies what is actually happening. Project management manages components. Program management manages the interactions between components. And the interactions are where the outcome lives. Not because of any philosophical claim about wholes and parts, but because the causal mechanisms that produce program-level outcomes are genuinely located at the interaction layer, not the component layer.

The Four Conditions for Emergence

Research on organizational emergence consistently identifies four conditions that determine whether an emergent outcome is possible.

The first is a disequilibrium state. Systems in comfortable equilibrium do not generate novel outcomes. Something has to disturb the current pattern before a new one can form. In a program context, this is usually the forcing function: a strategic imperative, a regulatory deadline, a competitive threat. The disequilibrium is what makes the program necessary in the first place. It is also what makes it difficult. Programs born out of genuine urgency are programs born into instability, and instability is not a problem to be eliminated. It is the precondition for the outcome to form.

Share

The second condition is amplifying actions. Small signals need pathways to grow. In organizations, those pathways are usually informal: the conversation in the hallway that spreads to a team, the prototype that gets seen by a sponsor, the failure that becomes a turning point when someone gives it the right interpretation. Programs that suppress anomalies, route everything through formal channels, and treat informal communication as a governance risk are programs that cut off their own amplifying mechanisms. The signal that could have redirected the program early gets filtered out before it reaches anyone with the authority to act on it.

The third condition is recombination and self-organization. The components of the system need enough autonomy to rearrange themselves in response to what they are learning. This is deeply uncomfortable for program governance structures built on control. But rigidity at the component level prevents the interaction layer from finding new configurations. You cannot plan an emergent outcome into existence. You can only create the conditions that allow it to form. Programs that lock down their workstreams in the name of coordination often discover they have produced coordination without adaptation, which is a different and worse problem.

The fourth condition is stabilizing feedback. Emergence needs constraints. A system with unlimited freedom to reconfigure itself produces noise, not novelty. The governance architecture of a program, when it is working well, is the stabilizing feedback. It is not the source of the outcome. It is the boundary conditions within which the outcome can emerge. This reframes what governance is actually for: not oversight of the components, but stewardship of the conditions.

Share

What This Means for Program Governance Design

The conventional view of program governance is oversight. Someone monitors the projects. Someone reviews the reports. Someone flags the variances. The governance structure is primarily an accountability mechanism, and its success is measured by how clean the reporting looks.

The emergence view is different. Governance is an ecological design problem. You are creating the conditions under which the right kind of emergence becomes possible.

That means attending to things that standard governance structures do not track. Whether weak signals from individual projects have any pathway to the program level, or whether they die in the reporting chain before reaching anyone who can assess their significance. Whether there is enough slack in the system for recombination, or whether cost and schedule pressure have been optimized to the point where the program can execute the plan but cannot adapt to what it is learning. And whether anyone actually holds the integration function, or whether it is assumed to happen through proximity and goodwill between project managers who are each accountable for their own delivery and nobody is accountable for the spaces between.

That last one is where most programs quietly fail. Project managers own their projects. The PMO owns the reporting. Nobody owns the interaction layer where the program-level outcome actually lives. The unowned space is not an oversight. It is a structural feature of how program governance is usually designed, and it produces structural failure with remarkable consistency.

Share

The Level You Are Managing Matters

The strongest practical takeaway from the science of emergence is this: you have to know which level you are managing, because the mechanisms that produce outcomes at different levels are genuinely different.

Project-level management is about execution: scoping, scheduling, resourcing, risk, delivery. The causal mechanisms are relatively tractable. Better plans produce better outcomes. Clearer requirements reduce rework. Good risk management prevents surprises.

Program-level management is about interaction: dependencies, integration, alignment, emergent properties. The causal mechanisms are less tractable. You cannot plan your way to a program-level outcome any more than you can plan the temperature of a gas by managing individual molecules. You create conditions and govern boundaries.

The profession has spent decades building a body of knowledge about the project level. The emergence science suggests that the program level requires something genuinely different, not just more of the same with a larger scope. Hoel’s January 2026 research gives that intuition a rigorous foundation: the program level is not a summary of the projects. It is a distinct causal layer.

Managing at that layer requires a different posture, different questions, and a different relationship to control than project management instincts tend to produce. The outcome you are after is not inside the projects. It is in what happens between them.

That is what makes program management a discipline, not a job title.

Nicole

Hoel, E. (2026). Quantifying emergent complexity. Patterns, 7(1). https://doi.org/10.1016/j.patter.2025.101472

Subscribe now

Share

Leave a comment

Paul Graham is not someone who writes casually. The co-founder of Y Combinator and one of the most widely read essayists in tech, he takes a narrow subject and uses it to say something uncomfortably true about how fields, economies, and careers actually work. His March 2026 essay The Brand Age starts with Swiss watchmaking and ends somewhere that should give anyone building a serious career pause.

On the surface, the argument is about watches. Underneath, it is about what happens to any discipline once technology eliminates real performance differences between products or practitioners. When substance disappears, brand fills the vacuum. And brand, as Graham argues, is structurally opposed to doing good work.

The Three Phases Every Field Goes Through

Graham breaks the Swiss watch industry into three eras. The structure generalizes far beyond watches.

The Golden Age (1945–1970). Hard problems. Real performance differences. Prestige earned through craft. The best makers focused on the essential tradeoff: accuracy and thinness. Form followed function.

The Crisis (1970–1985). Quartz movement made precision a commodity overnight. Foreign competition and currency shocks dismantled the structural advantages the Swiss had relied on for decades. Most of the industry became insolvent.

The Brand Age (1985–present). Survival through status. Watches grew larger to display brand. Artificial scarcity replaced engineering excellence. Revenue recovered. The soul of the craft did not.

Share

The watchmakers who survived did so by accepting they could no longer win on performance. Quartz movements were not only more accurate than any mechanical movement, they were thinner too. So the survivors pivoted to selling identity. And it worked, at least by revenue.

“Brand is what’s left when the substantive differences between products disappear. But making the substantive differences between products disappear is what technology naturally tends to do. So what happened to the Swiss watch industry is not merely an interesting outlier. It’s very much a story of our times.”

Paul Graham, The Brand Age

The Structural Conflict Between Brand and Design

This is the sharpest move in the essay. Graham does not say brand is merely separate from good design. He says it is **opposed** to it. Good design converges on right answers. Brand must diverge. If you choose the optimal solution, other people will choose it too. You will not be recognizable. You will not be a brand.

“Branding isn’t merely orthogonal to good design, but opposed to it. Branding by definition has to be distinctive. But good design, like math or science, seeks the right answer, and right answers tend to converge. Branding is centrifugal; design is centripetal.”

Paul Graham, The Brand Age

Share

He extends the argument beyond watches. If you want a group to look visibly different, you cannot ask them to do convenient things, because other people would do convenient things too. Distinctiveness requires a tax on reasonableness. That is not a side effect of branding. It is the mechanism.

The Patek Philippe Nautilus, launched in 1976, was 42 millimeters in diameter at a time when premium golden-age watches ran 32 to 33 millimeters. It had decorative protrusions on either side of the face. It could be recognized from across the room. By golden-age standards, it was a step backward in design. It is now the most sought-after watch Patek makes.

Quality Becomes a Threshold, Not a Differentiator

One of Graham’s most useful observations is about what happens to quality once brand takes over. It does not become irrelevant. It becomes a floor.

“Quality doesn’t stop mattering when a product switches to something people buy for its brand. But the way it matters changes shape. It becomes a threshold. It no longer has to be so great that it sells the product; brand sells the product; but it does have to be good enough to maintain the brand’s reputation. The brand must not break character.”

Paul Graham, The Brand Age

Share

A brand-age Patek Philippe still has to keep time. It still has to feel substantial. It cannot fall apart. But it is not competing on those dimensions anymore. It is competing on the story it tells about the person wearing it. Quality is the price of admission, not the point of the game.

That shift happens in careers too. It is the difference between a credential that reflects what you actually know and one that reflects that you completed a process. Both clear the bar. Only one means something beyond the bar.

What This Looks Like in a Career

Most fields follow the same arc Graham describes. The patterns show up differently depending on the industry, but the underlying dynamic is consistent.

Credential Theater

Credentials start as quality signals. They emerge in fields where the problems are hard and the differences between skilled and unskilled practitioners are real. Over time, as the field matures and the certification market grows, the credential can become the brand. The process of getting it becomes the point rather than what the process was designed to verify.

Share

When that happens, the incentive shifts. You optimize for the credential, not the capability it was supposed to represent. And the people who actually developed the capability often find themselves competing with people who optimized for the signal.

The credential is not the problem. The question worth asking is whether the field it comes from still has live, unresolved problems attached to it. Credentials earned at the frontier of a field carry different weight than credentials earned in a field that has already been packaged and standardized.

Framework Proliferation

The watchmakers eventually found that advertising centered on cost and exclusivity outperformed competing on technical performance. The professional equivalent is the constant production of new frameworks, methodologies, and models that circulate through conferences and consulting engagements without solving materially different problems than the ones before them.

The frameworks get larger and more decorated. They develop recognizable visual identities and branded vocabularies. Whether they produce better outcomes than their predecessors is rarely the central question. Recognition is.

Artificial Scarcity of Expertise

Graham describes Patek’s scarcity strategy: restrict supply, police the secondary market, build waiting lists. The professional equivalent is knowledge that never gets documented, shared, or transferred. Expertise that cannot be replicated holds its value longer. Expertise that is made legible and transferable becomes a commodity.

In fields and organizations without strong cultures of documentation and knowledge sharing, this scarcity often develops through inertia rather than strategy. The effect is the same either way.

Share

The Prescription

Graham closes with a principle simple enough to overlook and sharp enough to keep. The way to avoid brand-age fields, and to find golden-age ones, is to follow interesting problems. Not credentials, not prestige, not the institutions that have come to represent a field.

“What a golden age feels like, at the time, is just that smart people are working hard on interesting problems and getting results. It would be overfitting to optimize for more than that.”

Paul Graham, The Brand Age

The signal that you are in a golden-age field is that the problems feel live and unresolved. The work is harder to explain at a dinner party because it does not have a clean name yet. The practitioners are still arguing about fundamentals. The certifications, if they exist at all, are still catching up to what people are actually doing.

Brand-age fields feel the opposite. The vocabulary is settled. The career path is legible. Everyone knows what the prestigious credential is and what the prestigious firms are. That legibility is comfortable, but it is also a sign that the field has already made its most interesting moves.

There is a version of building a career that optimizes for recognizability: the right titles, the right logos on the resume, the right frameworks cited in the right order. There is another version that looks more like what the golden-age watchmakers were doing, working on the problem that actually needs solving, doing it well, and earning a reputation because the work warranted it.

Share

The first version is more legible and often more rewarding in the short run. But when the next disruption comes, the people who were following problems will be able to follow the new ones. The people who were following brand will be left holding credentials in a field that no longer has the same problems.

Stay close to work that does not yet have a clean answer.

Nicole

Source: Paul Graham, “The Brand Age,” paulgraham.com, March 2026

Subscribe now

Share

Leave a comment

The word is interdependencies.

Not risks. Not blockers. Not issues.

Interdependencies.

The shift is small. The implications are not.

Hat We’ve Been Trained to See

Most project managers are trained, explicitly or implicitly, to see work as a collection of tasks. You build a WBS. You sequence activities. You assign owners. You track completion percentages. The mental model underneath all of it is fundamentally linear: discrete units of work, moving from left to right across a timeline.

This is not wrong. For a large class of projects, task-based thinking works well enough. When the work is well-understood, the environment is stable, and the team has done something like this before, managing tasks is managing the project.

But increasingly, that is not the work most project managers are actually doing.

The projects landing on PM desks today tend to be cross-functional, multi-stakeholder, politically complex, and technically uncertain. They involve systems that are already in motion. They involve people whose incentives do not perfectly align. They involve decisions that ripple in ways that no one fully anticipated when the project charter was signed.

Share

Task-based thinking was not designed for this terrain. And it shows.

What Interdependency Thinking Actually Means

An interdependency is not a dependency.

A dependency is linear: Task B cannot start until Task A is done. It flows in one direction. It is mappable, schedulable, manageable.

An interdependency is relational: System A and System B influence each other. The relationship runs in both directions. Change one, and the other shifts, sometimes in ways that loop back and change the first.

This is the core insight from systems thinking that is now surfacing in project management literature, PMI thought leadership, and practitioner conversations: complex projects are not chains of tasks. They are webs of relationships. And managing a web requires different instincts than managing a chain.

The vocabulary matters because vocabulary shapes attention. When you are trained to see tasks, you look for tasks. When you learn to see interdependencies, you start noticing the relationships between things, between teams, between decisions, between timelines, between incentives that were always there but weren’t legible inside the old framework.

Share

Five Places This Shift Is Showing Up

1. Planning conversations are moving upstream.

The trend that is most visible right now is a push to use systems thinking earlier not as a risk management activity after the plan is set, but as a problem framing activity before it is. Teams are asking: are we solving the right problem? And: what does the system around this problem actually look like? This is the interdependency lens applied to scope definition itself.

2. Stakeholder mapping is getting more sophisticated.

The older model of stakeholder management was essentially a power-interest grid snapshot. The newer model treats stakeholders as actors in a dynamic system, with relationships to each other, not just to the project. Who influences whom? Where are the informal trust networks? Where are the misaligned incentives that will surface later as “resistance”? These are interdependency questions.

Share

3. Risk thinking is evolving toward feedback loops.

Traditional risk management identifies discrete risks and assigns probability and impact scores. Systems-aware risk thinking asks a different question: where are the feedback loops in this project that could amplify a small problem into a large one? The language of feedback loops, which comes directly from systems thinking is appearing in PM writing and training with increasing frequency.

4. Agile and systems thinking are converging.

One of the more interesting developments is that agile practitioners and systems thinkers are finding common ground. Both frameworks are fundamentally oriented toward complexity and adaptation rather than prediction and control. The language is different, but the underlying logic is similar: assume the system will surprise you, and design your process to detect and respond to that.

5. Outcomes are replacing outputs as the unit of success.

This is perhaps the deepest vocabulary shift. Outputs are task-level: did we deliver the thing? Outcomes are system-level: did delivering the thing actually change anything? The move toward outcome orientation in project and program management is, at its root, a systems thinking move. It reorients the entire project toward the system the project is trying to influence, not just the work the project is trying to complete.

Share

Why This Matters for How You Talk About Your Work

Vocabulary is not just descriptive. It is positional.

The project managers who are gaining influence in complex environments right now are not the ones with the most detailed project plans. They are the ones who can walk into a room and articulate what is actually going on, the real structure of the problem, the relationships that matter, the feedback loops that are already in play.

That requires a different vocabulary than task lists provide.

Interdependencies. Feedback loops. Stakeholder ecosystems. Problem framing. System boundaries. These are not buzzwords. They are the conceptual tools that let you see and describe work that task-based language obscures.

If you are managing complex, high-stakes, cross-functional work, learning to speak this language is not optional. It is a core competency for the environment you are actually working in.

The projects are getting more complex. The vocabulary has to keep up.

PM Researcher publishes at the intersection of thinking architecture and project practice. If this framing is useful, share it with someone doing hard PM work.

Nicole

Subscribe now

Share

Leave a comment

The diagnostic is a brief, not a verdict
Most program managers encounter complexity assessments as retrospective tools; instruments that explain what failed after the fact. The Requisite Variety Diagnostic is not that. It is prospective.

It tells you where your governance model will break before the system forces the answer.

That reframe matters. A deficit is not a failure. It is a design specification.

The question is: what do you redesign?

Share

Three levers, not one
Ashby’s Law is deceptively simple: a system’s controller must have at least as much variety as the system it governs. But when people first apply it, they reach for the most visible lever.

In governance, that lever is usually process. More reviews. More checkpoints. More documentation. More meetings.

This is variety amplification by volume, and it rarely works. Adding steps to a governance process does not increase regulatory capacity. It may just slow the system down while complexity compounds undetected. Ashby’s Law points to three distinct levers for closing the variety gap. You can amplify the variety of your governance system. You can attenuate the variety of the system being governed. Or you can do both.

Understanding which lever applies and where is the actual work.

Lever one: Amplify your governance variety
Amplification means increasing the range of responses your governance system can generate. This is not about adding more of the same. It is about adding different.
In practice, this might look like cross-functional decision authority giving your program office the ability to absorb technical, legal, financial, and stakeholder signals at once rather than routing each through a separate queue. It might look like real-time data access rather than periodic reporting cycles. It might look like distributed authority, where frontline teams have bounded autonomy to respond to local complexity without waiting for the center.
Governance variety is not a function of how many rules you have. It is a function of how many meaningfully distinct responses you can generate, and how fast.

Lever two: Attenuate the system’s variety
Attenuation means reducing the complexity your governance system has to absorb. This requires something more demanding than process design: it requires discipline about scope.
You are not simplifying the underlying system. You cannot legislate complexity away. What you can do is filter, prioritize, and sequence the signals your governance layer has to process at any given time.
Modular architecture is an attenuation strategy. Phased delivery is an attenuation strategy. A tightly scoped charter that defines what your program will not absorb is also attenuation.
This is not avoidance. It is design.

Lever three: Both at once
The most durable governance designs work both levers together. They build regulatory capacity into the governance system while reducing the complexity surface that capacity has to cover.
This is where your diagnostic results become a design map. A deficit concentrated in technical complexity signals a need for amplification, more variety in how your governance system reads and responds to technical signals. A deficit concentrated in stakeholder variety signals a need for boundary management, attenuation strategies that define what the program is not responsible for absorbing.
The diagnostic does not tell you which lever to pull. It tells you where to look.

Share

What governance actually has to do
Ashby’s Law has a quiet implication that most program management literature sidesteps: governance is not a neutral administrative layer. It is a regulatory system. And like any regulatory system, its fitness is determined by one thing – the relationship between its own variety and the variety of what it governs.
Governance design is not about getting the process right. It is about getting the capacity right. Structure, authority, information flow, decision speed, and boundary setting are all variety variables. Every governance choice you make either closes the gap or widens it.

The diagnostic gave you the map. This article gave you the levers. The next piece in this series will give you a framework for applying them to your own program, beginning with the decisions that carry the most weight.

Nicole

Subscribe now

Share

Leave a comment

This diagnostic gives you a structured method for measuring that gap in a system you govern and for producing a written argument that makes the case for structural change rather than better effort.

Download the PDF below to work through all five steps, a fully worked example, a glossary of core terms, a gap type decision guide, an annotated reading list, and a scope note on what the diagnostic cannot do.

Allow 45 to 90 minutes. Write in complete sentences. The precision of your language is part of the diagnostic.

Nicole

Requisite Variety Diagnostic Gumroad

31.9KB ∙ PDF file

Download

Download

If you haven’t read the prior article:

Leave a comment

Read more

The theorem was published in 1970 by Roger Conant and W. Ross Ashby. Its title is its entire argument: Every good regulator of a system must be a model of that system.

Not a monitor of it. Not a reporter on it. A model of it.

The distinction matters more than most governance conversations acknowledge.

What the Theorem Actually Says

Ashby had spent the previous decade formalizing the Law of Requisite Variety, the principle that a controller must possess at least as much variety as the system it governs. If you read the last piece in this series, you know the mechanics. Variety is the number of distinguishable states a system can occupy. A governance structure with insufficient variety to match its system is not in control, regardless of what the org chart says.

The 1970 paper with Conant pushed the argument one level deeper. It asked: what does a regulator need, internally, to actually govern something? The answer they proved, under broad mathematical conditions, was this: any regulator that is maximally both successful and simple must be structurally isomorphic with, must mirror the system it regulates.

Share

In plain terms: you cannot govern what you do not model. The model does not have to be explicit. It can be embedded in a governance structure, in sensing mechanisms, in the decision rules of a team. But it must exist. A regulator without an adequate internal model of its system is not, in any meaningful sense, a regulator. It is a witness.

This is not a management insight. It is a mathematical constraint.

The Shape of the Failure

When Conant and Ashby write “model,” they mean something specific. A model of a system is a representation that preserves the relevant structural relationships, the dependencies, the feedback loops, the interaction effects, the failure modes. A good model allows the regulator to anticipate states the system might enter and prepare a response before those states materialize.

Share

The absence of a model does not look like ignorance. It looks like oversight.

This is what makes the theorem so uncomfortable for anyone in a governance role. An oversight function can hold full organizational authority over a system and still lack a working model of it. The dashboard is updated weekly. The steering committee meets monthly. The risk register is current. And the actual system, its dependencies, its integration behavior, and its emergent failure patterns is running on a model that exists nowhere in the governance structure.

When something goes wrong, there is genuine surprise. Not because the warning signs were absent, but because the governance structure was not configured to recognize them as warning signs. The regulator’s model did not contain those states.

Share

Ashby described this gap in his original framing of the Law of Requisite Variety in 1956: “Regulation is possible only if the regulating system is as various and flexible as the system to be regulated. This principle disposes of the myth still cherished by journalists and sociologists in search of easy popularity that extraordinarily complex situations demand the concentration of extraordinary powers in a central entity.”

The concentration of authority does not solve a modeling problem. It consolidates it.

Two Cases, Same Theorem

If you read the prior piece in this series, the healthcare.gov and Boeing cases are already familiar. What the Conant-Ashby theorem adds is the precise diagnosis.

At healthcare.gov, the structural failure was not a shortage of authority or resources. It was the absence of any party holding a working model of the integrated whole. Individual contractors modeled their own components. The governance layer modeled the program plan. The integration space where components connected, interacted, and failed had no corresponding model. The repair that worked was not managerial. It was the appointment of a systems integrator whose specific function was to hold and continuously update a model of the whole.

At Boeing, the FAA retained formal oversight authority while losing epistemic access to the system it was supposed to certify. The Organization Designation Authorization program meant the FAA was not operating on its own model of the 737 MAX. It was operating on Boeing’s representation of that model. The 2020 House Transportation Committee investigation found that representation had been, in several critical instances, “highly edited.” The regulator was governing a fiction while the actual system went unmodeled and unchecked.

Authority without a model is ratification, not regulation. Both cases illustrate the same theorem. The difference is only in the cost of the gap.

Share

What This Means for Anyone Who Governs Complex Systems

The Conant-Ashby theorem is not an indictment of any particular governance approach. It is a structural constraint that applies to all of them. The question it asks of every oversight function is simple: do you have a working model of the system you govern?

Not a model of the plan. Not a model of the org chart. A model of the system — its dependencies, its failure modes, its emergent behaviors, the states it can enter that your governance structure has not anticipated.

Here is where it gets uncomfortable. Most governance is designed to model the work, not the system. Scope, schedule, cost, risk, and quality; these categories reduce a program to a manageable representation. That reduction is necessary and appropriate. It is also a form of attenuation. When the system’s actual complexity exceeds the model’s representational capacity, the governance structure begins producing accurate readings of itself rather than accurate readings of the system.

The dashboard is green. The system is failing. Both statements are true simultaneously because they describe different things.

Three questions worth asking of any governance structure:

First: Where is the integration modeled? In complex systems, the most dangerous failure territory is not within components; it is between them. The space where one contractor hands off to another, where systems must talk to each other, where requirements meet implementation. If no part of the governance structure holds a working model of those interfaces, that territory is ungoverned regardless of what the charter says.

Second: At what level does the model update? A governance model calibrated monthly cannot regulate a system that generates new states daily. The temporal relationship between the system’s behavior and the regulator’s model determines whether governance is anticipatory or retrospective. Retrospective governance is not governance. It is documentation.

Third: Whose model is the governance structure relying on? The Boeing case names what happens when a regulator substitutes another party’s model for its own. If an oversight function’s understanding of system state is mediated entirely through self-reports, vendor dashboards, and briefings prepared by the parties being overseen, it is not modeling the system. It is modeling their representation of it.

Share

The Regulator You Actually Need

Conant and Ashby’s theorem has a corollary that rarely surfaces in governance conversations. They note that the brain, to function as an effective regulator of survival, must continuously form models of its environment. This is not optional. It is the mechanism by which regulation becomes possible.

The implication for governance design: building a working model of the system is not a prerequisite for governing it. It is the act of governing it. An oversight function that does not continuously update its model of the system is not governing. It is occupying the governance role.

This is the distinction between a steward and an administrator. Both have authority. Only one has a model.

Stafford Beer, who spent his career translating Ashby’s mathematics into organizational design, put it plainly: the purpose of a system is what it does, not what it says it does. Applied to governance: the measure of an oversight function is not the authority it holds. It is the model’s accuracy that it maintains.

You cannot govern what you cannot model. You cannot model what you cannot sense. You may not be able to sense what your governance structure wasn’t designed to see.

The theorem is fifty-five years old. The failures it describes are not.

Paid subscribers can download the Requisite Variety Diagnostic, a five-step applied worksheet for mapping variety gaps in a system you govern, as part of your subscription.

If you are not yet a subscriber, the diagnostic is available as a standalone purchase on Gumroad.

Nicole

This is part of the PM Researcher systems thinking canon series. The prior piece covers Ashby’s Law of Requisite Variety, the theorem that precedes this one and grounds everything above.

Subscribe now

Share

Leave a comment

Sources

Conant, R.C. and Ashby, W.R. (1970). “Every good regulator of a system must be a model of that system.” *International Journal of Systems Science*, 1(2), 89–97.

Ashby, W.R. (1956). *An Introduction to Cybernetics*. Chapman & Hall. Freely available at archive.org.

House Committee on Transportation and Infrastructure (2020). *Final Report: The Design, Development & Certification of the Boeing 737 MAX*. Chairs DeFazio and Larsen.

CMS (2013). *HealthCare.gov Progress and Performance Report*. Centers for Medicare and Medicaid Services.

If you haven’t read that piece yet, it’s worth starting there. What follows will make more sense with that foundation.

Something breaks on a complex project. The response is immediate and instinctive: add a checkpoint. Create a review layer. Require sign-off. Build a dashboard. Hire someone to own it.

The system gets more complicated. The problem does not go away. So the next time something breaks, the same response follows. More process. More oversight. More control.

Share

This pattern is so common that most organizations. In many cases it is the mechanism of intelligent, well-intentioned leaders make.

W. Ross Ashby identified why in 1956. Most people running organizations today have never encountered his work. The ones who have tend to manage differently.

The Law Nobody Taught You

Ashby was a British psychiatrist and cybernetician. In 1956, as part of the foundational work in cybernetics that developed in parallel with systems thinking and preceded complex adaptive systems theory, he formulated what he called the Law of Requisite Variety.

The law states: only variety can absorb variety.

In plain terms: a controller can only regulate a system if the controller has at least as many available responses as the system has possible states. If the environment can produce ten kinds of disruption and your management system can only produce three kinds of response, you will be overwhelmed by the other seven. Not because you lack effort or intelligence, but because the mismatch is structural.

Share

This is not a metaphor. It is a constraint. The system does not care about your intentions.

The implication for anyone running an organization, a startup, a program, or a team is uncomfortable: when your environment grows more complex, the correct response is to grow the variety of your management system to match it. Simplifying your governance, standardizing your processes, and centralizing your decisions the instinctive responses to complexity reduce variety exactly when you need more of it.

This is what connects Ashby’s Law to the progression we started in the last piece. Systems thinking taught us to see feedback loops and nonlinear dynamics. Cynefin taught us to recognize when we have crossed from complicated terrain into complex terrain. Complex adaptive systems theory explained why complex systems behave the way they do. Ashby’s Law tells us what to actually do about governance when we get there.

Three bodies of work converge here, and it is worth naming them before we get to the cases.

Ashby formulated the law in 1956. Stafford Beer, the British cybernetician who founded the field of management cybernetics, spent the following decades translating it into organizational design. Beer’s Viable System Model, developed through the 1960s and 1970s, built directly on Ashby’s requisite variety principle and argued that any organization capable of surviving in a changing environment must be structured so that its internal variety matches what its environment can produce. Beer was not an academic writing for other academics. He was a working consultant who applied these ideas to real organizations across governments and industries. His central argument was uncomfortable and precise: the organizational charts leaders draw to show who controls what often bear little resemblance to the variety actually required to govern what the organization is doing. The gap between the two is where failure lives.

Separately, Bent Flyvbjerg spent thirty years doing something different. He gathered data. His research database, drawn from more than 16,000 projects across industries and countries, documented a pattern he called the iron law of megaprojects: over budget, over time, under benefits, over and over again. Flyvbjerg’s work is empirical where Beer’s is structural. He measured what Beer predicted. Nine out of ten large projects miss their targets. The pattern holds regardless of country, industry, or decade. Flyvbjerg diagnosed the failure as stemming from optimism bias, strategic misrepresentation, and governance structures that distort information as it moves upward through organizations. He did not use Ashby’s framework. But what he documented is exactly what Ashby’s Law would predict: management systems that are structurally simpler than the problems they are governing, failing in proportion to that mismatch, over and over, because the mismatch is structural rather than a product of incompetence.

Boisot and McKelvey, in their 2011 revision of Ashby’s Law in the context of complexity science, made the connection explicit in the academic literature. Their work positioned requisite variety alongside Cynefin and other complexity frameworks as a necessary tool for understanding how organizations relate to their environments. The academic case was made. It simply never reached the practitioners who needed it most, like me.

The case studies that follow are not abstract. They are well-documented, publicly examined failures. Each one is an Ashby’s Law story. Flyvbjerg would recognize the pattern in all of them. Beer would recognize the structural cause. None of them were diagnosed as variety mismatches at the time, which is precisely why the same failure keeps happening in different industries, at different scales, with different people making the same structural error.

Boeing 737 MAX: When the Regulator Was Simpler Than the Aircraft

The story of the 737 MAX is usually told as a story about corporate pressure, rushed timelines, and a culture that deprioritized safety. All of that is true. But underneath the cultural failures was a structural one that made the disaster close to inevitable before a single line of MCAS code was written.

By the 2010s, the FAA had developed a model of delegated certification. Rather than independently verify every system on a modern commercial aircraft an aircraft that had grown exponentially more complex over decades the FAA delegated significant portions of the certification process to Boeing’s own engineers, designated as Organization Designation Authorization representatives. The rationale was reasonable on its face: Boeing’s engineers understood the aircraft better than any outside regulator could. The FAA would oversee the process, set the standards, and review the outputs.

What this created was a regulatory system whose variety was structurally lower than the variety of the system it was certifying.

A modern commercial aircraft is one of the most complex engineered objects humans produce. The interactions between its systems aerodynamic, mechanical, electronic, software are nonlinear and not fully predictable from analyzing any individual component. MCAS, the Maneuvering Characteristics Augmentation System introduced on the MAX, was designed to compensate for the changed flight characteristics produced by larger, repositioned engines. It was a software solution to a physical problem, operating in a flight envelope that was genuinely novel.

The certification process governing it was not novel. It was a delegated review system designed for an earlier generation of aircraft complexity. Boeing engineers were evaluating Boeing systems against Boeing interpretations of FAA standards, with FAA oversight that lacked the independent variety to catch what the process was missing.

When MCAS malfunctioned, it did so in ways the certification process had not modeled. The system had more failure states than the governance structure had anticipated responses. The mismatch between aircraft complexity and regulatory variety was not a gap that more effort could have closed. It required a fundamentally different certification architecture one whose variety matched what it was governing.

346 people died in two crashes before the aircraft was grounded.

The lesson is not that the FAA was negligent, though there were negligent decisions made. The lesson is that a governance structure that is simpler than the system it governs will fail in proportion to that mismatch, regardless of the competence of the people operating it. Ashby’s Law does not grade on effort.

Healthcare.gov: The Coordination Complexity Nobody Governed

When healthcare.gov launched in October 2013 it collapsed almost immediately. The post-mortems focused on technical failures: servers that couldn’t handle load, integrations that didn’t work, testing that was insufficient. But the technical failures were downstream of a governance failure that Ashby’s Law describes precisely.

The build involved 55 contractors. Each was responsible for a defined scope. CMS, the Centers for Medicare and Medicaid Services, was the nominal owner and primary governance structure. The oversight model was traditional federal contracting: scope definition, milestone reviews, deliverable acceptance, status reporting.

This is a governance structure designed for projects where the work can be decomposed into independent workstreams and integrated at the end. It assumes the complexity is in the individual components, not in their interactions. It is a management system calibrated for complicated problems.

Healthcare.gov was not a complicated problem. It was a complex one. The interactions between 55 contractor systems, each built against specifications that were still evolving, against a regulatory environment that was itself still being defined, produced an integration complexity that no individual contractor owned and that CMS’s oversight model had no mechanism to sense or respond to.

The governance structure had three response modes: approve milestones, flag variances, escalate issues. The system being governed had thousands of possible failure states arising from interactions between components that no single party fully understood. The variety mismatch was not a planning failure. It was a structural one.

What healthcare.gov needed was a governance architecture with requisite variety: an integrator with genuine authority across all contractors, sensing mechanisms designed to detect cross-system failures before integration, decision-making capacity distributed to the level where problems were actually visible. What it had was a traditional oversight structure that could manage complicated work and was being asked to govern complex work.

The $2 billion rebuild that followed was not just a technical fix. It was a governance redesign. The Obama administration brought in a small team including a systems integrator, with broad authority, direct access to the President, and the autonomy to make decisions at the pace the system required. That team had more variety than the original governance structure. That is why it worked.

Share

The “Adult Supervision” Trap: When Boards Make It Worse

There is a pattern in venture-backed startups so common it has become a cliché. A high-growth company hits turbulence rapid scaling, cultural chaos, operational strain. The board, responding to legitimate concern, decides the founding team needs “adult supervision.” They recruit an experienced executive from a larger, more established company. Someone who has managed complexity before. Someone who knows how to build process and bring order.

Within twelve to eighteen months, the company is slower, the best early employees have left, and the founder is either sidelined or gone. The board is confused. The executive is frustrated. The company that was chaotic but vital is now orderly but struggling.

Zenefits is one of the cleaner documented versions of this story. Parker Conrad built a company that grew from zero to $4.5 billion valuation in roughly three years. The growth was real. So was the chaos compliance failures, a culture that had not kept pace with the company’s scale, internal controls that were not designed for a company of that size and regulatory exposure.

Share

When Conrad was pushed out and David Sacks brought in to stabilize the company, the response was to dramatically increase process and oversight. Compliance infrastructure, approval requirements, operational standardization. From the outside, these looked like the right moves. The company had been running with insufficient controls. Adding controls seemed like the obvious correction.

What happened instead was that the management system’s variety dropped sharply at the precise moment the company needed to navigate an extremely complex environment: a damaged reputation, a competitive market, regulatory scrutiny, and a demoralized team. The governance response reduced the organization’s capacity to sense and respond to a fast-moving situation. Zenefits never recovered its trajectory.

The pattern generalizes well beyond any single company. The error the board makes is misdiagnosing the problem. The company does not have too much variety. It has variety that is poorly directed. The correction is not to reduce variety through standardization. It is to structure variety so it is aimed at the right problems. Those are completely different interventions and they produce completely different outcomes.

Ashby’s Law reframes the “adult supervision” question entirely. The relevant question is not: does this executive have more experience? It is: does this management system have more variety than the environment it is trying to regulate? An executive imported from a stable, mature company often brings a management system calibrated for low-variety environments. Installing that system in a high-variety startup environment is not stabilization. It is a variety reduction at the worst possible moment.

Subscribe now

The Forty-Person Wall: Why Every Founder Knows This Feeling

There is a scaling threshold that founders talk about with a kind of resigned recognition. The company hits somewhere between thirty and fifty people and something that was working stops working. Communication breaks down. Decisions slow. The culture that felt self-sustaining starts requiring maintenance. The response is almost always the same: add structure. Define roles more precisely. Create management layers. Standardize how things get done.

Sometimes this works. Often it makes the underlying problem worse while creating the appearance of having addressed it.

What is actually happening at the forty-person wall is an Ashby’s Law transition. Below a certain size, an organization’s management system which at early stages is largely informal, relationship-based, and highly varied has enough variety to match the complexity of the environment. Everyone knows what everyone else is doing. Information flows freely. Decisions get made by whoever is closest to the problem.

As the organization grows, the environment’s complexity grows: more customers, more products, more markets, more stakeholders, more internal coordination surface. The informal management system that worked at fifteen people does not have enough variety to absorb the complexity of fifty people operating in a more demanding environment.

The instinctive response add hierarchy, standardize process, centralize decisions reduces variety. It trades the messy, high-variety informal system for a cleaner, lower-variety formal one. This can feel like progress because it produces legibility. Things look more organized. But legibility is not the same as regulatory capacity. A cleaner system that cannot match the variety of its environment will fail more neatly than a messy one, but it will still fail.

Subscribe now

Zappos recognized this problem explicitly. Tony Hsieh’s eventual turn toward holacracy a controversial and ultimately incomplete experiment was at its root an attempt to solve an Ashby’s Law problem. How do you preserve organizational variety as you scale? How do you keep decision-making capacity distributed to the level where problems are visible, rather than centralizing it upward where it is increasingly blind to local conditions?

The holacracy experiment failed for reasons worth examining separately. But the diagnosis it was responding to was correct. The standard scaling playbook hierarchy, standardization, centralization reduces variety. For complicated organizations operating in stable environments, that tradeoff is acceptable. For complex organizations operating in volatile environments, it is structurally self-defeating.

What Requisite Variety Actually Looks Like

The case studies above document what happens when variety is mismatched. But Ashby’s Law is not only a diagnostic tool. It points toward a different way of designing organizations and governance structures.

Some organizations have figured this out, not always by name.

Amazon’s two-pizza team structure is one of the better known examples. The principle teams small enough to be fed by two pizzas is often described as a communication heuristic. It is actually a variety preservation mechanism. Small, autonomous teams with genuine decision-making authority maintain the organizational variety that larger, more coordinated structures lose. Each team can sense its local environment and respond to it without routing decisions through a hierarchy that is too distant from the problem to have the right responses available.

The constraint is not the team size. It is the autonomy. A small team without genuine authority to act is just a committee. The variety comes from the combination of local sensing capacity and local response capacity. That combination is what Ashby requires.

Subscribe now

W.L. Gore, the company behind Gore-Tex, built its entire organizational philosophy around a related insight. Gore has no traditional hierarchy. Associates self-organize into teams around opportunities and commitments. Leadership emerges from demonstrated competence rather than appointed authority. The structure looks chaotic from outside and operates with remarkable stability from inside, because the management system’s variety is matched to the complexity of the work.

What these examples share is not a specific structure. They share a design principle: keep decision-making authority as close as possible to where information about the system’s state actually lives. This is the operational meaning of requisite variety. It is not about having more people or more process. It is about having the right response capacity distributed to the right levels.

Subscribe now

In practice, this means a few things that cut against standard organizational instincts. It means tolerating approaches that diverge from the original plan, because local conditions warrant local responses. It means building sensing mechanisms into the structure rather than treating sensing as a reporting function. It means accepting that a well-governed complex system will look, from a distance, like it is not fully under control because it is exercising the variety the situation requires rather than the tidiness that oversight prefers.

This last point deserves emphasis. The appearance of control and the reality of regulatory capacity are not the same thing. A highly standardized, centrally governed organization can look extremely well-managed while being structurally unable to respond to the complexity of its environment. A distributed, high-variety organization can look messy while actually maintaining the capacity to absorb what its environment produces. Ashby’s Law cares about the latter. Most governance structures are optimized for the former.

How to Audit Your Own Variety Mismatch

You do not need to have built an aircraft or launched a federal website to have an Ashby’s Law problem. The mismatch shows up at every scale. These questions are designed to make it visible.

How many distinct states can your environment produce, and how many distinct responses can your management system generate? This does not require a formal count. It requires honest estimation. If your market, your technology, your regulatory environment, or your team dynamics can produce ten kinds of disruption, can your governance structure produce ten kinds of response? Or does it have three responses escalate, review, approve that it applies to everything?

Share

When something unexpected happens, where does the decision get made? If the answer is always upward to the executive team, to the board, to the program office your decision-making variety is concentrated at the level furthest from the problem. That is a structural mismatch. The people closest to the disruption have the most information and the least authority. The people with the most authority have the least information and are making decisions with the highest variety consequences.

When your environment grew more complex, what did you do to your management system? If the answer is that you added process, approval layers, and reporting requirements, you almost certainly reduced your management system’s variety at the moment you needed to increase it. What did you do to increase the response capacity of the people closest to the work?

Where does sensing actually happen in your organization? Sensing is not the same as reporting. Reporting tells leadership what already happened. Sensing detects what is happening now and what is about to happen. If your primary sensing mechanism is a status report or a dashboard built from lagging indicators, your variety is limited to what those instruments can detect. Complex environments produce signals that don’t show up in standard reporting. Who is positioned to catch those signals, and do they have the authority to act on them?

What does your organization do with responses that diverge from the plan? If the answer is that divergence triggers escalation, review, and correction back toward the original approach, you have a management system that suppresses variety. Local adaptations are variety. Suppressing them in the name of consistency reduces your regulatory capacity. The question is not whether divergence should be visible. It should be. The question is whether the system’s response to divergence is to learn from it or to eliminate it.

Subscribe now

The Diagnostic, Not the Solution

Ashby’s Law does not tell you how to build your organization. It tells you what property your management system must have relative to the system it governs.

That is actually more useful than a prescription, because it reframes the question you are asking. The question is not: how do we get this under control? The question is: does our capacity to respond match the variety of what we are trying to govern?

Boeing’s certification process could not match the variety of a novel flight control system operating in an unanticipated flight envelope. Healthcare.gov’s oversight structure could not match the variety of 55 contractor integrations against a moving regulatory target. Zenefits’ new management system could not match the variety of a damaged, fast-moving company in a complex competitive environment. The startups that hit the forty-person wall and respond with standardization are trading variety for legibility at the moment legibility is least useful.

In each case the people involved were not negligent or incompetent. They were applying management instincts that work well in complicated environments to complex ones. Ashby’s Law is the formal statement of why that fails.

Subscribe now

The practitioners who navigate complex environments well are not the ones with the most sophisticated control systems. They are the ones who have stopped asking how to simplify their management of complexity and started asking whether their management system is as varied as the complexity they are managing.

Systems thinking gave us the capacity to see relationships and feedback dynamics. Cynefin gave us the diagnostic framework to know when we have crossed into complex terrain. Complex adaptive systems theory gave us the vocabulary to understand why complex systems behave the way they do. Ashby’s Law gives us the structural principle for designing governance that can actually keep pace.

Together they form a progression that most practitioners never complete. The ones who do manage differently. Not with more control with better matched capacity.

I’m working through these frameworks in real time, applying them to real programs and real governance problems. If you are doing the same, I’d like to hear what you’re finding.

Nicole

Subscribe now

Share

Leave a comment

Systems thinking broke that open. It introduced feedback loops, nonlinearity, unintended consequences, and emergent behavior. It taught a generation of managers to see relationships, not just components. To ask not just what happened, but why the system produced that outcome. It gave us a vocabulary of stocks, flows, reinforcing loops, and balancing loops that made visible what linear thinking had been hiding.

But there is a class of problems where systems thinking, too, begins to strain. Where the map keeps failing to match the territory. Where understanding the feedback loops still doesn’t help you predict or manage what happens next.

For that terrain, there is a progression of three frameworks that most project managers have never encountered and that the best ones are quietly starting to use.

The Limit Systems Thinking Hits

Systems thinking assumes, at some level, that the system can be understood. That if you map it carefully enough the actors, the relationships, the feedback dynamics, you will have a model that gives you useful leverage.

Share

This assumption holds in complicated environments. A complicated system has many parts and many interactions, but those parts follow rules that don’t change as you observe them. A well-mapped complicated system yields to analysis.

A complex system is different in a precise way: the agents inside it adapt. They learn. They respond to your interventions by changing their behavior. The rules of the system evolve as the system runs. This means no static map however carefully drawn fully captures what is happening, because the act of mapping is already changing the territory.

This is not a failure of systems thinking. It is the boundary condition where a different set of tools becomes necessary.

The academic literature on complexity and project management has been building this case for some time. A 2018 review published in Wiley’s Hindawi Complexity journal found that as projects have grown more complex, traditional tools and techniques developed for simpler projects have been found to be inappropriate and that complexity contributes to project failure in ways that are real but not yet fully characterized. The implication is not that PM tools are bad. It is that they were designed for a different class of problem than the one many practitioners are now facing.

Share

The First Extension: Cynefin

The most immediately useful framework for project managers working beyond the systems thinking boundary is Cynefin, developed by Dave Snowden at IBM in the late 1990s and refined over the two decades since.

Cynefin is not a replacement for systems thinking. It is a decision framework for knowing which mode of thinking the situation actually calls for. It distinguishes five domains. Two are relevant here.

The **Complicated** domain is where systems thinking excels. There are right answers, but finding them requires expertise and analysis. You can model the system, run analysis, and develop a plan that will hold. Good systems thinking is the right tool.

The **Complex** domain is where systems thinking starts to slip. There are no right answers in advance, only answers that emerge from the system as it runs. Cause and effect are only visible in retrospect. You cannot analyze your way to a safe plan because the system will adapt.

Share

The Second Extension: Complex Adaptive Systems

Cynefin tells you what to do differently in complex terrain. Complex Adaptive Systems (CAS) theory, developed primarily at the Santa Fe Institute beginning in the 1980s, tells you why.

CAS theory studies systems composed of agents that interact, learn, and adapt and it identifies properties that emerge reliably from those interactions, regardless of the specific agents involved.

Share

Three properties are most consequential for project managers.

Emergence. In a CAS, system-level behavior arises from agent interactions in ways that cannot be predicted from understanding any individual agent. The traffic jam is not in any individual car. The organizational culture is not in any individual employee. The project dynamic is not in any individual stakeholder. Emergent properties are real, consequential, and invisible to analysis focused at the wrong level.

Nonlinearity. Small inputs can produce large outputs; large inputs can produce small ones. The relationship between cause and effect is not proportional. This is why complex projects regularly produce outcomes that feel wildly disproportionate to their apparent causes, a single conversation that changes the trajectory of a multi-year program, or a massive intervention that produces almost no change at all.

Co-evolution. Agents in a CAS do not just respond to the environment. They change the environment, which changes the other agents, which changes the environment again. In organizational terms: you are not managing a system from the outside. You are an agent inside it. Your interventions become part of the system’s inputs. This is the feedback loop that systems thinking introduced, but CAS theory makes explicit that you, the manager, are inside it too.

Share

The practical implication is uncomfortable: in a complex adaptive system, prediction is structurally limited. Not because you lack information, but because the system’s behavior is genuinely underdetermined until it unfolds. The appropriate response is not better forecasting. It is better sensing, building the organizational capacity to detect what is actually happening and respond faster than the system changes.

The vocabulary CAS adds: emergence, nonlinearity, co-evolution, agent-based dynamics. Fitness landscapes. Attractors. Sensitivity to initial conditions.

The Third Extension: Ashby’s Law

The deepest of the three frameworks is also the oldest. W. Ross Ashby formulated the Law of Requisite Variety in 1956, as part of the foundational work in cybernetics that preceded both systems thinking and CAS theory.

The law states: only variety can absorb variety.

In plain terms: a controller can only manage a system if the controller has at least as many available responses as the system has possible states. If the system is more complex than the controller, the controller will be overwhelmed. Regulation fails not because of bad intentions or insufficient effort, but because of a structural mismatch in complexity.

For project managers, Ashby’s Law reframes a question that most organizations get wrong by default.

Share

The standard response to a complex, high-uncertainty project is to add more governance: more reporting requirements, more approval gates, more oversight layers. The intuition is that more control produces better outcomes. Ashby’s Law says the opposite: if the governance structure is simpler than the system being governed, adding more of the same governance does not increase control. It increases friction while leaving the fundamental mismatch unresolved.

What requisite variety actually requires is governance that can match the complexity of the governed system. In practice, this means distributed decision-making authority, teams with genuine autonomy to respond to local conditions, and tolerance for approaches that differ from the original plan. It means designing the management system to be as varied as the problem system not as streamlined and standardized as possible.

This is a direct challenge to how most bureaucratic and federal project governance is structured. And it is why well-governed complex projects often look, from the outside, like they are “out of control” because they are exercising the variety the situation actually requires.

The vocabulary Ashby adds: requisite variety, regulatory capacity, complexity matching. The principle that governance must be as complex as what it governs.

Share

A Progression, Not a Replacement

These three frameworks do not replace systems thinking. They extend it.

Systems thinking gives you the capacity to see relationships and feedback dynamics in complicated environments. Cynefin gives you the diagnostic framework to know when you have crossed into complex terrain and need a different approach. CAS theory gives you the conceptual vocabulary to understand why complex systems behave the way they do. Ashby’s Law gives you the structural principle for designing governance that can actually keep pace.

Together, they form a progression from mapping to navigating. From understanding systems to operating inside them. From managing plans to managing adaptive responses.

Most project managers operate exclusively with tools designed for the complicated domain. That was sufficient when most project work was complicated. It is increasingly insufficient now as projects grow larger, more cross-functional, more politically entangled, and more technically uncertain.

The practitioners who will lead the next generation of complex program work are not the ones with the most sophisticated Gantt charts. They are the ones who understand which kind of problem they are actually facing and who have the vocabulary, and the frameworks, to manage it honestly.

Systems thinking was the right upgrade for its moment. Combining them is next level. I’m just starting this journal of deeply learning and applying these levels.

Nicole

Subscribe now

Share

Leave a comment

It comes from Donella Meadows. Her 1997 essay “Leverage Points: Places to Intervene in a System” is the companion text to Senge’s work that most practitioners haven’t read yet. If The Fifth Discipline teaches you to see systems, Meadows tells you where to push.

Her central observation is blunt: people instinctively know where the leverage points in a system are. And they almost always push in the wrong direction.

This piece walks through her full hierarchy of twelve leverage points translated into the organizational and program management context. The list runs from weakest to strongest. The counterintuitive move is to read it that way: starting with where most of your energy currently goes, and working toward where it would produce the most change.

The Hierarchy: Weakest to Strongest

12. Numbers: constants, parameters, targets

This is where roughly 95% of management attention goes. Budget figures. Headcount. Timeline milestones. KPI targets. Velocity metrics. Meadows is direct about this tier: adjusting numbers almost never changes system behavior. If the underlying feedback structure is intact, the system will route around your parameter changes and return to its prior state.

The clearest organizational example is the annual performance target reset. Numbers go up. The structure that produced last year’s outcomes hasn’t changed. Outcomes drift back. Next year, the numbers go up again.

Parameters become leverage points only in one narrow circumstance: when changing them pushes the system across a structural threshold a tipping point where a different feedback loop kicks in. Short of that, they are the most politically tractable and least effective intervention available.

Share

11. Buffer sizes: the stabilizing stocks

Buffers are the reserves that absorb shocks: cash reserves, inventory depth, staff slack capacity, processing time margins. Increasing buffer size makes a system more stable but less responsive. Decreasing it increases efficiency but reduces resilience.

In program management, this shows up as the chronic tension between resource optimization and adaptive capacity. Fully utilized teams have no buffer. They deliver at peak throughput under normal conditions and fail catastrophically under disruption because there is nowhere for the shock to go. The COVID-era supply chain collapse was a textbook buffer failure: decades of just-in-time optimization had removed every stabilizing reserve from the system.

Buffer changes can be meaningful leverage, but they are expensive. Physical and organizational buffers are hard to build and politically difficult to maintain against efficiency pressure.

10. Stock-and-flow structure: the physical architecture

This is the actual layout of the system: who reports to whom, what the workflow sequence is, where information originates and where it terminates, how resources move through the organization. Org charts. Process maps. Data pipelines.

Structural redesign is high-effort, slow to implement, and genuinely impactful, but often not as impactful as the effort invested suggests. The reason: if the information flows, rules, and goals of the system haven’t changed, the new structure will gradually adapt to replicate the old behaviors. You’ve seen this. A reorganization produces a new org chart and, within eighteen months, informal networks have reconstituted the old power dynamics in the new boxes.

Structure determines what’s possible. It rarely determines what happens.

Share

9. Delays: the time lags in feedback loops

This is one of the most underestimated leverage points in the hierarchy. Delays are the gaps between an action and its feedback: the time between a decision and its consequences, between a resource investment and its impact, between a performance signal and the management response it triggers.

Meadows is pointed here: delays that are too long relative to the rate of change in a system are a major source of instability. A slow feedback loop in a fast-moving environment produces oscillation, overcorrection followed by undercorrection, repeated indefinitely, because the system is always responding to outdated information.

In program contexts: the time between a team raising a dependency risk and that risk reaching a governance decision is a delay. The gap between a program’s execution and its retrospective review is a delay. The lag between an architectural decision and its downstream consequences is a delay. Shortening critical delays, not all delays, but the ones governing important feedback loops is genuine leverage. This is one of the few places where process improvement actually changes system behavior, because you are changing the information the system is operating on.

8. Negative feedback loops: the corrective mechanisms

Negative feedback loops are the self-correcting mechanisms that keep systems stable. A thermostat is the classic example: temperature deviates from the goal; the system detects the deviation; it applies a corrective force; the deviation closes.

In organizations, negative feedback loops are the quality checkpoints, the risk escalation processes, the budget variance reviews, the retrospectives, anything that detects deviation from intended behavior and triggers correction.

The leverage question is: how strong are they, and are they correctly calibrated? Weak negative feedback where the corrective signal is too small or too slow to actually close the gap, produces systems that drift persistently from their intended state while technically having “oversight” in place. This is the audit theater problem. The review exists. It produces findings. Nothing changes. The feedback loop is structurally present but functionally impotent.

Strengthening negative feedback loops means ensuring the signal is timely, the consequence is real, and the corrective mechanism is proportionate to the gap. That’s more structural than procedural and it requires asking who actually sees what information when, and whether acting on that information is institutionally rewarded or punished.

Share

7. Positive feedback loops: the amplifying drivers

Positive feedback loops accelerate whatever they are attached to, in either direction. They are the engine of growth, and of collapse. Network effects, compound learning, reputation cycles, technical debt accumulation all are reinforcing loops.

Meadows’ advice for positive feedback is counterintuitive: in most cases, it is better to slow down a runaway positive loop than to accelerate a corrective negative one. The reason is stability. Accelerating a positive loop in one domain often overwhelms balancing mechanisms elsewhere, creating cascading instability.

In program terms: the reinforcing loop between team capability and delivery quality is worth accelerating. The reinforcing loop between scope creep and schedule pressure is worth interrupting. The skill is distinguishing which positive loops are generating value and which are generating fragility and intervening accordingly. Most programs manage neither consciously.

6. Information flows: who knows what, when

This is where the hierarchy starts to bite. Meadows is emphatic that missing or delayed information is one of the most powerful causes of system malfunction and one of the most tractable to fix.

The organizational application is specific: who has access to what information, and when? Not in the abstract sense of “we have dashboards,” but in the functional sense of whether the people making decisions are operating on current, accurate, complete information about the state of the system they’re managing.

The classic failure pattern is a reporting structure that filters information upward through successive layers of interpretation and summary, each layer removing signal in favor of a coherent narrative until leadership is making decisions based on a representation of the system that no longer corresponds to its actual state. The information gap is not a communication failure. It is a structural feature of how information flows are designed.

Redesigning information flows, not just improving reporting, but changing who gets what directly is often faster and cheaper to implement than structural reorganization, and more durably effective. This is why transparency norms, direct access to production metrics, and open retrospectives function as leverage: they change the information structure.

Share

5. Rules: incentives, constraints, punishments

Rules are the formal and informal operating conditions of the system: what is rewarded, what is punished, what is permitted, what is prohibited. They include procurement regulations, performance incentive structures, promotion criteria, budget appropriation rules, HR policies, and the informal norms that everyone knows but nobody writes down.

Rules shape behavior more powerfully than most interventions at levels 12 through 7 because they operate on motivation, not just mechanics. Change a rule and you change what rational actors in the system are optimizing for.

The most important thing Meadows says about rules: pay attention to who has the power to make and change them. The entity that sets the rules is in a structurally different position from all the entities subject to them. In program governance, this distinction matters: the team executing inside a rule set has severely constrained leverage. The entity that can change the rules has disproportionate leverage. One of the most common mistakes in change management is deploying execution-level effort against a rules-level problem.

4. Self-organization: the power to change structure

This is the system’s capacity to evolve its own structure in response to changed conditions: to create new feedback loops, develop new rules, reorganize itself. In biological systems it is evolution. In organizations it is the capacity for genuine structural adaptation, not reorganization imposed from outside, but the system developing new configurations from within.

Most organizations actively suppress this capacity in the name of control. Standard processes, rigid approval chains, and change management overhead all reduce the system’s ability to self-organize in response to signals it is receiving. The cost of that suppression is resilience: a system that cannot reorganize itself can only be reorganized by external intervention, which is slower, more expensive, and usually incomplete.

The leverage question here is whether your program or organizational structure gives teams the actual authority to change how they work, not just the permission to suggest it.

3. Goals: the purpose the system is organized to achieve

This is where the hierarchy becomes genuinely uncomfortable. Goals are the objectives the system’s feedback loops are structured to pursue. Not the stated objectives. The operative ones — the targets the system’s actual behavior reveals it to be optimizing for.

Meadows’ key insight: a system will behave consistently with its operative goal regardless of what any actor within it intends. If a program’s operative goal is budget preservation rather than mission delivery as revealed by where resources actually go under pressure, then all the feedback loops, rules, and oversight mechanisms will function to protect the budget, even when participants believe they are pursuing the mission.

The distance between stated and operative goals is one of the most powerful diagnostics available to a program manager. You find it not by asking what the program is for, but by watching what the system protects when it is under pressure. What gets cut last? What triggers the strongest institutional resistance? What is the actual constraint that no intervention has ever successfully moved? That is the operative goal.

Changing operative goals requires naming the gap between stated and actual, which is why this tier generates the most organizational resistance. It is not a technical intervention. It is a political one.

2. Paradigms: the shared assumptions the system is built on

Paradigms are the unstated beliefs that generate goals, rules, and information structures. They are the water the system swims in: so foundational that they are rarely examined and almost never named.

In organizational contexts, paradigms include beliefs like: projects succeed or fail based on execution quality; uncertainty is a planning failure; experts have the answers; more process produces more control; efficiency and resilience are tradeoffs. These are not policies. They are assumptions so deeply held that alternatives are often not considered legitimate.

The leverage here is enormous and so is the resistance. Paradigm challenges are the interventions that produce the strongest institutional antibody response, because they threaten not just specific behaviors but the framework of legitimacy within which all behaviors are evaluated. This is why genuinely transformative organizational change is rare, slow, and painful: it requires shifting the paradigm before the new structures and rules can take hold, but the existing paradigm controls the process by which changes are evaluated.

Meadows’ method for paradigm intervention: consistently and patiently pointing to the anomalies and failures that the current paradigm cannot explain, to people who are open to examining their assumptions. Not argument. Accumulation of evidence that the existing frame no longer accounts for what is actually happening.

Share

1. Transcending paradigms: holding all frameworks lightly

The highest leverage point is the capacity to step outside any particular paradigm and recognize it as a lens rather than a truth — to see the entire hierarchy of leverage points as itself a construct, useful and limited, rather than a complete description of reality.

This is not relativism. It is a different cognitive posture: the ability to use frameworks instrumentally, to switch between them as conditions require, and to remain genuinely open to evidence that your current model of a situation is wrong. It is what Senge, in a different vocabulary, calls the discipline of mental models.

In practice, it looks like a PM who can hold their project methodology and their stakeholder model simultaneously as partial representations of a more complex reality and who can release either one when it stops producing useful signal. This is rare. Organizations actively select against it, because it is less legible than confident expertise and harder to evaluate than credentialed competence.

What This Means for Where You’re Spending Your Time

The reason to work through this hierarchy is not academic. It is diagnostic.

Most of the management tools available to you such as dashboards, status reports, milestone tracking, resource leveling, risk registers, operate at levels 12 through 9. They are parameter adjustments, buffer monitoring, flow tracking, and delay measurement. They are necessary and insufficient.

Share

Most change management and process improvement work operates at levels 9 through 6. Occasionally at 5. This is where most organizational “transformation” programs live, and why they produce temporary change that reverts when the intervention pressure is removed: the rules, goals, and paradigms that generate the behavior were never touched.

The levels where durable change actually happens in 6 through 2 are largely inaccessible to standard PM toolkits. They require different interventions: naming information gaps structurally rather than procedurally, identifying operative goals rather than stated ones, surfacing the paradigm assumptions that are generating the problems you keep solving.

This is not an argument for abandoning the tools you have. It is an argument for knowing which tier you are intervening at, and having honest expectations about what that tier can and cannot move.

Meadows closes her essay with a warning worth carrying: the higher the leverage point, the more the system will resist changing it. The reason programs keep producing the same outcomes despite repeated interventions is often not poor execution. It is that the interventions are operating at the wrong level of the hierarchy; visible, tractable, and insufficient.

The question is which tier you are actually working on.

Nicole

Further readings:

Leverage Points: Places to Intervene in a System”, Donella Meadows (1997, freely available at donellameadows.org)

Thinking in Systems: A Primer, Donella Meadows (2008)

Subscribe now

Share

Leave a comment

It’s worth reading in full. The framework she builds around the Jevons paradox is one of the cleaner pieces of economic thinking applied to the current moment. But it stops short of naming the structural property that determines which category you fall into.

That property is how you think. Specifically, whether you think in systems.

The Framework, Briefly

Lowrey’s argument turns on a 19th-century insight from economist William Stanley Jevons. When steam engines became more efficient, economists expected demand for coal to fall. Instead, efficiency drove down the cost of production, which expanded industrial activity, which consumed more coal than before. Making a resource cheaper to use increases total demand for it. That’s the Jevons paradox.

Share

She applies this to labor. Some workers are coal: AI makes their function cheaper and more accessible, which expands total demand for what they do. Software engineers are her primary example; employment is up 6 percent year over year, in part because companies need people to develop and implement AI products. Radiologists are another: when AI improved medical imaging, it didn’t replace them. It unlocked new use cases for CT and MRI scans, and radiologists were the ones administering and interpreting more of them.

Horses are the other category. When tractors replaced draft animals, demand for horses didn’t expand. It collapsed. The function was substituted entirely, with no Jevons rebound.

Lowrey is careful to note that AI will affect different workers differently, and that the same person can be coal in one context and horse in another. What she doesn’t give you is a diagnostic. She shows you examples but doesn’t tell you what the coal roles have in common.

What the Coal Roles Share

Look at the roles Lowrey identifies as coal or coal-adjacent: software engineers figuring out how to implement AI systems and radiologists interpreting expanded imaging volumes.

None of them are operating in environments that behave predictably.

Share

This is the distinction that matters: complicated versus complex. A complicated system has many parts, but those parts follow rules. You can model it, optimize it, hand it to an algorithm. AI is extraordinarily good at complicated. It synthesizes codifiable knowledge, executes repeatable processes, and finds patterns in large datasets faster and more reliably than any human.

A complex system is different. The parts interact in ways that produce emergent behavior. The rules shift as the system responds to interventions. The same action produces different outcomes depending on context, timing, and what else is happening simultaneously. You cannot fully model it in advance. You navigate it in real time.

Systems thinking is the cognitive practice of operating in complex environments. It’s not a methodology or a certification. It’s a way of seeing: feedback loops instead of linear cause-and-effect, dynamic relationships instead of static structures, emergence instead of predictable outputs. People who think this way do it whether or not they’ve read Meadows or Stacey or Snowden. And people who don’t think this way don’t do it just because they’ve taken a course.

This is why the coal/horse question is ultimately a question about cognition, not job title.

Share

Why Systems Thinkers Are Coal

Ashby’s Law of Requisite Variety states that a system can only be governed by a controller with at least as much variety as the system itself. It’s a formal way of saying that complexity requires a commensurate intelligence to navigate it.

AI increases variety in organizational and technical environments. It accelerates deployment cycles, creates new interdependencies, and generates emergent behavior that wasn’t present before. The environments that engineers, consultants, project/program managers, doctors, and designers operate in are getting more complex, not less, precisely because AI is making it cheaper and faster to build and deploy systems.

That is a direct Jevons dynamic. Cheaper tools expand the surface area of what gets built. Expanded surface area increases the complexity of what needs to be governed, integrated, and interpreted. Demand for the intelligence that can do that goes up.

Systems thinkers are the people positioned to meet that demand. Not because of their titles, but because of how they process environments that keep changing their own rules.

Share

The Honest Diagnostic

If you’re trying to locate yourself on the coal-horse spectrum, the question isn’t what your job is called. It’s how you actually work.

Some people, when they encounter a problem, look for the lever. They want to identify the variable, adjust it, and produce a known output. That’s excellent thinking for complicated problems. It’s also the thinking AI is rapidly absorbing.

Other people, when they encounter a problem, look for the system. They want to understand what’s producing the problem, what’s connected to it, what will shift if they intervene, and what unintended consequences might follow. They’re comfortable holding ambiguity while the picture clarifies. They change their model when the environment surprises them.

The second group isn’t smarter. They’re oriented differently. And that orientation is, right now, structurally valuable in a way that the first orientation is not.

Share

This doesn’t mean every engineer, consultant, interior designer, or doctor is coal. Lowrey is right that the same role can go either way. A software engineer who codes to spec inside a defined system is operating in complicated territory. A software engineer who is figuring out how an AI system will interact with an existing organizational environment, anticipating failure modes, and adapting as the system produces surprises is operating in complex territory. Same title. Different cognitive work. Different position on the spectrum.

The Risk Worth Naming

The threat to systems thinkers isn’t substitution. It’s misclassification.

Organizations under cost pressure tend to flatten roles toward their most measurable functions. If a program manager’s job gets reduced to status reporting and schedule tracking, those functions compress. If a consultant’s engagement gets scoped to deliverable production rather than diagnostic judgment, that compresses too. The systems thinking layer, the part that reads the environment, holds the whole, and navigates emergence gets treated as overhead rather than function.

That’s the scenario to watch for. Not AI doing your job, but your job being redefined until it no longer contains the work AI can’t do.

Share

The Caveat Lowrey Earns

She closes her piece with a sharp observation: coal itself eventually became horse. England, whose Industrial Revolution the Jevons paradox helped explain, now uses as much coal as it did in 1666. Technological succession is real.

Systems thinkers are coal right now. The Jevons dynamic is working in their favor. But the durability of that position depends on staying in the complex layer on doing work that requires genuine systems intelligence, not just work that happens to carry a prestigious title. The orientation protects you. The credential doesn’t.

Nicole

Read Annie Lowrey’s full piece in The Atlantic: How to Guess If Your Job Will Exist in Five Years

Subscribe now

Share

Leave a comment