SYSTEMS THINKING

Examine interactions, shared dependencies, feedback loops, resource contention, incentives, and system-level causes. Keep the system boundary focused on interactions that materially explain the behavior or could change the decision; do not expand into an unlimited system map.

A Power Mode is an instruction pattern, not a feature of the AI. Nothing recognises the name — the wording underneath it does the work, and you can copy it from this page.

From the book. Chapter 13 / Part VII — SYSTEMS THINKING

What it actually does

Some problems are hard because they are not in one place. Five projects report five different reasons for delay, and five separate corrective actions follow.

SYSTEMS THINKING asks whether the causes connect: shared specialists, contended environments, a single overloaded approval group, scope arriving after development starts, teams protecting their own milestones by passing risk downstream.

The instruction directs attention to interactions, feedback loops, resource contention, and incentives rather than to each issue on its own — and asks the model to include only the interactions that materially help explain the behaviour, because any system can be drawn larger indefinitely.

When to use it

Use SYSTEMS THINKING when you see the same problem recurring across parts that are managed separately, and suspect the parts are interacting.

It is the primary mode for this job: change how the problem is framed.

When not to use it

This is the section worth reading. Using only what the work requires is the point; a mode applied to the wrong shape of problem costs you a worse answer than plain language would have given.

Use a different mode instead

FIRST PRINCIPLES fires when you suspect the question itself assumes the current approach, and want the problem rebuilt from what is actually required.
BACKCAST fires when you name a concrete success you want by a date, and ask what has to be true between now and then.
SECOND-ORDER THINKING fires when you accept what a change does immediately and want to know what it causes after that.
IMPACT PRIORITIZATION fires when you already have the list, and need to know which few items actually carry the outcome.

Use no mode at all

The problem is simple and isolated.
Expanding the system would add complexity without explanatory value.

There is no bonus for naming a mode when plain language is clearer. If you can already state the exact question, ask it.

Its failure mode

Expanding the system so broadly that the analysis loses focus.

Starter instruction

Paste this above your task. It is the whole mode — there is nothing else to switch on.

Examine this problem as a system. Look for interactions, shared dependencies, feedback loops, resource contention, incentives, and downstream effects rather than treating each issue independently. Focus only on interactions that materially help explain the behavior.

The same task, run both ways

Blind run. Separate sessions per arm, Temporary Chat, no memory, no tools attached. Neither prompt named a mode. No arm searched.

The task: Our mobile release has slipped in four of the last five cycles. - QA says builds arrive late and unstable, so they cut regression scope to hit the date - Engineering says QA files the serious bugs too late in the window to fix before the freeze - Product says scope is fixed by commitments made a quarter ahead - Support says the last two releases each caused a two-week spike in tickets - Every team hit its own quarterly targets last quarter Why does this keep happening, and what should we change?

Baseline — "Why does this keep happening, and what should we change?"

This keeps happening because the organization is **optimizing each function separately while the release succeeds or fails as one end-to-end system**.

[…]

For shared metrics, I'd use only a small handful. For example: release predictability, escaped defects/severity, change failure rate, time from code-complete to validated, and post-release support volume. Individual teams can still have operational metrics, but nobody should be considered fully successful if the release repeatedly creates customer problems.

SYSTEMS THINKING — "Look for interactions, shared dependencies, feedback loops, resource contention"

The scarce resource isn't simply "QA capacity." It's stable elapsed time between feature completion and release.

[…]

The highest-leverage metric may therefore be something surprisingly simple: the amount of stable-build time available before release. If that starts shrinking, it is an early warning that the whole reinforcing loop is activating. Ticket spikes and slipped dates are lagging indicators.

Both arms name the same disease. The difference is what they tell you to watch. The baseline’s five shared metrics — release predictability, escaped defects, change failure rate, time from code-complete to validated, post-release support volume — are all measured after a release has already gone wrong. The mode arm first names a different scarce thing than the one everyone is arguing about, then picks the one number that moves before anything breaks: stable-build time, with ticket spikes and slipped dates demoted to "lagging indicators".

The baseline is not weak here and the count of buzzwords is not the finding. It laid out a six-step cycle that feeds back on itself without ever using the word loop, refused to blame QA or Engineering, and reached the same central diagnosis of local optimisation with cross-team externalities. What it never does is ask which resource the teams are actually competing for, and its metrics are the ones that tell you afterwards.

Extracts are verbatim from 06_Test_Lab/Experiments/TL-026_SYSTEMS_THINKING_Raw_Outputs.md.

Related modes

Try it on your own work

Describe what you are actually doing and the Builder writes the full prompt — mode, context, output shape, and the verification step. It picks the mode from your description, which is why this link does not carry one.

Open the Prompt Builder →