2.4 Systems Thinking in Change

Systems thinking is the discipline of understanding the smaller interacting elements of a change rather than treating each part in isolation. CM3 places it in the context-setting section for a specific reason: it is how you identify intended and unintended consequences before they arrive.

The core idea

An organisation is not a collection of independent boxes on a chart. It is a set of elements — teams, processes, systems, incentives, relationships, informal workarounds — that interact. Change one element and the connected elements respond, whether or not you intended them to.

A worked example makes this concrete. A finance team introduces an automated three-day payment approval to reduce processing cost. The intended consequence is achieved. The unintended consequences ripple outward:

• Suppliers who previously chased the finance team by phone now have no human contact, so complaints route to account managers instead
• Account managers, whose targets do not include supplier queries, deprioritise them
• Two suppliers, unable to get answers, tighten credit terms
• Procurement's negotiating position weakens at the next renewal

Nothing in that chain was in the project scope. Every link is a real interaction between elements of the system, and a systems view would have exposed at least the first two before go-live.

Concepts that make systems thinking usable

Interconnection. Ask, for each part of the change, "what else touches this?" Not just which systems, but which people, incentives, informal arrangements and reporting lines.

Unintended consequences. These are not rare surprises; they are the normal output of intervening in a system you do not fully understand. CM3 treats them as an expected category, which is why unintended or unplanned change is one of the three formal categories in change impact assessment.

Feedback loops. Some effects reinforce themselves. If a change makes a team's work harder and their performance dips, and the dip attracts scrutiny that adds reporting burden, the loop amplifies. Recognising a reinforcing loop early is worth more than any amount of after-the-fact analysis.

Delay. Consequences frequently arrive long after the intervention. Because change teams typically disband at go-live, the delayed effects land on people who have no context for them and no mandate to fix them — which is one of the most common sources of the poor history of change that poisons the next initiative.

Putting systems thinking to work

In practice, three activities carry most of the value:

1. Map beyond the obvious boundary. Take the change's stated scope and deliberately identify three groups just outside it who interact with the affected process. In the payments example: suppliers, account managers, procurement.
2. Ask what currently absorbs the strain. Every process has informal shock absorbers — the experienced administrator who fixes exceptions, the phone call that unblocks things. Changes routinely remove these without noticing they existed, because they appear on no process map.
3. Ask what behaviour the change rewards. If a new metric makes one team's numbers depend on another team's speed, you have created an interaction whether or not you designed one.

Where it connects in the syllabus

Systems thinking is not an isolated model; it underpins several later topics:

The discipline it demands

Systems thinking is uncomfortable because it expands scope. Every ripple you identify is potentially more work, and there is real pressure to keep the boundary tight so the change stays deliverable. The professional answer is not to expand the change to cover every ripple, but to identify it, assess its severity, and make a conscious decision — accept it, mitigate it, or hand it to someone who owns it. An unintended consequence that has been named, assessed and consciously accepted is a managed risk. The same consequence unnoticed is a failure waiting to be discovered by someone else.

Drawing the map

Systems thinking becomes practical when it produces an actual picture. A workable method, usable in a single facilitated session:

1. Put the changed element in the centre — the process, system or role that the change directly alters.
2. Draw everything that feeds it — inputs, upstream teams, source systems, the people who supply information to it.
3. Draw everything it feeds — outputs, downstream teams, reports, decisions that depend on it.
4. Add the informal connections — the phone call that unblocks exceptions, the person everyone asks, the spreadsheet nobody owns. These almost never appear on process documentation and are frequently what the change removes.
5. Mark where effects will be delayed — month-end, quarter-end, annual cycles, and anything that only surfaces under peak load.

Step four produces the most value per minute spent, and it requires people who do the work rather than people who designed it. Step five matters because delayed effects arrive after the change team has moved on, and flagging them in advance is the difference between a known consequence and an unexplained problem attributed to the change months later.

The output is not a deliverable for governance; it is an input to the stakeholder list and the impact assessment.