Here is a scene I have watched play out dozens of times. A leader — smart, experienced, genuinely committed — sits across from me and describes a problem they have been trying to solve for the better part of a year. Different details each time, but the shape is always the same. Something keeps going wrong. They have tried fixing it. The fix holds for a few weeks, maybe a month, and then the same problem returns wearing a slightly different outfit. A different person is involved, or a different project, or a different month — but the underlying pattern is identical.
And then they say the thing that tells me everything: “I don’t understand why this keeps happening. We have good people.”
They do have good people. That is not the issue. The issue is that they are applying individual-level fixes to a system-level problem. They keep treating the visible symptom — the missed handoff, the team that stops communicating under pressure, the senior person who burns out every eighteen months — because the symptom is urgent and right in front of them. The structure generating the symptom is none of those things. It is quiet, invisible, and patient. And so the symptom returns, reliably, because the thing producing it was never touched.
If you keep paying the same cost despite changing the people, the problem is not the people. It is the architecture that connects them. The reporting lines, the way decisions get made, what behaviour actually gets rewarded when no one is watching. That architecture is a system. And the system is getting what it’s designed to get — not what you intended, not what you announced at the last meeting, but what the structure actually produces when real humans operate inside it under real pressure.
The system is getting what it’s designed to get. Not what you intended. Not what you believe you communicated. What the structure, incentives, and feedback loops actually produce. If you do not like the output, redesigning the system is the only intervention that holds.
Events vs. Trajectories
Most leaders spend their days managing events. A project slips. A key person hands in their notice. A client relationship goes sideways. Each event gets a response — a debrief, a counteroffer, a difficult conversation. The response is proportionate to the event, and that is exactly the problem. Because the event is not the thing that matters. The trajectory is.
An event is a snapshot. A trajectory is what has been happening over the last eighteen months, and where the pattern points if nothing structural changes. A project slipping is an event. Projects of a certain type slipping every time they cross a particular handoff point — that is a trajectory. A good person leaving is an event. Three strong people leaving the same team inside a year, each citing some version of the same frustration — that is a trajectory. And trajectories do not resolve themselves. They continue until the structure driving them is changed.
The distinction is not abstract. It determines where you spend your finite attention. Event-level thinking keeps you in permanent triage — always responding, never redesigning. You become the person who is very busy, very responsive, and solving the same problem for the third time this year. Trajectory-level thinking asks a fundamentally different question: What structure is producing this pattern, and what would need to change in the structure to shift the direction?
Systems don’t respond to intentions; they respond to consequences. You can announce a new direction, a new set of priorities, a new way of working. The system will ignore all of it and continue responding to whatever is actually rewarded, actually punished, and actually measured.
This is why so many well-intentioned changes produce nothing lasting. The announcement was sincere. The intention was real. But the structure — what people actually get promoted for, how information actually flows, who actually makes the decisions that matter — remained untouched. The system absorbed the new initiative the way a river absorbs a stone: a brief disruption, then the same current flowing in the same direction.
Why Blaming Individuals Fails
Blame is psychologically efficient. It resolves ambiguity fast. The project failed because Sarah dropped the ball. The team underperformed because James is not a strong manager. The client left because someone on the account team was not paying close enough attention. Each of these may contain a grain of truth. None of them is an explanation.
I watch this happen in organisations the same way I watch it happen in families. Someone is identified as “the problem.” The problem is removed. And six months later, someone else has drifted into the same role, producing the same friction, generating the same complaints. Because the position in the system is what creates the problem, not the person who happens to be occupying it.
Sarah dropped the ball because she was carrying six concurrent priorities with no way to triage them. James is managing poorly because he was promoted for being excellent at something entirely different and given no infrastructure to do the new job. The client left because the team’s incentive structure quietly rewarded bringing in new work over looking after existing relationships, and that had been true for two years before anyone noticed the pattern.
When you blame the individual, you get the satisfaction of a clear narrative and the comfort of a simple fix: replace the person. And then the replacement, operating within the same structure, produces the same result. Because the structure has not changed. Only the name has.
First change the environment, then ask for heroics. If good people consistently struggle in the same role, the role is the problem. If talented teams consistently produce mediocre outcomes, the system connecting those teams is the problem. The person is visible. The structure is not. Blame follows visibility, not causation.
This is not an argument against accountability. It is an argument against misplaced accountability. Hold people responsible for what they actually control. Hold the system responsible for what the system produces. Confusing the two guarantees that you will keep replacing individuals while the structural cause sits quietly underneath, generating the next failure on schedule.
The Outcome Engine
Every recurring pattern in a team, an organisation, or a career is the output of a system with identifiable components. The components are not mysterious. They follow a sequence, and once you can see the sequence, you can intervene at the point of highest leverage rather than the point of highest visibility.
The sequence runs like this:
1. Structure
Structure is the physical arrangement of elements: who reports to whom, how resources are allocated, what information flows where, what decisions require approval and from whom, how close or far people sit from the work they are supposed to understand. Structure is not strategy. Strategy is what you intend. Structure is what you actually built. When the two diverge — and they always diverge — structure wins. Every time. You can have the most brilliant plan in the world, but if the structure underneath it routes information to the wrong people, delays decisions by three weeks, or separates the person making the call from the person who understands the situation, the structure will produce exactly what it is designed to produce. Which is not what you intended.
2. Incentives
Incentives are the consequence architecture: what gets rewarded, what gets punished, what gets quietly ignored. This includes the formal mechanisms — compensation, promotion criteria, performance reviews — but the informal ones are usually more powerful. What does the leader actually pay attention to? What behaviour gets praised in meetings? Who gets the interesting assignments? What kind of person gets promoted, and what does that tell everyone about what is really valued here?
People are exquisitely sensitive to what is actually rewarded, regardless of what is officially stated. I have never met a group of humans who could not decode the real incentive structure within their first few months in a role. They may not be able to articulate it. But they respond to it with remarkable precision.
3. Behaviour
Behaviour is the rational response to the structure and incentives as they actually exist. If people are doing something that looks irrational to you, you are not seeing the incentive they are responding to. Behaviour is never random in a system. It is always optimising for something — and the thing it optimises for is whatever the system actually rewards, regardless of what anyone says is valued.
When a team hoards information rather than sharing it, the question is not “Why are they so territorial?” The question is: “What is this system rewarding that makes hoarding the rational move?” When someone avoids raising a concern, the question is not “Why don’t they speak up?” It is: “What happened to the last person who did?”
4. Feedback
Feedback is the information that flows back from behaviour to the people who control structure and incentives. Effective feedback is timely, accurate, and connected to someone who can actually act on it. Most organisational feedback is none of these things. It is delayed by weeks or months. It is filtered through layers of interpretation. And it arrives at people who lack the authority to change anything structural, so it accumulates as frustration rather than producing adjustment.
The result: the structure produces behaviour, the behaviour produces outcomes, and the outcomes either never reach the people who could change the structure, or reach them so late that the connection between cause and effect is invisible. By the time someone says “We have a problem,” the problem has been baked into the system for a year.
5. Stability or Drift
If the feedback loop is intact, the system self-corrects. Structure produces behaviour, behaviour produces outcomes, feedback connects outcomes to structure, and the structure adjusts. This is stability — not rigidity, but dynamic equilibrium. The system adapts because the information loop is complete.
If the feedback loop is broken — delayed, distorted, or missing — the system drifts. It continues producing the same behaviour regardless of changing conditions because it has no mechanism to detect that conditions have changed. Drift is not dramatic. It is the slow, invisible divergence between what the system is doing and what the environment now requires. By the time drift becomes visible, the correction needed is large, expensive, and urgent — which is exactly when large corrections are hardest to execute well.
Structure creates Incentives, which shape Behaviour, which generates outcomes. Feedback either connects those outcomes back to Structure (producing Stability) or fails to connect them (producing Drift). Every chronic problem you face is a breakdown somewhere in this chain. Find the break, and you have found the leverage point.
Three Patterns That Look Like People Problems but Are System Problems
The Outcome Engine is abstract until you see it operating in the specific, mundane situations where teams actually get stuck. Here are three patterns I encounter regularly. In each case, the leader has diagnosed a people problem. In each case, it is a system problem.
What you see: A new initiative is launched with genuine enthusiasm. Six months later, adoption is shallow, the language has been adopted but the behaviour has not, and the initiative is quietly dying while everyone pretends it is alive.
What people say: “Our team doesn’t embrace change.” “Middle management didn’t buy in.” “We need to communicate the vision better.”
What the system is doing: A new initiative was added. Nothing existing was removed. No capacity was freed. The implicit message was: do everything you were already doing, plus this new thing, with the same people in the same hours. The only rational response available within that structure is performative compliance — adopt the language, attend the meetings, fill in the new reports, and continue doing whatever was already rewarded because those are the things that determine your day-to-day reality. The initiative does not fail because people resist change. It fails because the structure made genuine adoption impossible. There was nowhere for it to go.
The leverage point: Before adding, remove. Capacity is finite. If you want the new thing to be real, you have to make room for it by taking something else off the table. Not theoretically. Actually.
What you see: A significant problem surfaces late. By the time leadership hears about it, the options for correction are limited and expensive. Everyone downstream knew about it weeks ago.
What people say: “Why didn’t anyone raise this earlier?” “We need a culture of transparency.”
What the system is doing: Bad news is punished. Not formally — no one has a written policy penalising the messenger. But informally, everyone has watched what happens. The person who raises a concern becomes associated with the concern. Their judgement gets scrutinised. The meeting where they spoke up becomes tense and uncomfortable. The rational response: delay reporting. Minimise. Frame problems as “challenges we’re managing.” Problems surface late because the system makes late surfacing the safest option for the individual. And when the problem finally lands on leadership’s desk, the response is tighter oversight and more frequent check-ins — which further increases the cost of honesty, which further delays reporting. The loop tightens.
The leverage point: Reverse the incentive at the source. The first person who brings a problem forward early needs to be thanked, publicly and specifically, for the early warning. Not interrogated about why the problem exists. The system will not believe the new incentive until it has seen real consequences — actual, visible reward for the behaviour you want — at least three or four times. Words change nothing. Visible consequences change everything.
What you see: Someone who was sharp, decisive, and engaged eighteen months ago is now slower, more reactive, and visibly struggling to maintain the standard they used to set effortlessly. They describe it as burnout.
What people say: “I need a holiday.” “I’ve lost my edge.” “I just need to push through this quarter.”
What the system is doing: Sleep has been traded for hours. The initial return on borrowed time looked positive — more output, more availability, a feeling of momentum. But executive function degrades reliably with sleep deprivation: decision quality drops, emotional regulation weakens, the ability to hold complexity narrows. The degraded cognition produces avoidance of the harder work, because hard problems now feel overwhelming rather than engaging. Avoidance creates a backlog. The backlog creates pressure. The pressure triggers more hours. More hours means less sleep. The loop accelerates. What looks like a motivation problem or a character deficit is a feedback loop with a physiological driver. The person is not failing. The system they have built for themselves — the structure of their day, the implicit expectation of constant availability, the absence of any honest signal about their own cognitive state — is producing exactly the output it is designed to produce.
The leverage point: Intervene at the physiological constraint: sleep. Not motivation. Not discipline. Not a new planning tool. The constraint is biological, and every downstream symptom — the avoidance, the poor decisions, the emotional volatility — resolves when the constraint is addressed. Willpower applied against a structural constraint is borrowed at high interest and repaid with compounding damage.
In each case, the visible problem — the shallow adoption, the late escalation, the declining performance — is not the cause. It is the output. The cause is the structure that makes the visible problem the rational, predictable, almost inevitable outcome. Addressing the output without changing the structure is painting over rust.
First Principles: The System Creates Its Own Behaviour
This is the foundational principle of systems thinking, and it is the one that most leaders resist. Not intellectually — the logic is straightforward. Emotionally. Because accepting that the system creates its own behaviour means accepting that you, as the designer or inheritor of the system, are implicated in every outcome the system produces. Including the ones you find frustrating.
I see this resistance in my consulting room in exactly the same form I see it in my therapy room. The manager who cannot understand why their team keeps withholding information — while they themselves visibly tense up every time someone delivers bad news. The leader who wants innovation but whose approval process takes six weeks and punishes failed experiments. The founder who says they want their senior people to take ownership, while personally weighing in on every significant decision. In each case, the person is sincere. They genuinely want the outcome they describe. But the system they built, or the system they chose not to redesign, is producing something else entirely.
The system is getting what it’s designed to get. If you do not like the output, the question is not “who failed?” The question is “what did I build?”
This is not fatalism. It is the opposite. If the system creates its own behaviour, then changing the system changes the behaviour. You do not need to persuade people to act differently. You do not need to inspire them, send them to a workshop, or give them a motivational speech. You need to change the structure they operate within, and the behaviour will follow — because the behaviour was always a response to the structure, not a property of the individuals.
This is where the leverage is. Not in working harder, communicating more clearly, or crafting better value statements. In redesign. The system does not respond to your intentions. It responds to its own architecture. Change the architecture, and you change the output. Leave the architecture intact while changing everything else, and you get the same output with new language wrapped around it.
Systems don’t respond to intentions; they respond to consequences. The gap between what you intend and what the system actually produces is not a communication problem. It is a design problem. And design problems require design solutions — structural changes to incentives, feedback timing, and how resources actually move — not motivational ones.
The 20-Minute Systems Scan
What follows is not a comprehensive systems analysis. It is a triage tool — a structured twenty minutes that surfaces the most likely structural cause of a recurring pattern. Use it on any problem that keeps returning despite competent attempts to resolve it.
The 20-Minute Systems Scan
Select a recurring problem. Not a one-time event — a pattern that has appeared at least three times. Then work through the following five questions. Write the answers down. Do not do this in your head; the value is in the externalisation.
- What is the repeating outcome? Describe it in observable terms. Not “morale is low” — that is an interpretation. What are you actually seeing? People leaving a specific team? A specific type of project running over time? The same kind of conflict surfacing between the same functions? Name the pattern as precisely as you can. The more concrete the description, the more useful the exercise.
- What is the typical trigger? What event or condition precedes the pattern? A deadline approaching? A new person joining the team? A particular meeting or planning cycle? The trigger is the point in the system where the loop begins to execute. It is usually more specific and more mundane than you expect.
- What is the stabilising payoff? Every recurring pattern persists because something in the system benefits from it — not in the sense that someone wants the bad outcome, but in the sense that the current arrangement is serving some function, even if that function is no longer desirable. Initiative fatigue persists because it lets leaders launch without the harder work of removing. Silence persists because it protects individuals from scrutiny. The high-performer loop persists because the short-term output increase feels like progress. What payoff is keeping this pattern stable?
- What is the hidden constraint? What resource, capacity, or structural element is the binding constraint that makes the current pattern inevitable? Capacity. Access to information. Decision-making authority. Time. The constraint is the thing that, if relaxed, would make a different outcome possible without requiring anyone to work harder or be more motivated. You are looking for the bottleneck, not the blame.
- What feedback is missing or delayed? What information, if it arrived faster or more accurately, would allow the system to self-correct? In the silence culture, it is the safety to report early. In the performance loop, it is honest data on cognitive function and decision quality. In initiative fatigue, it is truthful reporting about actual capacity. The missing feedback is usually the single highest-leverage intervention available, because restoring feedback allows the system to correct itself rather than requiring you to correct it by hand.
Spend four minutes per question. The constraint on time is deliberate — it forces specificity over rumination. If you cannot answer a question in four minutes, that itself is diagnostic: it means you do not have visibility into that layer of the system, and gaining that visibility should be your first intervention.
The scan is not the solution. It is the diagnostic that points you toward the right layer. Most leaders intervene at the behaviour layer because that is where the problem is visible. Someone is not communicating well enough, not prioritising correctly, not taking ownership. The scan moves your attention downward — to structure, incentives, and feedback — where the actual leverage lives. A structural change at the right point will do more than a hundred conversations about behaviour, because the behaviour is downstream. Change the upstream condition, and the downstream pattern shifts without requiring anyone to exert willpower or adopt a new mindset through sheer determination.
- Running the scan on a one-time event. The tool is designed for recurring patterns. If the problem has only happened once, you do not yet have enough data to identify a system. Wait for the pattern to repeat, or accept that this may be noise rather than signal.
- Answering the questions in your head. Externalisation is not optional. The act of writing forces precision that thinking alone does not. Your internal narrative will smooth over the gaps and flatten the contradictions. Written answers expose them. If you will not write it down, you are not doing the exercise — you are thinking about doing it, which is a different activity with a different output.
- Identifying the system and then intervening at the wrong layer. The most common mistake after a successful diagnosis is still intervening at the behaviour layer because it feels more actionable. “We have a feedback problem” is a system-level diagnosis. “Let’s tell people to give more feedback” is a behaviour-level intervention. The system-level intervention is: change the structure so that feedback flows as a natural byproduct of the work, rather than requiring individuals to voluntarily do something the current structure quietly discourages.
Design and Learning, Not Control
There is a seductive misreading of systems thinking that turns it into a control framework: if I understand the system completely, I can predict and control every outcome. This is wrong, and pursuing it will make you a worse leader, not a better one.
Complex systems — teams, organisations, markets, relationships — are not controllable in the mechanistic sense. They contain too many variables, too many feedback loops, too many nonlinear interactions between people who are themselves complex systems. The goal of systems thinking is not to build a perfect model that predicts everything. The goal is to build a model that is less wrong than the one you are currently operating with, and then to keep updating it as reality teaches you where your model diverges from what is actually happening.
The stance is design and learning. Design: change the structure where you have evidence of a leverage point. Learning: observe what actually happens after the change, compare it to what you expected, and update your understanding of the system accordingly. Then redesign. Then learn again. This is an iterative cycle, not a one-time analysis. The leaders who use systems thinking well are not the ones with the most sophisticated models. They are the ones who update fastest. They hold their understanding firmly enough to act on it, loosely enough to revise it, and they treat every intervention as an experiment that generates information about how the system actually works.
The goal is not control. It is design and learning. You redesign the structure based on what you understand. Then the system teaches you what you missed. The best leaders are not the ones who get the design right the first time. They are the ones who learn from the system’s response fastest.
Key Takeaways
- Recurring problems are structural, not individual. If the same failure repeats despite different people, the cause is in the system, not the personnel. Stop replacing individuals and start examining the architecture they operate within.
- Manage trajectories, not events. Events are data points. Trajectories are patterns. The trajectory tells you where the system is heading. The event only tells you where it was on one particular day.
- The Outcome Engine explains most chronic patterns. Structure creates incentives, incentives shape behaviour, behaviour generates outcomes, and feedback either connects outcomes back to structure (stability) or fails to (drift). Find the broken link.
- The system responds to consequences, not intentions. Announcements and value statements change nothing until the incentive structure and feedback loops change. The system ignores what you say and responds to what you actually reward, tolerate, and punish.
- The 20-Minute Systems Scan is your entry point. Five questions. Twenty minutes. The output is a diagnosis of which layer — structure, incentives, behaviour, or feedback — contains the leverage point for your specific recurring pattern.
- Design and learn. Do not try to control. Complex systems are not fully predictable. Intervene where you have evidence, observe the response, update your model, and redesign. The cycle is the method.
This is the entry point. The principle that the system creates its own behaviour reframes every chronic problem from a motivation issue to a design issue. From “why won’t people change?” to “what is the structure incentivising?” From blame to architecture. From wishful thinking to mechanics.
But the principle alone is not enough. To redesign a system, you need a language for describing what changes slowly versus what changes quickly — the reservoirs of capacity, trust, knowledge, and morale that accumulate and deplete over time, and the rates at which they flow. That language is the subject of the next post.
If you want the structural diagnosis — not the motivational pep talk — that is the work we do.
Request Assessment