When a systems thinker encounters a problem, the first thing he or she does is look for data, time graphs, the history of the system. That’s because long term behavior provides clues to the underlying system structure. And structure is the key to understanding not just what is happening, but why.

— Donella H. Meadows, Thinking in Systems

Every year, I introduce systems students to the iceberg model. The model is a helpful way of understanding situations by looking ‘beneath the surface’ of the things we experience, to the structures and mental models they manifest.

In case you’re unfamiliar with the iceberg model, it’s a framework that encourages you to think about situations at four levels:

  1. Events, or the tangible manifestations of the situation; the things we can see, hear, and record — “just the facts.”
  2. Patterns we perceive in events; outcomes that happen not just once but manifest time and again.
  3. Structures that may be causing the patterns we perceive; these could include rules, regulations, incentives, etc.
  4. Mental models that bring these structures into being.
Image via [ecochallenge.org](https://ecochallenge.org/iceberg-model/)

Image via ecochallenge.org

Notice the fourth level is more abstract than the first: we can ascertain events, but we must hypothesize mental models. There’s also a causal relationship between levels: mental models elicit structures that elicit patterns of events.

As a result, events are easier to grok than mental models. But as with pace layers, the deep levels are where the true power lies. A change at the level you can see has less impact than tweaking the mental models that bring it forth. The ability to change minds is an incredibly powerful lever.

The iceberg model is helpful when doing research. Research produces lots of data points: Google Analytics and search logs tell you about usage, landscape analyses tell you about competitors and analogs, user interviews tell you about intent, etc.

But research doesn’t stop with data. Insights only emerge once you spot patterns in data. If lots of people enter the same term into the search box and do not get good results, that tells you something important about your system.

But you can go deeper still. Patterns only tell you what is happening, not why. You should at least have a hypothesis about why things are happening. This calls for understanding the underlying structures and the mental models that enable them.

Collaborating on these levels can be uncomfortable since the work is speculative. Acknowledge the awkwardness upfront. Allow the team to speculate. You’re not making anything normative yet, just understanding why things might be happening.

Knowing causes helps produce better outcomes. You might not know causes precisely, but you can test hypotheses. Ultimately, a better understanding of the system’s structures and underlying mental models will lead to more skillful interventions.