Most organizations try to improve by fixing one thing at a time. One team gets a new OKR. One process gets redesigned. One tool gets swapped out. A new CX program launches. A reorg moves a few boxes on the chart. Each of these feels like progress because you can point at it. Something changed. Someone owns it.
A year later the overall pain is usually the same. The same meetings take the same amount of time. Customers still fall through the same cracks. The same decisions get escalated to the same people. The slide deck with the transformation plan has been quietly retired. What happened?
What happened is that the problem was never inside the thing anyone tried to fix. The problem was in how the parts connected to each other, and nobody looked there. Teams got better at their own work and the handoffs stayed broken. The CX program improved touchpoints that were downstream of a structural issue nobody touched. The new OKR pointed one team forward while pulling another one sideways.
This page is where I collect everything I write about systems thinking. If you lead a function, run a transformation, or keep watching good people hit invisible walls, this is the lens that helps you see why. The parts are rarely the point. The connections are.
What is systems thinking in business?
Systems thinking has an academic definition involving feedback loops and stocks and flows and Donella Meadows. It's worth reading. But most leaders don't have time for that version, and they don't need it. The practical version is simpler.
A business is a system. Strategy, structure, processes, people, technology, customers, and the outside world form one connected thing. Change in one part shifts the others, sometimes immediately, sometimes with a lag of months. What a customer feels on Tuesday is the output of decisions made three layers away and two years ago. What a team produces is shaped by incentives they don't see and metrics somebody else picks.
Systems thinking is the practice of zooming out far enough to see those connections, and zooming in far enough to do something about them. It's not a framework. It's a habit of looking.
There are three kinds of thinking that aren't systems thinking, even when smart people do them:
Functional excellence. Running your own function well. Necessary, but it can quietly make the whole system worse if your excellence depends on dumping complexity on the team next door.
Linear problem-solving. Treating a symptom as if it has one cause. "Customers are complaining, so we need a better CX program." Often the complaints trace back to a pricing model, a segmentation choice, or a platform constraint three steps removed from anything the CX team touches.
Framework application. Picking a model (OKRs, Agile, DDD, whatever) and rolling it out as if the framework itself is the change. Frameworks are lenses. They only help if the person holding them is already looking at the system.
Systems thinking in business is not about knowing more theory. It's about seeing more of the whole, and resisting the pull to act before you've seen it.
My top lessons on systems thinking
1. The pain you feel is almost always a connection problem
When I walk into an organization that's stuck, the leaders usually describe the problem as if it sits inside one team. "Product is slow." "Sales doesn't understand the customer." "Risk blocks everything." Nine times out of ten, the pain lives in the space between those teams — the handoffs, the shared data, the decisions nobody owns end-to-end. The teams themselves are mostly fine. The seams are what's torn.
This changes what you look at first. Not the performance of any single function, but the traffic between them. A ticket that sits for eight days because it's "waiting on alignment." A customer request that bounces through three teams before anyone agrees what it actually is. A deal that closes three weeks late because legal and finance are each waiting on the other. The system's performance is decided in the seams, not inside the boxes.
2. Functional excellence can make the whole worse
Every leader wants their function to perform. Reasonable. But local optimization has a cost that rarely shows up in local reports. A sales team that pushes volume above everything floods delivery with unprofitable contracts. A risk team that protects the company from every possible downside also protects it from every possible upside. A product team that ships fast can leave support drowning in avoidable tickets.
None of this is anyone's fault in the normal sense. Each team is doing what their metrics ask for. That's the trap. Metrics that work at the part level can cancel each other out at the whole level. Systems thinking asks the harder question behind "is this team doing well" — is the team's excellence producing a better system, or a worse one?
3. Most improvement plans optimize the part that already works
There's a pattern I see often enough to name it. When a company decides to improve, the improvement gets assigned to the team that is already the most capable. Data team gets more investment. The strongest product line gets more resources. The best-performing region gets the attention. The logic feels sound — back the winners — but it misses the point.
Systems usually get stuck because of their weakest connection, not their weakest part. If ten teams are waiting on one team's decisions, making the nine fast teams faster doesn't help anyone. Goldratt called this the theory of constraints, and the lesson is blunt: find the bottleneck, fix the bottleneck, then go find the next one. Don't optimize upstream or downstream of a choke point unless you've opened the choke point first.
4. You don't need to see the whole system, just two layers up and down
One fear stops a lot of leaders from thinking systemically: that you have to understand everything before you're allowed to act. You don't. Nobody can hold the whole picture of a modern business in their head at once. That's not the bar.
The bar is this — you see two layers above you (what your work feeds into, what strategy depends on it) and two layers below you (what your work depends on, what the teams upstream and downstream are trying to do). That's enough to stop making decisions that create problems somewhere else. It's also enough to spot the connections that actually need attention. The thirteen-layer view of a business I wrote about in what most product teams don't see is a tool for this. You don't need to master all thirteen. You need to know which two or three matter for the decision in front of you today.
5. Seeing connections is a skill, not a title
A C-level title doesn't make anyone a systems thinker. I've met plenty of senior people who run their function brilliantly and still treat every cross-functional problem as someone else's to solve. I've also met mid-level program managers and business leads who already think in connections and handoffs because their job forced them to.
Systems thinking is a practiced habit. You get better at it by doing it — by tracing how decisions travel, by asking what else moves when this moves, by refusing to accept the first explanation for why something is broken. It's a muscle anyone in the organization can build. And the people who build it become disproportionately useful, because most of the work that actually matters at scale happens in the seams they can finally see.
A simple guide to thinking in systems
This is the sequence I use when a client describes a problem that looks like one thing and is almost certainly something else. It's not a formal method. It's a habit of questions.
1. Start with one real pain and trace it outward
Pick a concrete, painful, recent example. Not "our processes are slow" — the actual ticket that took twelve days when it should have taken two. Follow it. Who did what. Where it waited. Who it waited on. What they were waiting for. Every pain has a trail. The trail tells you more than any process map drawn from memory.
2. List the hand-offs, not the boxes
Most diagrams show teams. Systems thinkers draw the lines between teams. Where does work cross a boundary? What gets lost there? What gets added there that wasn't there before? Handoffs are where information degrades, timelines slip, and accountability dissolves. If you can see only one thing, see these.
3. Map the decision points, not the tasks
Tasks get done. Decisions are what stall. Walk through the flow and mark every point where somebody has to say yes or no. Ask who owns each of those decisions, how long it usually takes, and what happens if they say the wrong thing. Decision rights are the quiet load-bearing structure of any operating model. When they're fuzzy, everything above them slows down.
4. Find the couplings
Coupling is when a change in one place forces a change in another. Some couplings are necessary: pricing is coupled to cost structure, features are coupled to engineering capacity. Some couplings are accidental and expensive: sales incentives coupled to a product roadmap that doesn't reward them, risk reviews coupled to every release instead of the risky ones. Couplings you never designed are usually the ones eating your capacity to move.
5. Name the invisible forces
Incentives, budgets, metrics, and unwritten rules shape behaviour more than any strategy deck. When a team's behaviour doesn't match the declared strategy, the strategy isn't winning. Something else is. Find it. It's almost always one of these four. The structure of budgets is especially telling — I wrote about that specifically in your budget structure is your real operating model.
6. Pick the smallest intervention that touches the most connections
The final move is the counterintuitive one. You resist the urge to launch a transformation program. You look at the map you've built and ask: what's the smallest, specific change that would shift the most connections at once? Sometimes it's a single decision right, moved from a committee to a named person. Sometimes it's a metric that stops rewarding the wrong behaviour. Sometimes it's a meeting that gets deleted. The biggest improvements rarely look like big projects. They look like small structural choices that unclog many things at once.
This is the part that connects Systems Thinking to the rest of the work I do. It links directly to operating model design, where the connections get named and redesigned. It links to strategy execution, where the top-level choices either reinforce or contradict the system underneath them. And it links to concept validation, where you test whether a change will actually improve the system before you build at scale.
Best resources on systems thinking
A short list of what I recommend when clients ask where to start.
Donella Meadows — Thinking in Systems: A Primer. The best entry point. Short, clear, no jargon. Her chapter on leverage points is worth re-reading once a year.
Eli Goldratt — The Goal. A novel about a plant manager learning theory of constraints. Feels dated, reads fast, teaches something that stays with you. Every leader who worries about the wrong bottleneck should read this.
Peter Senge — The Fifth Discipline. The classic. The learning organization idea has aged unevenly, but the section on systems archetypes is still gold. Skim the rest.
Russell Ackoff's essays and talks. Provocative, funny, sometimes wrong, always sharpening. His insistence that most problems dissolve rather than get solved changed how I think about improvement work.
My own writing. The thirteen-layer view of a business in what most product teams don't see is the piece I send to people who want a practical map of the layers above the product. It pairs well with Meadows as a bridge from theory to daily work.
Systems thinking won't make your decisions for you. It will change which decisions you notice are yours to make. That's usually enough.
