Most leaders develop systems thinking by accident. Here’s how to build it on purpose.
I emphasize learning systems thinking, but I haven’t explained how to build the skill. I often highlight its importance, yet I rarely give people actionable steps to develop it.
My systems thinking is intuitive now, and most senior leaders I know developed it the same way: informally, through experience. This makes it seem innate rather than a skill to practice.
In this piece, I’ll lay out what systems thinking looks like, how to start developing it, and how to improve it over time. I’ll preview a specific framework and a set of practical exercises designed to help you put systems thinking into practice. If you’re looking for concrete guidance you can use right away, you’ll find it, read on.
The Two Modes
There’s a tension at the core of leadership that most people feel but don’t name: leaders must balance transactional management—defining rules, assigning tasks, creating incentives, and fixing problems as they surface —with systems thinking—understanding and addressing the underlying structures that produce those problems and results.
Transactional management works fine for small teams and short time horizons. It works for early-stage startups that are just trying to survive. But it hits a ceiling. As scope grows, the problems multiply faster than any individual leader can address them. Leaders who stay transactional end up playing whack-a-mole with symptoms instead of addressing root causes. If every problem you solve creates two new ones, you’re not solving problems. You’re rearranging them.
If you’ve been part of a small startup that grows into a larger company, you’ve felt this. In the early stage, transactional thinking works because you’re just trying to make it to next week. But as the company grows and time horizons lengthen, that operating mode starts to hold you back. That’s when you need to shift into thinking about the system you’re in and how to improve it.
Systems thinking is the shift from ‘why is this person not delivering?’ to ‘what’s making it hard for this person to deliver?’ Though subtle, this shift changes where you focus your attention. It also connects directly to strategy. When you understand the system, you can anticipate how a change in one place will affect another. That foresight, seeing second-order effects, links strategic and systems thinking as leaders advance.
The gardener metaphor is one I keep coming back to. You can plan a garden down to the centimeter: this rose here, that plant two inches away, exactly this many leaves. It can all be laid out on paper. Still, when you plant the seeds, and they grow, you’re going to get what you get. The goal isn’t to match the plan exactly, but to create conditions where good things grow. You guide and shape, yet the end result will always emerge from the living things involved. Often, the outcome is even better than planned because of the people who are part of it. That’s systems thinking in practice: you’re aiming for a positive outcome, not an exact one.
A Four-Stage Progression
I’ve put together a framework for developing systems-thinking skills. It moves through four stages, from observation to intervention. Think of it as a progression, with each stage building on the one before.
Stage One: See the System
Most people see individual actions, decisions, and outcomes. The first step is recognizing that these are connected by structures, incentives, and dependencies that aren’t always visible. There is a system beneath the visible activity of your organization, and until you start looking for it, you won’t see it.
I hear this all the time, even from people on my own teams: “This team is really slow. What’s wrong with them? Why aren’t they working harder?” But nobody has actually talked to that team. Nobody has asked what they’re dealing with. Maybe they have a poor set of tools. Maybe they’re waiting on another team for something that isn’t visible from the outside. It looks like a people problem, but if you ask the next “why,” you often discover it’s a structural one.
That shift in thinking is foundational. Instead of blaming the team or developer, ask: What conditions make it difficult for them to get their work done?
Stage Two: Map the System
Once you’ve started seeing the system, the next step is to make it visible to yourself and others. Draw the relationships between teams, trace workflow, and identify decision points and bottlenecks. Making the system explicit sets the stage for productive conversations.
When I join a new company, the first thing I do is talk to everyone, not just people in my organization but all the organizations around it. I ask what’s working and what isn’t from both inside and outside perspectives. That gives me more than a list of problems. It starts to reveal the interconnections between teams. Two companies can adopt the same team model and end up with completely different dependency maps. You can’t see that from an org chart. You can only learn it by talking to people.
People will tell you things like ‘we’re constantly waiting on this other team’ or ‘that group keeps dropping work on us.’ These aren’t just complaints, they’re signals about how the system operates. As you collect these, create a map: put teams on a board, draw connections and dependencies, using any tool that works for you. This process clarifies unseen structures.
This map is not a secret document. I share it with people and ask them to correct it. And this is important: the conversations the map generates are often more valuable than the map itself. People will look at it and tell you, “This is wrong, that’s not how it actually works.” That correction process surfaces things you wouldn’t have found on your own. Update the map as you learn. The org chart tells you who reports to whom. A systems map tells you how work actually gets done.
I also look at specific teams and count how many dependencies other teams have on them, and how many dependencies they have on others. Sometimes it looks like the product team is the bottleneck, but when you map it out, the real constraint is elsewhere entirely. It isn’t obvious from the outside or even from the inside until you visualize it. Having that map gives you a way to talk about problems concretely, not as hunches but as visible structures.
Stage Three: Understand How the System Constrains and Enables
Once you have the map, analyze where the system is helping and where it’s hurting. Where are the bottlenecks? Where are the feedback loops? Where are the incentives driving behavior, and are they producing the behavior you actually want?
Donella Meadows’ Thinking in Systems is excellent on this. She describes how systems have sources, sinks, and bottlenecks. In a product development organization, your sources of features and bugs are the sales, marketing, and product teams, as well as developers themselves. Your sink is usually shipping code to 100% of your customers. The path between those two points, and the things that slow it down or speed it up along the way, is the system you need to understand.
This analytical layer helps you recognize patterns across different situations. Misaligned incentives are a common problem: for teams not meeting expectations, examine what they are incentivized to do. Consider how performance is measured and rewarded, as these nearly invisible structures often explain dysfunction. You only see them when you look deliberately.
If you don’t like the behavior a system is producing, look at the incentives before you look at the people. A lot of friction between teams comes down to teams being incentivized for different outcomes instead of the same one.
Stage Four: Intervene with Awareness of Cascading Effects
This is the hardest stage, as it means predicting second-order effects and managing disruption from improvement. When you fix one part of the system, you might unexpectedly impact another. Anticipating this is critical to solving more problems than you create.
To help with this, I suggest using a simple tool before making any system intervention: run through a checklist or set of questions that prompt you to consider potential ripple effects. Here are a few to start with:
- What are the upstream and downstream teams or processes touched by this change?
- What current bottlenecks does this affect, and where might new bottlenecks appear?
- Who stands to lose or gain power, resources, or visibility as a result?
- What informal processes or workarounds are people relying on that could be disrupted?
- What data or feedback loops exist to help you catch unexpected impacts quickly?
Asking these questions up front does not guarantee you’ll predict every effect, but it improves your odds and makes you a more responsible systems thinker.
Here’s a current example I’m thinking about a lot. Engineering teams adopting AI tools are getting faster at code generation. That sounds like pure upside. But the entire system around software development was built for a world where engineering was the bottleneck. Software development has been time-consuming and expensive for decades, and the industry’s practices are all organized around maximizing engineering capacity because it’s the scarcest resource.
Now, engineering is becoming less of a bottleneck. That should mean everything goes faster. But consider what happens. Product teams are used to having time to research and prepare features for engineering to pick up, because engineering consumes that work slowly. When engineering suddenly moves faster, the product team can’t feed the backlog fast enough. You’ve put back pressure on the product team. On the other hand, if you have a QA team staffed relative to engineering’s slower output rate, they’re now getting backed up as well. You’ve solved one bottleneck and created two new ones.
That’s not a reason to avoid the change. But if you don’t see the system, you won’t anticipate those downstream effects until they’re already causing problems. And if you solve the product bottleneck, then something upstream of the product team becomes the constraint. If you solve the QA bottleneck, you might now be putting pressure on the infrastructure, marketing, or sales teams. Understanding these cascading effects is what separates someone who can see a system from someone who can actually intervene in one effectively.
More broadly, AI and agentic systems are, at their core, systems design problems. When you design an AI workflow, you’re building a system with components that interact, handoffs between steps, feedback loops, and failure modes. Leaders who think in systems will design better AI implementations because they already understand how components interact and where things break down. Without systems thinking, leaders will treat AI adoption as a tool problem rather than a system problem. And adding AI to a broken process just gives you a faster broken process.
When You’ll Meet Resistance
Some people see systems thinking as cold or mechanical, as an attempt to turn people into interchangeable parts in a machine. When you try to map out what are essentially human relationships and team dynamics, very organic and people-centered things, some people will resist that framing.
It’s worth addressing directly. Systems thinking is not about treating people as cogs. It’s about making the environment around them better so they can do their best work. That gardener metaphor matters here: you’re not engineering a machine. You’re creating conditions for living things to grow.
You’ll also face friction from peers who operate in a more transactional mode. Sales teams tend to be exceptionally transaction-driven by nature. A lot of the tension I’ve experienced, and that the people I mentor experience, comes from engineering leaders trying to be long-term and systems-oriented, while transactional leaders in other parts of the company need everyone to work the way they do. The “doing stuff” approach, more reorgs, more reassignment, more process, looks productive in the short term. When you’re building systems, it can look like you’re not doing much because the changes are structural rather than visible activities.
This is where communication becomes critical. I learned this the hard way. At one company where I was CTO, I was building better systems, and the improvements were real, but I wasn’t explaining what I was doing well enough. My executive peers, particularly on the sales side, were getting impatient. I could have forced changes through transactionally, but that wouldn’t have produced what they actually needed next. The problem was that from their perspective, they couldn’t see the system I was building. The results weren’t proving fast enough, and I wasn’t making the progress visible. The system I forgot to work on was the one between my peers and me.
That failure taught me something important. Building a better system is not enough if the people around you don’t understand that you’re building one. Systems-level change takes time, and organizations are full of people who want faster answers. When you can hold the line long enough for the system to start producing results, people will become supporters. But if your peers and your leadership don’t understand your work on system-level improvements, they’ll evaluate you on surface-level metrics and lean into quick fixes that undermine what you’re building. Your job is to narrate what you’re doing and why, especially to people who think differently about management. Make the work visible. Show early wins. And keep communicating the trajectory, not just the current state. Communication about system-level work needs to be ongoing, not a one-time explanation.
That said, context matters. Long-horizon systems work is much easier in companies that are doing well. If your company is struggling and just trying to survive, that’s not the time for building systems that take years to produce results. Sometimes transactional leadership is the right match for the situation. Early-stage startups are transactional, and that works because they’re focused on survival. The goal isn’t to always be a systems thinker. It’s to know which mode the situation calls for.
In reality, most organizations need to blend both modes. Urgent issues often require transactional action, even as you continue system-level changes to achieve sustainable improvements. For example, you might handle a critical customer escalation with a quick fix while simultaneously documenting what led to the problem, and then working on a system change to prevent it from happening again. The best leaders combine systems thinking to shape the environment over time with the ability to execute decisively in the moment. That means communicating when you switch between modes, so your team understands why you act one way now and another later. Hybrid approaches let you address today’s fires while still laying the foundations for tomorrow.
Building the Skill in Practice
The progression gives you a mental model. But you also need concrete exercises to develop the skill. Here are the ones I use and recommend.
Map the dependencies when you join a new organization or take on a new scope. This is the first thing I do, and I think it’s the most valuable. Draw how teams relate to each other, not the org chart but the actual working relationships: who depends on whom, where handoffs happen, where shared resources create contention. You can only learn this from talking to people and asking them what’s working and what isn’t. They’ll tell you, especially if you’re new, because it’s not from a decision you made, and they’re hoping you’ll improve things.
Follow a piece of work end-to-end. Pick a feature, a bug fix, a customer request, and trace it from origin to delivery. Document every handoff, every queue, every approval step, every place it sits waiting. Look for the accumulation of small delays, not just the obvious bottlenecks. And remember that this map extends past your organization. You can fix your part of something, but your team is not the full system.
At one company, we had a velocity problem we couldn’t explain. The teams were good. The processes seemed fine. There wasn’t an obvious bottleneck. I asked one of my leaders to try this exercise: take a single piece of work and follow it through the entire organization. What we found wasn’t one big slowdown. It was dozens of small friction points, a day waiting here, two days waiting there. Each one was individually insignificant, and people were aware of them locally. But nobody had seen the accumulation. When you added them all up, they explained the entire velocity gap.
We streamlined those friction points and improved velocity without asking anyone to work harder. Everyone was already working hard. The system was working against them. It was only when we mapped how work moved through the system that this became visible. You can start this kind of exercise in Jira, but you can’t do it all automatically. You have to attend the standups, attend the retros, and follow the actual path. I’ve tried to do it purely through tooling multiple times. It doesn’t work.
Trace how a decision got made. Pick a recent decision and work backward. Who made the final call? What information did they have? Who influenced it? How long did it take, and where did it stall? This surfaces hidden power structures, information bottlenecks, and approval layers that slow the organization down. It also reveals whether the people closest to the problems are making the decisions or whether decisions are unnecessarily being escalated. This exercise is easier if you’re a senior leader who can see the full chain, but it’s worth attempting at any level.
Map incentive structures. For a team or group of teams that aren’t producing the outcomes you expect, look at what they’re actually incentivized to do. Examine how performance is measured, what gets rewarded, what gets punished, and what gets ignored. When I see bad behavior or misaligned priorities, I usually see perverse incentives at work. Teams incentivized for different outcomes rather than the same one will create friction among themselves, and that’s a system problem, not a people problem.
Start This Week
Systems thinking is not an advanced leadership concept reserved for CTOs. It’s a skill that can be developed at any level, starting with the simple act of looking beyond individual performance to ask how the structure around people shapes their work.
Pick one exercise and try it this week. If you are looking for the quickest way to open your eyes to systems thinking, start by mapping the dependencies between the teams you work with. I recommend this as the most impactful starting point, especially for first-timers or anyone short on time. It’s a simple, concrete way to see how your work fits into the bigger picture, and it often surfaces underlying issues you hadn’t noticed before. If you want a deeper dive, follow one piece of work from start to finish and write down every place it pauses. You can also trace how a recent decision actually got made, or look at an underperforming team and ask what they’re incentivized to do versus what you want them to do.
I also recommend two books that shaped my own thinking. Donella Meadows’ Thinking in Systems is the best foundational text I know on the subject. And Jurgen Appelo’s Management 3.0 integrates systems thinking throughout without always calling it by name.
Every organization is a system. The question is whether you’re designing it or just living in it.
To hear an extended discussion of this topic, please listen to my recent podcast episode: Every Organization Is a System. Are You Designing It or Just Living in It?
