How to Use the Iceberg Model for Effective Root Cause Analysis

The Iceberg Model for Lasting Change

I often see leaders frustrated by recurring issues. Despite new policies, updated software, or team reshuffles, the same bottlenecks keep appearing. We tend to fix what we can see, but the most significant parts of our problems often hide beneath the surface.

It made me reflect: Are we actually solving the problem, or are we just reacting to the noise?

In systems thinking, we use the Iceberg Model to explain why “quick fixes” rarely stick. We spend most of our energy at the very tip, while the real drivers of change sit in the deep.

“Rather than reacting to individual problems that arise, a systems thinker will ask about relationships to other activities within the system, look for patterns over time, and seek root causes.” — Courage Egbude

Iceberg Model

When we look at a challenge through this lens, we see four distinct layers:

  • The Event (The Tip): The visible crisis. A missed deadline, a drop in quality, or a team conflict. We react here because it’s loud.
  • The Patterns (Below the Surface): The trends over time. Is this the third time this month a deadline was missed? Patterns show us that the event isn’t an accident; it’s a habit.
  • The System Structures: The rules, physical setups, and power dynamics that dictate how we work. People don’t miss deadlines because they are lazy; they miss them because the workflow is broken or the incentives are misaligned.
  • The Mental Models (The Base): The core beliefs and values that keep the system in place. This is the “why”. If the leadership believes “speed matters more than accuracy”, the system will naturally produce errors.

In order to create lasting change, organisations do not necessarily need more “action items” or stricter oversight. We need to shift the perspective from the surface to the structure.

Here are 3 ways to start looking deeper:

  1. Stop Reacting, Start Tracking. Before jumping to a fix, ask: How often has this happened? Identify the pattern before you identify the solution.
  2. Audit the Architecture. Look at the systems—the meetings, the software, the hierarchy—that allow the problem to exist. Most “people problems” are actually “system problems”.
  3. Challenge the “Why”. Have honest conversations about the underlying beliefs. What are we prioritising that is causing this outcome?

When we stop fighting the “tip” and start addressing the base, we stop putting out fires—and start building systems that actually work.

Do you find yourself reacting to the same “events” every week? It might be time to look below the waterline.