Iceberg Model: Diagnosing Software Team Conflicts at the Root

Introduction

The author is reading Systems Thinking: Coping with Complex Problems in Software Development , which repeatedly references the iceberg model as a framework for analyzing problems in software development.

The Iceberg Model: Four Levels

The model visualizes problem analysis as an iceberg with four layers, each answering a different question:

Events (above water): Visible occurrences — "What happened? What did we see?" Examples: a production bug, a project delay. Most people react at this level, but patching events alone yields no lasting change.

Patterns and Trends (first underwater layer): Recurrence and direction — "Has this happened before? What is the trend?" Recognizing patterns enables anticipation.

Structure (deeper layer): The organizational, technical, social, and procedural arrangements that generate the patterns — "How are the patterns connected?" Structure produces behavior.

Mental Models (bottom layer): The beliefs and values that create the structures and patterns — "What assumptions underlie these structures?" Changing mental models is required for true system transformation.

Case Study: Two Technology Teams in Conflict

Event

Two technology teams refuse to collaborate on improving the relationship between their software modules; instead they fight for control. The visible symptom is a lack of cooperation and territorial disputes.

Patterns and Trends

Historically, the organization's hiring has long prioritized "technical-centered" skill stacks and never included questions such as "How do you think together with others to solve systemic challenges?" This pattern shaped the culture of the teams and the wider organization, making them poor at collaborative thinking from the start.

Structure

What systems and processes sustain this pattern? The article points to the industry-standard whiteboard interview . This practice tests knowledge stock — what a candidate currently knows — but cannot assess knowledge flow — how a person learns and adapts when the environment changes. Consequently, the team comprises people who do not value learning from others, and the organization has no structural reinforcement for that value.

Mental Models

The deep beliefs driving the structure and patterns include:

Experience with a specific technical tool predicts the quality of future knowledge work a candidate will deliver.

The best person for a technical solution must be able to improvise programming puzzles in an interview.

Communication and other "soft skills" are not a priority for software engineers ("that's the project manager's job").

People tend to blame poor leadership, lack of funding, technology choices, or the other team's incompetence, rarely realizing that their own thinking structures and hiring systems have led the teams into this situation.

Reflections

The iceberg model's primary purpose is to help people see through phenomena to essence, providing a thinking framework. The author notes that an engineer's technical height depends on cognitive height, and a company's future depends on its vision and values. Cognition is the way one thinks about problems — linear thinking versus systems thinking. Systems thinking emphasizes a global, multi-dimensional, multi-angle view. Everyone can use models to improve their cognitive ability.