Identify the system before trying to change it

The misidentification problem

The most common failure mode in organizational change is not choosing the wrong intervention — it is intervening in the wrong system. A sales leader who redesigns the sales process to fix a revenue problem that is actually caused by a product-market fit issue is intervening in the wrong system. An operations leader who adds quality inspectors to fix a defect problem that is actually caused by supplier quality is intervening in the wrong system. A people leader who redesigns the performance review process to fix a retention problem that is actually caused by compensation inequity is intervening in the wrong system.

Donella Meadows, the systems scientist whose work on leverage points remains foundational, observed that the single most important skill in systems thinking is the ability to see the system accurately — to identify its boundaries, components, and connections before attempting to change any of them. "We can't optimize a part of the system at the expense of the whole system," she wrote. "But we routinely try, because we can see the part but not the whole" (Meadows, 2008).

The difficulty is not intellectual laziness. It is perceptual. Every person in an organization sees the system from their position within it — and from any single position, most of the system is invisible. The engineer sees the engineering system. The salesperson sees the sales system. The manager sees the management system. None of them sees the whole system — the interactions between engineering, sales, management, finance, legal, and operations that together produce the organizational outcomes.

The four-layer map

Effective system identification requires mapping the system at four layers, each revealing different aspects of how the system operates.

Layer 1: Boundaries

The boundary map defines what is inside the system and what is outside. This is the most consequential mapping decision because it determines what the change agent will see and what they will miss.

Draw the boundary too narrowly and you miss critical influences. A team that maps its "delivery system" as starting when a ticket enters the sprint and ending when code is deployed will miss the upstream system (how tickets are created, prioritized, and specified) and the downstream system (how deployed code is monitored, maintained, and iterated). The delivery system may be functioning perfectly while the upstream system produces poorly specified tickets that cause rework — but the narrow boundary makes the rework appear to be a delivery problem.

Draw the boundary too broadly and you cannot focus. A team that maps its "delivery system" as everything from customer research to post-deployment support will produce a map so complex that no intervention point is identifiable.

The pragmatic approach: start with the outcome you want to change and draw the boundary to include everything that influences that outcome. Then test the boundary by asking: "Is there anything outside this boundary that significantly affects the outcome inside it?" If yes, expand the boundary. If no, the boundary is adequate.

Layer 2: Components

The component map lists every element inside the boundary that participates in producing the outcome. Components include:

Actors — the people and teams who perform work, make decisions, and interact with each other. Include not just the primary actors but the secondary actors: the approvers, the reviewers, the gatekeepers, the support functions that enable or constrain the primary actors.

Processes — the sequences of activities through which work flows. Map the actual processes, not the documented ones. Peter Checkland's Soft Systems Methodology distinguishes between the "root definition" of a process (what it is supposed to do) and its "rich picture" (what it actually does, including workarounds, shortcuts, and informal procedures). The rich picture is the one that matters for system change (Checkland, 1981).

Decision points — the places where choices are made that affect the outcome. Who decides? Based on what information? Using what criteria? With what authority? Decision points are often the highest-leverage components because they directly determine the direction of work.

Resources — the budgets, tools, data, and time available to the actors. Resource constraints shape behavior as powerfully as incentives — when resources are scarce, actors optimize for survival rather than quality.

Layer 3: Connections

The connection map shows how components influence each other. Connections are the causal pathways through which the system operates — the mechanisms through which one component's behavior affects another's.

Information connections show how knowledge and data flow between components. Who tells whom what? How quickly does information travel? Where does information get filtered, distorted, or lost?

Authority connections show how decision rights flow. Who can direct whom? Who can approve or block? Where does authority concentrate, and where is it absent?

Incentive connections show how rewards and consequences flow. What does each actor gain or lose based on the outcome? Are the incentives aligned (everyone benefits from the same outcome) or misaligned (one actor benefits from an outcome that harms another)?

Material connections show how work products flow. What does each component produce that another component consumes? Where are the handoffs, and what happens at each handoff?

The connection map often reveals the most important insight: the connections that are missing. A product team that has no direct connection to customer feedback is making decisions without the information that would make those decisions good. A support team that has no connection to the engineering team that produces the bugs they fix cannot create pressure for quality improvement. Missing connections are invisible by definition — they can only be discovered by mapping what should be connected and noticing the gaps.

Layer 4: Dynamics

The dynamics map shows how the system behaves over time — the patterns that emerge from the interaction of components and connections.

Feedback loops are the most important dynamic pattern. Reinforcing loops amplify behavior: success breeds more success, failure breeds more failure. Balancing loops constrain behavior: as a variable grows, a force pushes it back toward equilibrium. Every persistent organizational pattern is maintained by at least one feedback loop — and changing the pattern requires identifying and modifying that loop.

Delays are the time gaps between cause and effect. When a manager makes a hiring decision, the effect on team performance is not visible for months. When a process change is implemented, the effect on outcomes may not appear for quarters. Delays make system behavior counterintuitive — by the time the effect is visible, the cause has been forgotten, and the organization may have already implemented a second change that interacts unpredictably with the first.

Accumulations are the places where things build up before being processed. A queue of customer tickets, a backlog of technical debt, a pipeline of pending decisions — accumulations create their own dynamics, producing pressure that shapes behavior in ways that are not visible from the flow diagram alone.

The formal-informal gap

Every organization has two systems: the formal system (what the org chart shows, what the process documents describe, what the policies mandate) and the informal system (how work actually gets done, who actually makes decisions, what actually gets rewarded).

The formal system is visible, documented, and usually wrong — not because it was designed poorly but because the organization has evolved since the formal system was documented, and no one has updated the documentation. The informal system is invisible, undocumented, and usually accurate — it is the living system that has adapted to the actual conditions of the organization.

System identification must map the informal system. This requires observation rather than documentation review — watching how work actually flows, asking people to describe their actual workflow (not their documented workflow), and tracing real decisions from initiation to resolution rather than reading the decision-making policy.

The gap between the formal and informal systems is itself diagnostic. Where the gap is large, the formal system is failing — the organization has worked around it because it does not serve its purpose. Where the gap is small, the formal system is working — the documented process is the actual process because it is well-designed.

The Third Brain

Your AI system can help you build system maps by synthesizing multiple perspectives. Describe the outcome you want to change and the components you can see from your position, and ask: "Help me map the system that produces this outcome. Given the components I have described, what additional components might I be missing? What connections between these components would explain the current outcome? What feedback loops might be maintaining the current pattern? Where are the likely delays between cause and effect? Generate questions I should ask people in different parts of the system to complete the map."

The AI can also help you validate a system map: "Here is my system map for [outcome]. Review it for completeness: Am I missing any significant components, connections, or dynamics? Are there interactions between components that I have not accounted for? What would I need to add to make this map accurately predict the current outcome?"

From identification to leverage

A complete system map is not the end of the diagnostic process — it is the beginning of the intervention design. The system map reveals dozens of components and connections, but not all of them are equally influential. Some are critical drivers of the outcome; others are peripheral. Some are changeable; others are fixed.

The next lesson, Leverage points in systems, examines leverage points — the places in a system where a small change produces a disproportionately large effect. Leverage points are the practical bridge between system identification (understanding the system) and system change (redesigning it).

---

Sources:

1. Meadows, D. H. (2008). Thinking in Systems: A Primer. Chelsea Green Publishing.
2. Checkland, P. (1981). Systems Thinking, Systems Practice. Wiley.