You don’t have a people problem, you have a system problem

I should estimate that, in my experience most troubles and most possibilities for improvement add up to the proportions something like this: 94% belongs to the system (responsibility of management) 6% special [1] - W. Edwards Deming

After decades of studying organisations, Deming [1] concluded that most performance problems are not caused by individuals, but by the system they work within. Whether the number is 94%, 80%, or something lower, is almost beside the point. What matters is that most organisational problems are predictable consequences of how decisions are made, incentives are structured, and organisational systems***** are designed. Yet fifty years later, many organisations still respond to problems as if they were individual events.

* Deming defines a system as: network of interdependent components that work together to try to accomplish the aim of the system

Distinguishing two types of variation

Reading “The essential Deming: Leadership principles from the father of quality”, one thing that stood out for me and has stayed with me since was Deming’s distinction between two fundamentally different types of variation:

1. Special cause variation.

   These are unusual events, causes that lie outside the normal behaviour of the (organisational) system. For example: a misconfigured feature flag briefly exposes an unfinished feature to users, generating a spike in support tickets for that day; or an account manager that accidentally promises a custom feature to a key client without checking capacity, forcing a one-off rush job. These situations are exceptional and specific. These events can usually be investigated and addressed close to where they occur, by the team and/or manager(s) nearest to the event.

2. Common cause variation.

   These are the patterns built into the system itself — the way work, meetings, roles, and incentives are organised. Think of situations like:

• Priorities are continuously changing because the leaders keep adding urgent work without removing anything. Typical reaction: “The team needs to become better at planning.”

• People are in too many meetings because decisions require multiple approvals and everyone is invited “just in case”. Typical reaction: “People need to manage their time better.”

• Teams don’t take ownership because goals, roles, or KPIs are unclear and overlapping. Typical reaction: “We need people with an ownership mindset.”

• People don’t give feedback or raise problems because there is little psychological safety and no structured time or process for speaking up. Typical reaction: “People should just speak up more.”

  In each case, the organisation reacts as if the problem is the people, while the pattern itself is a predictable result of how the system is designed. That is precisely what Deming meant by ‘common cause variation’: outcomes produced by the normal operation of the system, which cannot be fixed by asking individuals to “try harder.”

The mistake: treating system problems as people problems

Deming warned that many organisations confuse system problems and people problems and default to treating common causes as if they were special causes. The four examples above are typical: a systemic pattern shows up, and the response to it is to “fix” the people. Another example:

• A team uses a free tier of a third‑party service for a critical part of the website.
• The service hits its limits in production, causing an outage or severe degradation.
• Management demands to know who made such a “reckless” decision and looks for someone to blame.
• A post‑mortem and a performance conversation follow, focused on the team’s judgement.

In reality, the team chose that route because the approval process for paid services takes months and they were under a tight deadline. The incident is a symptom of how the system handles procurement, risk, and time pressure.  Not of uniquely incompetent people or one foolish choice.

Nonetheless, a few months later, the same fundamental issue could recur, perhaps with a different team or scapegoat, but under the same underlying conditions. Nothing in the system has changed, so it continues to produce the same variation.

Deming called this tampering: reacting to normal systemic variation as if it were caused by a special, isolated event. Tampering feels like decisive action, but it mostly adds cost and frustration without improving the system’s capability.

How to fix the system

Working on common cause variation means moving our attention from events to patterns. It means asking not “who caused this?” but “why does this keep happening?”. In practice, this includes:

• Redesigning workflows to remove bottlenecks and handoffs that predictably lead to delay or error.
• Revising incentive structures that drive local optimisation at the expense of system performance (e.g. sales teams being rewarded for achieving a target number of sales at the cost of delivery quality, for example).
• Addressing policy conflicts between departments, whose individual KPIs make sense but are collectively dysfunctional (https://youtu.be/E2j2SFOvMmQ?si=MEh9VPakLmq_6qO6&t=3174).
• Reducing structural overload — because an overloaded team produces more errors not because of individual carelessness but because the system itself is overloaded.
• Building feedback loops so that information about process quality reaches decision-makers in time to act, rather than surfacing only after damage is done.

As Peter Scholtes noted: “Changing the system will change what people do. Changing what people do will not change the system.” [3] Performance pressure, motivational speeches, and performance improvement plans are special-cause interventions applied to common-cause problems and, therefore, often fail to make an impact.

Why it isn’t happening

How to fix the system sounds straightforward enough, yet it’s difficult to achieve. Management struggles to take the needed distance from the system to address it, because it is consumed by it.

According to the Work Trend Index Annual Report: “80% of the global workforce—both employees and leaders—say they’re lacking enough time or energy to do their work”.

It’s not hard to imagine that strategic thinking is the first thing to disappear under pressure. Emails demand attention. Escalations need dealing with. And so, system analysis gets deferred to a later point in time.

In technical, fast‑paced environments, managers face a set of barriers that keep them locked in day‑to‑day operations instead of systemic leadership:

• The Subject-Matter-Expert trap. Many managers are promoted because they are the best engineers, analysts, or specialists, not because they have been prepared for management or, in particular, leadership. When work gets complex or deadlines are quickly arriving, they naturally fall back on what they are good at: doing the work themselves and solving problems as an expert rather than as a system designer. Instead of delegating and improving the flow of work, they become “heroes” with a team attached.
• Resource constraints. In many organisations, there is rarely slack in the system. Administrative support is limited, specialist roles are understaffed, and budgets reward short‑term efficiency over long‑term capacity. Managers are more likely to be incentivised for e.g. cutting two support roles, than for funding a process improvement that reduces incidents next year. The system applauds immediate savings, even when they quietly increase future workload and risk. The result is that managers carry a double burden: they are expected to meet today’s targets while simultaneously redesigning tomorrow’s system. As only the operational side has visible consequences when neglected, strategic work loses the prioritisation battle.
• Bureaucratic processes. Layered governance, reporting requirements, and compliance processes further impact leadership attention. Hours that could be spent on coaching, redesigning workflows or aligning strategy are instead spent on dashboards, status reports, approvals, and internal presentations. The organisation unintentionally trains managers to prioritise activity over system improvement.

To see why this trap is so persistent, it helps to look at the queueing behaviour of leadership time.

The queue problem: Why you can’t just make time for system work

The book ‘The Phoenix Project’ [4] offers an interesting take on wait time and utilisation. Wait time for a resource is not linear with utilisation. In queueing theory, wait time doesn’t increase in a straight line as you get busier. At moderate utilisation, adding more work only causes small delays. But once a resource gets very busy - roughly above 80-90% - average wait times shoot up dramatically. As you push towards 100% utilisation, the expected delay for new work becomes extremely long.

Now apply this to management attention. A senior leadership team that is 90% utilised — with full calendars, operational demands, and constant requests for decisions — has an effective wait time of 9x for any new item. A cross-functional systems analysis requires getting the right people in the room at the same time. If each participant is 90% booked, the collective scheduling time multiplies dramatically. And that is before accounting for the cognitive cost: research shows that switching between information streams requires 23 minutes for full cognitive refocus, that excessive task-switching reduces decision-making speed by 40% [5], and that information overload leaves managers in many update meetings, yet with very little space to step back and think about the bigger picture.

The organisation that most urgently needs systems analysis — the one that is constantly firefighting and running at maximum capacity — is also the one least structurally capable of conducting it. Again, this is a result of the (unintentional) system design.

What does have an impact?

If queueing theory and systems thinking tell us that “just making time” inside the current system is a long shot, then the path forward is to change the system so that time for strategic and systemic thinking is created by design.

This means:

• Deliberately lowering leadership utilisation. Redesign roles, delegation, and intake of work so senior leaders are not running at 90–100% by default. When utilisation remains below the threshold at which wait times surge, management can respond to systemic signals rather than be consumed by operational noise.
• Distinguishing common from special causes in every review. Before reacting, ask: is this a repeating pattern produced by the system, or a genuine one-off? If it is a special cause, local action by the team or manager closest to the work is usually appropriate. If it is a common cause, only management can fix it, often through a cross-functional effort whose purpose is to analyse and redesign the system rather than to find someone to blame.
• Making the system visible. Use control charts, cumulative flow diagrams, or other tools that show behaviour over time rather than isolated incidents. When leaders can see patterns of variation and flow, they can intervene in structures instead of reacting to symptoms.
• Institutionalising collective executive time for system work. E.g., create a recurring time when the right leaders work on the system together and defend that time with the same seriousness currently reserved for major escalations. If that time is optional, the existing queue of urgent work will always get prioritised.

I believe Deming’s insight was that most managers are trapped in a system that keeps them working in the system instead of on it. The “94% that belongs to management” isn’t a jab at management; it is a description of where the largest lever for improvement is. The real question is not whether leaders care about systemic improvement, but whether they can redesign the organisation to have the structural capacity to do so.

Sources

[1] Deming, W. E. (1986). Out of the crisis (p. 270). Massachusetts Institute of Technology, Center for Advanced Engineering Study.

[2] Deming, W. E. (1993). The new economics for industry, government, education. Massachusetts Institute of Technology, Center for Advanced Engineering Study.

[3] https://changethewayyouchange.com/workshops/#:~:text=Change%20is%20successful%20only%20when,.%E2%80%9D%20(Peter%20Scholtes).

[4] Kim, G., Behr, K., & Spafford, G. (2013). The Phoenix Project: A novel about IT, DevOps, and helping your business win. IT Revolution Press.

[5] https://www.linkedin.com/pulse/how-information-overload-undermines-managerial-vikas-gupta-xdiof/

Notes

• “Changing the system will change what people do.” If you redesign structures - workflows, policies, KPIs, incentives, tools, meeting patterns, feedback loops - people’s behaviour shifts because the constraints and signals they live in have changed. Example: if you remove conflicting KPIs and clarify product vs project priorities, you’ll see fewer last‑minute priority changes and planning chaos without needing to lecture teams about planning.
• “Changing what people do will not change the system.” If you focus on individuals - coaching, performance plans - but leave the underlying structures the same, the macro‑patterns stay the same. You might get temporary compliance or heroics, but the recurring problems (overload, handoff issues, unclear ownership) reappear because the system still generates them.