The iceberg model in systems thinking examines a problem at four levels: events, patterns, structures and mental models. Start with what happened, check whether it repeats, investigate the conditions that could produce it, and question the assumptions behind those conditions. Keep observations separate from explanations you have not tested.
Below, a fictional equipment-loan team investigates repeated handoff omissions. The completed analysis includes evidence gaps, competing explanations and a small test. It shows how to move beyond a frustrating incident without declaring that a diagram has discovered the root cause.
What the four levels mean
Ecochallenge's iceberg model presents these four levels as a way to look beneath visible events. The iceberg is a metaphor for attention: the immediately noticeable incident is only part of what you may need to examine. It is not a measured rule assigning a percentage of organizational problems to each layer.
| Level | Working question | Evidence to look for |
|---|---|---|
| Event | What happened on this occasion? | Time-stamped records and direct observations |
| Pattern | What changes or repeats across occasions? | Comparable observations over a defined period |
| Structure | Which arrangements may produce the pattern? | Rules, information flows, resources and incentives |
| Mental model | Which assumptions help maintain those arrangements? | Stated beliefs, decisions and explanations from participants |
A structure can include a form, a shift boundary or a requirement to get approval. It does not have to mean a formal organization chart. A mental model is an assumption about how things work, not a diagnosis of somebody's character.
You may move back and forth between levels. A proposed structural explanation might send you back to check records for a pattern you had assumed existed. That revision is useful analysis, even if the finished board looks less tidy.
The complete fictional case
A neighborhood center lends projectors and speakers. An evening volunteer hands the cupboard over to a morning volunteer. On one Tuesday, the morning volunteer promises a projector to a class, then discovers it is already reserved. The evening reservation never reached the shared handoff record.
Assume the team assembles the following invented practice material. These figures are teaching data, not a study of a real service:
| Observation over two weeks | Recorded result | What remains unknown |
|---|---|---|
| Handoffs reviewed | 10 | Whether these weeks were typical |
| Reservation omissions | 4 handoffs had at least one | Whether all omissions were detected |
| Shift overlap | 0 minutes on those 4 handoffs; 15 minutes on the other 6 | Whether overlap explains the difference |
| Where reservations arrived | Shared form, phone and personal messages | Counts and timing by channel |
| Editing access | Morning volunteer could edit; evening volunteers could only view the shared sheet | Whether everyone knew this restriction |
The coordinator also finds a written instruction: “Send changes to the morning lead.” In an interview, one evening volunteer says, “I thought the lead copied every message into the sheet.” Another says they sometimes used a personal message because the form was hard to open on a phone.
Already there are several possible explanations. Access restrictions, fragmented channels and lack of overlap could interact. The team should resist choosing one simply because it makes a clean story.
Level 1: Describe the event without adding blame
An event entry should be specific enough for another person to locate the same incident. For this case, write:
Tuesday's morning volunteer offered an already-reserved projector. The reservation was present in an evening message but absent from the shared handoff sheet at the morning check.
“Evening staff are careless” is not an event description. It turns one observation into a judgment about a group. “Communication failed” is also too vague: it hides which information existed, where it was and who could see it.
Record the immediate response separately. The center still needs to contact the affected class, find an alternative if possible and correct the reservation record. Systems thinking does not require delaying an urgent repair while the team completes a workshop.
Add an evidence label: record checked, person's recollection or not yet verified. If the exact time is unknown, say so. An explicit gap gives the next person a research task; an invented timestamp creates false confidence.
Level 2: Look for a pattern using a denominator
The practice data shows omissions in 4 of 10 reviewed handoffs. That is a more meaningful description than “four mistakes recently,” because readers know how many handoffs were examined. It still describes only the chosen two-week window.
The coincidence with zero overlap is worth investigating. It does not establish causation. Perhaps busy evenings both prevent overlap and create more reservations. Perhaps the morning lead handles a different mix of equipment on overlapping shifts. A small sample can make an accidental relationship look convincing.
Write the pattern layer this way:
In the ten reviewed handoffs, omissions were recorded on four. Those four had no scheduled overlap. We have not yet compared reservation volume, arrival time or channel across all ten.
A useful next table would show each handoff's total reservations, late changes, channels and detected omissions. Keep “no omission found” distinct from “confirmed complete.” If nobody checked one handoff, it should remain missing rather than being counted as successful.
A timeline can help place message arrival, shift end and sheet update on the same sequence. Use it to compare records, not to decorate a conclusion you already prefer.
Level 3: Inspect structures that could produce it
Now examine the arrangements around the work. The evening volunteers can receive a reservation but cannot enter it in the common record. Information must pass through a morning lead. Personal messages and calls create more places to check. Zero overlap removes one opportunity to catch an omission.
Those are inspectable conditions. The claim that one of them caused all four omissions is still a hypothesis. Keep the distinction visible:
| Structural hypothesis | Existing support | Next check |
|---|---|---|
| Restricted edit access creates a copying dependency | Access settings and written instruction | Trace who could update each missing reservation |
| Multiple channels hide changes from the next shift | Three arrival channels and interview accounts | Classify arrivals for every reviewed handoff |
| No overlap reduces chances to reconcile records | Association in this small practice sample | Compare similar-volume shifts; inspect other explanations |
Draw a short swimlane map if responsibilities are unclear. Put the borrower, evening volunteer and morning lead in separate lanes. Show where information moves and where somebody has to copy it. A step labeled “someone updates the sheet” is precisely the ambiguity worth exposing.
Avoid a familiar trap: replacing “careless people” with “bad process” without gathering better evidence. Either phrase can become a slogan that ends inquiry. Describe the rule, access setting or dependency that you can actually inspect.
Level 4: Investigate mental models respectfully
The volunteer's statement about the morning lead is direct evidence that one person held that assumption at the time of the interview. It is not evidence that everyone shared it. Likewise, using a personal message does not establish laziness or resistance to change.
Possible mental-model entries include:
- Stated: One volunteer believed the lead copied every message.
- To investigate: Does the coordinator assume view-only access is necessary for record accuracy?
- To investigate: Do volunteers treat a sent message as a completed handoff rather than requiring acknowledgment?
Ask neutral questions: “What tells you a reservation has been handed over?” “What happens if the lead is away?” “Why was this access rule introduced?” Participants may describe a valid constraint you did not know about, such as previous accidental deletions.
An assumption is worth examining when it influences a decision or behavior. Do not fill the bottom layer with abstract words such as “culture” or “mindset” and treat depth on the diagram as proof of importance. Some problems can be improved by a simple access change without a sweeping account of organizational beliefs.
Turn the model into a small, testable action
For this fictional case, the team could pilot one shared reservation-entry route for a week, with an agreed confirmation step and appropriately scoped editing permissions. Keep an agreed record owner and a way to recover mistaken edits. Ask the volunteers to check that the entry route works during an actual shift.
Define the test before seeing results:
| Test element | Working proposal |
|---|---|
| Change | One shared entry route; receiver confirms entries before the next pickup session |
| Owner | Center coordinator, with volunteers checking usability |
| Outcome | Handoffs with detected missing reservations divided by handoffs reviewed |
| Supporting observations | Reservation volume, late changes, channel exceptions and reconciliation time |
| Review | Compare the next week's records with the same definitions; extend if volume is too small |
| Protection | Preserve usable access and an exception route when the shared form is unavailable |
Do not claim a percentage improvement before running the test. If omissions fall but reconciliation time becomes unreasonable, that matters too. If the change does not help, return to the hypotheses rather than concluding that volunteers failed the model.
A first test often changes more than one thing for practical reasons. Record that limitation: you may learn that the package helps without knowing which individual component caused the improvement.
Iceberg model, fishbone or five whys?
Choose the tool according to the question. The iceberg model broadens attention across time, arrangements and assumptions. A fishbone diagram helps organize several candidate cause categories. Five whys follows an explanatory chain that must still be checked against evidence.
You can use them together without copying the same content into three diagrams. Start with an iceberg to notice the repeated pattern, use a process map to inspect the copying dependency, and investigate one unresolved hypothesis with a focused chain of questions.
The output should remain a bounded explanation and an action you can evaluate. A board with four beautifully filled layers but no evidence gaps, owner or next observation is unfinished analysis.
