Complete firstRecurring problemnot in catalog
The same phenomenon keeps recurring despite repeated quick fixes (at least three occurrences with a similar pattern).
Without: Without recurrence, the Iceberg Model remains academic; a 5-Whys is enough.
RunsheetSystems Thinking
Iceberg Model
ComplexityLow
Time30-60 min
Participants2-10
FormatWorkshop + async
MaturityEstablished
01
Prerequisite
What needs to be finished first
Complete firstTimeline of events
A timeline of previous occurrences with dates and context exists, so patterns are recognizable.
Without: Without a timeline, patterns are guessed instead of being evidenced and analysis stays anecdotal.
02
Preparation
What needs to be ready before start
Materials
Whiteboard or Miro board with four layers (Events at top, Patterns, Structures, Mental Models at bottom), four-color stickies, timeline attachment, observations and event data.
People / roles
One facilitator; 3-6 participants with system knowledge; one scribe; ideally people from multiple organizational levels (Operations, Lead, Strategy).
Pre-read
Three to five concrete occurrences with dates; previous measures and their outcomes; known incentives, rules, and beliefs in the system.
Time needed
90-150 min
Setup
Iceberg tip (Events) at the top, clear waterline. Patterns as first submerged layer, Structures as second, Mental Models as third. Rule: layers are filled one after another, not mixed.
03
Core question
The one question this method answers
Which patterns, structures, and mental models create the recurring events, and on which layer is an intervention sustainable?
04
Flow
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Collect events | 20 min | List concrete events from the last 12 months: date, what happened, immediate reaction. At least three comparable occurrences. | If only one event exists, Iceberg is not suitable. With two events, check for additional evidence first or choose another method. |
2Phase 2: Identify patterns | 30 min | Patterns as recurring behavior over time. Ask what repeats and what the trend statement is. Examples: "every quarter-end performance incidents escalate" or "new features break legacy functionality". | Patterns are generalizations, not single events. If a statement only describes one event, it is too specific. |
3Phase 3: Reveal structures | 40 min | Identify structures as incentives, processes, org setup, tool setup, rewards. Ask: which structure makes the pattern likely? Examples: bonus on output instead of outcome, missing QA stage, reporting lines. | Structures are changeable but hidden. A pattern without structure stays at symptom level. Make at least two structures explicit per pattern. |
4Phase 4: Reveal mental models | 30 min | Beliefs, assumptions, and cultural patterns that justify the structures. Examples: "speed beats quality", "market rewards only releases", "no time for tests". | Mental models are the most difficult layer. If the group avoids this level, Iceberg remains stuck in structures. Build psychological safety and focus on naming over blaming. |
5Phase 5: Levers and actions | 20 min | One action per layer: Event (quick fix), Pattern (pattern detection), Structure (change incentives), Mental Model (dialogue). Aim for at least one action at Structure or Mental Model level. | If all actions address events, the system does not learn. At least one action must change structure, otherwise the pattern will recur. |
05
Artifact
What comes out at the end
Form
Iceberg diagram as image plus supporting Markdown document with event list, pattern list, structure list, Mental-Models list, derived levers, and concrete actions by layer with owner and deadline.
Versioning / ownership
One document per analysis with date and phenomenon. Track actions separately so the Iceberg analysis remains comparable later. Link predecessor workshops.
Tool alternatives
- Miro or FigJam with Iceberg template
- Notion- or Confluence page with four sections
- Markdown in repo under docs/systems/iceberg/
- Lucidchart or draw.io with a custom Iceberg template
iceberg-model-working-template.md
Compact working template for Iceberg Model with context, input, output artifacts, and next step.
Iceberg Model Working Matrix
| Element | Description | Rating | Evidence | Owner | Next step |
|---|---|---|---|---|---|
| 1 | |||||
| 2 | |||||
| 3 |
Output artifacts
- Iceberg Worksheet:
- Pattern Notes:
- Intervention Ideas:
Decision or recommendation
What consequence follows from the matrix?
06
Example output
Concrete filled scenario, fictional example
iceberg-model-beispiel.md
Concrete filled scenario, fictional example
Iceberg Model - recurring quarter-end outages Workspot, May 2026
Events
- 31.03.2026: Outage 47 min at month-end close.
- 30.06.2025: Outage 1 h 12 min at month-end close.
- 31.12.2024: Outage 38 min at year-end close.
- 31.03.2025: Performance drop without full outage.
Patterns
- Month-end reporting peak overload burdens the database consistently.
- Post-incident hotfixes only treat symptoms, architecture stays unchanged.
Structures
- Reporting queries run on production DB without a read replica.
- Engineering backlog prioritizes feature work over platform resilience.
- Sales bonus is tied to month-end reporting, increasing reporting pressure at critical times.
Mental Models
- "Platform work does not pay off, customers pay for features."
- "A hotfix is cheaper than refactoring."
- "Outages are unavoidable."
Actions
- IB-01 (Structure): Build read replica for reporting. Owner: @marcus, by 31.07.
- IB-02 (Structure): Reserve 20% of sprint capacity for platform resilience. Owner: @julia (CTO).
- IB-03 (Mental Model): Run quarter-end workshop with Sales and Engineering on reporting load, Owner: @lisa, on 25.06.
- IB-04 (Event): Bring runbook to current state. Owner: @ben.
07
Pitfalls
Recognize symptoms and steer against them
Trap
Stop at event level
Symptom
Workshop produces only a hotfix plan, no structural change.
What to do
Do not skip phases 3 and 4. Force action matrix to include at least one lever at structure or mental model level.
Trap
Patterns too specific
Symptom
A pattern is phrased as "Outage on 31.03." rather than a recurring pattern.
What to do
A pattern should generalize across at least three events. If this is not possible, add more events or do not use Iceberg for this phenomenon.
Trap
Mental models become person criticism
Symptom
MM statements mention "X believes" instead of system assumptions.
What to do
Frame MM as shared assumptions. Use statements like "We believe that..." or "the system rewards..." and rephrase person statements.
Trap
No owner for structural actions
Symptom
Structures are identified but no one has a mandate to change them.
What to do
Run workshop only with people who have mandate or can escalate. Without escalation owner, Iceberg analysis remains without follow-through.
Trap
Judgment as diagnosis
Symptom
Structures or mental models are labeled as "wrong" and discussion drifts into blame.
What to do
Use diagnostic language, not judgmental labels. A structure is not "wrong"; it produces a pattern we currently do not want.
08
Stop criteria
Done signals checkable in under a minute
Only one or two events are known, so patterns cannot be derived.
No mandate exists for structural changes, so workshop has no follow-through.
Psychological safety for mental-model discussion is disrupted.
Event data is too fragmented, and pattern statements cannot be evidenced.
The phenomenon is acute and needs immediate response, deep diagnosis delays urgent action.
Workshop is compressed below 60 minutes, deep dive is not possible.
Finished the runsheet?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.