Systems Thinking

Systems Thinking

Goal

Reframe a local problem as part of a wider system and identify the highest-leverage intervention point.

The job of this skill is not to make everything abstract. The job is to surface dependencies, loops, bottlenecks, and side effects so action targets the system, not just the symptom.

This skill maps interacting causes. It does not claim the mapped system is complete or validated unless evidence is explicitly provided.

Default Posture

• system before symptom
• interactions before isolated parts
• second-order effects before quick fixes
• leverage over activity
• bottleneck before optimization

When To Use

Run this skill when:

• fixing one part causes problems elsewhere
• the same issue keeps recurring
• local optimization does not improve overall outcomes
• there are strong dependencies, queues, loops, or delays
• the problem spans people, process, product, and tooling together

This is a strong next step after:

• triz when contradiction interacts with the wider system
• jtbd when the job is clear but the delivery system fails
• before prioritization when a local fix may create regressions

Scope Boundaries

In scope:

• identify system boundaries and actors
• map dependencies, flows, delays, and feedback loops
• detect bottlenecks and local-vs-global mismatches
• surface second-order effects
• recommend the highest-leverage next intervention

Out of scope by default:

• pretending the whole world is in scope
• drawing exhaustive system maps when a focused one is enough
• replacing contradiction solving better handled by triz
• replacing problem framing better handled by jtbd

Escalation Conditions

Pause and keep uncertainty explicit when:

• the system boundary cannot be named usefully
• no meaningful dependency or loop can be identified
• the map grows but no leverage point appears
• the problem is actually a local contradiction or weak framing issue

If the model remains too vague after one pass, recommend returning to jtbd, triz, or narrower validation work.

Systems Workflow

1. State the focal problem in operational terms.
2. Define the minimum useful system boundary.
3. Identify the main actors, components, queues, or flows.
4. Map key dependencies and delays.
5. Identify reinforcing and balancing loops if they matter.
6. Find the current bottleneck or leverage point.
7. Name likely second-order effects of naive fixes.
8. Recommend the smallest high-leverage intervention and the next validation step.

Core Questions

Use the minimum set needed:

• What system is this problem part of?
• What are the most important dependencies or flows?
• Where does work, attention, or value accumulate or stall?
• What local fix could worsen the system?
• What loop is reinforcing the current outcome?
• Where is the highest-leverage point for change?

Output Contract

Always return:

1. focal_problem
2. system_boundary
3. key_components
4. critical_dependencies
5. feedback_loops
6. bottleneck_or_leverage_point
7. second_order_effects
8. evidence_status (provided, inferred, mixed)
9. open_unknowns
10. recommended_followup (systems-thinking, jtbd, triz, selector, validation)
11. next_intervention

Good Systems Signals

Strong signals:

• the same issue repeats despite fixes
• multiple parts interact to produce the outcome
• a queue, delay, or dependency is visible
• local success does not equal system success

Weak signals:

• the issue is contained to one isolated component
• the problem is still undefined
• there is a direct contradiction that should be handled first
• system mapping adds complexity without new insight

Guardrails

• Do not expand the system boundary without purpose.
• Do not confuse "many factors" with a real system model.
• Do not skip bottleneck identification.
• Distinguish evidence from inference.
• If the problem is really framing or contradiction, recommend jtbd or triz.
• Prefer one useful leverage point over a giant map with no action.
• If no leverage point emerges, say so instead of inflating the system description.

Anti-Patterns

Watch for these failure modes:

• system-map theater
• naming many components but no meaningful interactions
• treating every issue as systemic
• optimizing around the bottleneck instead of addressing it
• describing loops without any practical intervention
• expanding scope until action disappears

Example

User request:

Support tickets keep rising even though we keep shipping fixes.

Expected shape of response:

1. focal_problem: support volume rises despite ongoing product fixes
2. system_boundary: support intake, product defects, release process, docs, onboarding, feedback triage
3. key_components: users, support team, product team, release pipeline, help docs, onboarding flows
4. critical_dependencies: ticket data to prioritization, release timing to incident load, docs quality to self-service resolution
5. feedback_loops: more tickets reduce support bandwidth, weaker triage delays fixes, delayed fixes create more tickets
6. bottleneck_or_leverage_point: weak issue categorization and delayed root-cause routing between support and product
7. second_order_effects: shipping more low-confidence fixes may increase regressions and documentation drift
8. evidence_status: inferred
9. open_unknowns: which ticket categories dominate, where re-open rates cluster, how release timing correlates with spikes
10. recommended_followup: validation
11. next_intervention: instrument ticket categories and route the highest-volume class through a tighter support-to-product feedback loop