RunsheetSystems Thinking

System Archetypes

ComplexityHigh

Time90-180 min

Participants3-10

FormatWorkshop

MaturityCanonical

Prerequisite

What needs to be finished first

Complete firstCausal Loop Diagram

Team understands loop notation and delays, ideally with first sketch of relevant dynamic.

Without: Without loop understanding, archetypes cannot be recognized and method stays superficial.

Complete firstIceberg Model

Team can look below observable events into patterns, structures and mental models.

Without: Without willingness for deeper analysis, archetype assignment remains label without consequence.

Preparation

What needs to be ready before start

Materials

Whiteboard or Miro board with archetype cards (Limits to Growth, Shifting the Burden, Tragedy of the Commons, Fixes that Fail, Success to the Successful, Drifting Goals, Escalation, Growth and Underinvestment); current observations or symptoms; Senge/Meadows reference; pens.

People / roles

One facilitator experienced in systems thinking; 3-10 participants with context on problem; scribe for levers and actions; optional coach for archetype deepening.

Pre-read

Current observations with data (for example trend charts); known past solution attempts with result; Iceberg Model analysis if available; archetype cards as pre-read.

Time needed

90-180 min

Setup

Archetype cards on wall with short loop sketch and example. Section for observations. Section for identified archetype. Section for levers and actions. Rule: check several archetypes, do not latch onto first.

Core question

The one question this method answers

Which archetype best explains recurring symptoms, and which levers are typical for this archetype?

Flow

Marker: Phase

Step	Duration	Action	Hint
1Phase 1: Formulate observations	20-30 min	List concrete recurring symptoms. Data or evidence per symptom. Past solution attempts and their effect. Goal: at least 5 observations with timeline.	Symptoms without data are anecdotal. Anyone without data is in speculation mode, not observation mode. First data, then archetype.
2Phase 2: Introduce archetype cards	20-30 min	Explain loop structure per archetype with example. Limits to Growth: growth creates own limit. Shifting the Burden: symptom solution weakens fundamental solution. Fixes that Fail: quick fix reinforces problem long-term. Etc.	Every archetype has characteristic loop structure. If you cannot draw loops, you did not understand archetype. Sketch per archetype on wall.
3Phase 3: Check possible archetypes	30-40 min	Compare observations with 2-3 archetype candidates. Per candidate check: do loops fit, do delays fit, does it explain past solution attempts.	Several archetypes are often active at once. Do not latch on early. Whoever chooses first plausible one often misses dominant one.
4Phase 4: Draw loops and delays	30-45 min	Draw chosen archetype explicitly for our case. Variables with real labels (for example "number of support tickets", "engineering capacity"). Mark delays.	Generic archetype becomes concrete diagram. Delays are often key: quick effect short-term, counterintuitive effect long-term.
5Phase 5: Levers and actions	30-45 min	Typical levers per archetype (for example Shifting the Burden: strengthen fundamental solution, do not scale symptom solution). Actions with owner and deadline.	Archetypes have textbook levers. If levers are ignored and symptom actions proposed instead, the archetype continues. Textbook levers as default.

Artifact

What comes out at the end

Form

Archetype assignment as diagram (concrete loop sketch for our case), lever list based on archetype theory, action plan with owner and deadline. Linked to Causal Loop Diagram or Iceberg analysis.

Versioning / ownership

New per diagnosis. When symptoms change, new analysis. Archive previous version. Observe lever effect over time, adapt diagram when learning.

Tool alternatives

Miro or FigJam with archetype templates
Lucidchart with loop diagrams
Kumu for interactive systems maps
Mermaid diagram in wiki (for simple loops)
Vensim or Stella for simulations (if needed)

system-archetypes-working-template.md

Compact working template for System Archetypes with context, input, output artifacts, and next step.

System Archetypes Working Template

Goal

Standard patterns of recurring system dynamics such as Limits to Growth.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Execution

Short notes along the runsheet.

Output artifacts

Archetype mapping:
Leverage list:

Assumptions and open questions

Decision / next step

Owner, date, and success signal.

Example output

Concrete filled scenario, fictional example

system-archetypes-beispiel.md

Concrete filled scenario, fictional example

System Archetypes - Recurring engineering bottlenecks, 2026-05-18

Observations

Despite 4 hiring waves in 2 years, backlog size stays constant at 180-220 open tickets.
On-call load does not decrease despite tool investments.
Senior engineers spend 60% time on mentoring/code review, less on system improvement.
Documentation state worsens quarterly despite documentation sprints.
Past solutions: hiring, tooling, process tightening. None with sustainable improvement.

Checked archetypes

Limits to Growth: Hiring brings growth, but engineering onboarding capacity limits. Plausible.
Shifting the Burden: Symptom solutions (hiring, tooling) displace fundamental solution (architecture simplification, docs). Strongly plausible.
Fixes that Fail: Hiring creates more complexity (more communication, more onboarding load), reinforcing problem long-term. Plausible as secondary loop.

Dominant archetype: Shifting the Burden

Loop sketch (simplified)

Symptom: bottleneck perception -> symptom solution: hiring -> short-term relief -> side effect: docs/architecture investment falls further behind -> fundamental solution (architecture simplification) weakens -> problem returns stronger.

Delays: Hiring works in 3-6 months, architecture decay acts over 2-3 years. Asymmetry makes symptom solution more attractive.

Textbook levers for Shifting the Burden

Strengthen fundamental solution (even if slower): enforce architecture sprint share at 30%.
Mark symptom solution explicitly as temporary: hiring only under condition of architecture investment.
Make delays visible: dashboards for architecture health (bus factor, docs coverage, cyclomatic complexity).

Actions

Architecture sprint share 30%: 1 of 3 sprints dedicated to architecture simplification. Owner: @julia, start Sprint 25.
Hiring coupling: For every 2 new engineers define 1 refactoring project beforehand. Owner: @julia with HR, start Q3.
Architecture health dashboard: Bus factor, docs coverage per service. Owner: @ben, by 2026-07-15.
Senior engineer protection: 30% time for system improvement, protected through OKR setting. Owner: @julia, Q3 OKR.

Non-actions (deliberately no levers)

More hiring without architecture investment (would reinforce loop).
Symptom solution "more tools" without addressing fundamental complexity.

What to do

Define effect indicators per lever. Quarterly review. If effect absent, re-check or reframe archetype. Learning is method core.

Stop criteria

Done signals checkable in under a minute

Team does not know loop notation and delays, archetypes would be incomprehensible.

No sufficient observations with data available, diagnosis would be speculation.

Symptoms are very new, delay effects not yet observable.

Workshop under 90 min, archetype checking and loop drawing impossible in time.

Pure linear processes, no feedback loop visible, archetype concept does not fit.

Sponsor expects fast action items without deep analysis, method would be disregarded.

Finished the runsheet?

Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.

Go to profile More methods