Systems Thinking
See the Whole, Not Just the Parts
The skill that stops you from fixing the same problems over and over. Instead of treating symptoms, find the structures that create them.
You can’t understand a system by looking at its parts in isolation. You have to see the connections, the delays, the feedback loops. That’s where the leverage is.
Why Fixing Symptoms Never Works
Most organizations operate in reaction mode. Something breaks, someone patches it. Deadlines slip, so you add more people. Customer complaints spike, so you retrain the support team. These interventions feel productive, but they rarely last.
I have watched this pattern play out in every type of team I have worked with: engineering, hospitality, consulting. The symptoms keep returning because the underlying structure that produces them is untouched. Systems thinking is the discipline of seeing that structure.
It is not a framework you install or a workshop you attend once. It is a way of seeing: understanding that every problem is connected to other problems, every solution has side effects, and the most effective interventions are rarely the most obvious ones.
The Iceberg Model
Most people only see events. Systems thinkers look deeper: at the patterns, structures, and mental models that produce those events.
Events
The visible tip. What happened? A deadline was missed. A customer complained. A deploy broke production. These are the events that trigger reactions.
Most organizations spend all their energy here: responding to events as they surface. It feels productive, but it is reactive by definition.
Patterns
Just below the surface. What trends are emerging? Deadlines always slip in Q4. The same type of bugs keep appearing. Customer complaints cluster around the same feature.
Seeing patterns is the first step beyond reaction. When you notice the same event recurring, you start asking better questions about why.
Structures
The systems and rules that drive patterns. How is work organized? What incentives exist? Which feedback loops are missing? Structures include org charts, release processes, communication channels, and decision authority.
This is where most leverage lives. Change the structure, and the patterns change with it. But structures are invisible unless you deliberately look for them.
Mental Models
The deepest layer. What beliefs and assumptions shaped the structures? “Developers work best alone.” “More features equals more value.” “Speed is more important than quality.”
Mental models are the hardest to change, but they have the highest leverage. Shift the belief, and the entire system shifts with it.
Events
The visible tip. What happened? A deadline was missed. A customer complained. A deploy broke production. These are the events that trigger reactions.
Most organizations spend all their energy here: responding to events as they surface. It feels productive, but it is reactive by definition.
Patterns
Just below the surface. What trends are emerging? Deadlines always slip in Q4. The same type of bugs keep appearing. Customer complaints cluster around the same feature.
Seeing patterns is the first step beyond reaction. When you notice the same event recurring, you start asking better questions about why.
Structures
The systems and rules that drive patterns. How is work organized? What incentives exist? Which feedback loops are missing? Structures include org charts, release processes, communication channels, and decision authority.
This is where most leverage lives. Change the structure, and the patterns change with it. But structures are invisible unless you deliberately look for them.
Mental Models
The deepest layer. What beliefs and assumptions shaped the structures? “Developers work best alone.” “More features equals more value.” “Speed is more important than quality.”
Mental models are the hardest to change, but they have the highest leverage. Shift the belief, and the entire system shifts with it.
Feedback Loops
Systems run on feedback. Understanding which loops reinforce behavior and which ones balance it is the key to predicting how a system will respond to change.
Reinforcing Loops
Growth or decline that feeds on itself. Success breeds success; failure breeds failure. The rich get richer. Technical debt compounds.
“The more we ship without tests, the more bugs we create, the more time we spend firefighting, the less time we have for tests...”
Balancing Loops
Self-correcting mechanisms that push toward equilibrium. Thermostats. Sprint retrospectives. Market corrections. They resist change and maintain stability.
“When the team is overloaded, they push back on new requests, which naturally reduces the workload back to a sustainable level.”
Finding Leverage Points
The most obvious intervention is rarely the most effective. Leverage points are the places in a system where a small change produces a disproportionately large effect.
1. See the Symptom
Start with what is visible. Deploys keep breaking. The team is frustrated. Customer satisfaction scores are dropping. This is the presenting problem, and it is where most interventions stop.
Resist the urge to fix it directly. Instead, ask: what is connected to this?
2. Trace Upstream
Follow the connections. Why do deploys break? Because testing is insufficient. Why is testing insufficient? Because the team is under constant deadline pressure. Why the pressure? Because scope is never negotiated.
Each “why” reveals a new node in the system. The connections between nodes are just as important as the nodes themselves.
3. Find the Leverage Point
Look for nodes with many connections. A single change here ripples through the entire system. In our example, the scope negotiation process sits upstream of deadlines, testing, deploy quality, and team morale.
Changing how scope is agreed upon is a higher-leverage intervention than adding more test automation or hiring more engineers.
4. Design the Intervention
Once you have identified the leverage point, design a small, targeted change. Introduce a simple scope check at the start of each sprint. Make trade-offs visible. Give the team a voice in what is realistic.
Small structural changes, applied at the right point, are more powerful than large initiatives applied at the wrong one.
1. See the Symptom
Start with what is visible. Deploys keep breaking. The team is frustrated. Customer satisfaction scores are dropping. This is the presenting problem, and it is where most interventions stop.
Resist the urge to fix it directly. Instead, ask: what is connected to this?
2. Trace Upstream
Follow the connections. Why do deploys break? Because testing is insufficient. Why is testing insufficient? Because the team is under constant deadline pressure. Why the pressure? Because scope is never negotiated.
Each “why” reveals a new node in the system. The connections between nodes are just as important as the nodes themselves.
3. Find the Leverage Point
Look for nodes with many connections. A single change here ripples through the entire system. In our example, the scope negotiation process sits upstream of deadlines, testing, deploy quality, and team morale.
Changing how scope is agreed upon is a higher-leverage intervention than adding more test automation or hiring more engineers.
4. Design the Intervention
Once you have identified the leverage point, design a small, targeted change. Introduce a simple scope check at the start of each sprint. Make trade-offs visible. Give the team a voice in what is realistic.
Small structural changes, applied at the right point, are more powerful than large initiatives applied at the wrong one.
In Practice
Systems thinking is not abstract theory. Here are four situations I encounter regularly where seeing the system changes everything.
Why your stand-ups feel pointless
The meeting is not the problem. The underlying structure is: unclear priorities, invisible dependencies, and a team that lacks shared context. Fixing the meeting format treats the symptom. Mapping the information flow reveals why communication keeps breaking down.
Reading the signals in team turnover
When people leave, it is tempting to blame salary or management. But turnover often signals a deeper system issue: lack of autonomy, invisible career paths, or a culture where raising concerns feels unsafe. The exit interview data is a symptom map.
When adding more people makes things slower
Brooks's Law in action: adding engineers to a late project makes it later. The system effect is real. More people means more communication channels, more coordination overhead, and more time onboarding. Sometimes the leverage point is removing work, not adding people.
The hidden cost of "just this one exception"
Every exception to a process creates a precedent. Over time, exceptions accumulate into a shadow system that nobody designed and nobody maintains. The leverage point is making the process flexible enough that exceptions become unnecessary.
Related Skill Deep-Dives
Each skill deep-dive on the Skills & Framework page explores a specific domain in depth, combining theory, practical frameworks, and real-world application.
Ready to See the System, Not Just the Symptoms?
I help teams and leaders build the capacity to think in systems. Whether through workshops, advisory sessions, or hands-on collaboration, the goal is always the same: find the leverage points where small changes create lasting impact.