The observation is not original. It is widely attributed to Deming, though the precise origin is disputed. The point survives the attribution: if an organisation consistently produces the same operational failure, the cause is rarely the individual at the point of failure. It is the system that made that failure inevitable.
Recurring problems are structural. The people at the visible link in the chain are not the issue. The chain itself is.
A stock figure that nobody can quote
Consider a question that should be simple: how many units of a product does the business have in stock?
Free · 4 minutes
When two of your systems disagree, do you know which one to believe?
Fourteen questions on ownership, lineage, and quality — the difference between a number on a dashboard and a number you could defend. Banded finding on screen, full sheet by email.
In a typical mid-sized organisation, the answer depends on which system you ask.
The CRM holds what sales can promise — available to sell, after allocations and reservations. The ERP holds what the business owns — physical inventory including stock that has been bought but not yet moved into the right position. The warehouse management system sees physical positions: stock in the main bay, stock in goods-in, stock in a virtual warehouse used for returns or pre-orders. The picklist system reduces availability the moment a pick list is generated, before anything has physically moved. The accounting system only sees what has been transacted; stock that has shifted physically but not yet hit a transaction does not exist in its view. The reordering system is making purchasing decisions based on whichever figure it was wired to read.
Each system is internally correct. Each is answering a slightly different version of the question. Together, they produce a stock picture in which the sales team, the warehouse, and finance all have different answers — and nobody is technically wrong.
The outcomes are predictable. Orders go out that cannot be fulfilled. Stock-outs occur that nobody saw coming. Surplus stock arrives because the reordering system was looking at a figure that did not reflect actual availability. A constant, low-level conflict between teams who each have data on their side.
Who gets blamed
The blame usually lands at the most visible link.
The warehouse manager is blamed for the stock-out. The sales representative is blamed for the oversold order. The buyer is blamed for the surplus. Each conversation is local. Each assumes the failure was a discipline issue, a judgement issue, or an attention issue.
It is none of those. The warehouse manager was reading the figure the warehouse system gave them. The sales rep was reading what the CRM showed as available. The buyer was reading the reordering system’s recommendation. All three were doing what their system told them to do. The systems disagreed. The chain produced the outcome it was structured to produce.
This is the moment the Deming observation lands. The system was perfectly designed — not deliberately, but in effect — for the outcome the organisation is now blaming individuals for.
Why nobody spots it
Most of the organisation only sees the link directly in front of them.
The warehouse sees the picklist that arrived. The picklist system sees the stock figure it was told. Finance sees the transaction that did or did not arrive. Each part of the chain is functioning correctly by its own measure. Each can defend its position. Each is, in isolation, right.
The structural problem is only visible from above the chain. Someone has to look at all the systems together, ask the same question of each, and notice that the answers disagree.
In most organisations, the person who spots it is a data analyst — usually someone trying to build a report that requires reconciling these figures, who realises the reconciliation is impossible. They are the only person whose job has forced them to look across the chain rather than at one link in it.
When the data person raises it, the response is often to focus on the report rather than the structure. The report is the immediate problem. The structure is much larger.
What this looks like beyond stock
The stock example is vivid, but the pattern recurs across operational domains.
Customer records held in multiple systems with different update rules produce inconsistent customer experiences. Order states tracked in ecommerce, fulfilment, and accounting produce arguments about whether an order is open, picked, shipped, or invoiced. Pricing logic embedded in the catalogue, the ecommerce platform, and the ERP produces invoices that do not match quotes. Project budgets tracked in the PM tool, finance, and HR produce monthly reports that nobody fully trusts.
In each case the symptom is a recurring failure that the organisation attributes to discipline. The actual cause is structural: multiple systems producing slightly different answers to questions the business needs a single answer to.
Individual blame is the response of an organisation that has not yet looked at the chain.
What changes when the chain is examined
The work is not technically complex. It is organisationally uncomfortable.
Examining the chain requires admitting that the systems disagree. It requires choosing which system is authoritative for which question — and accepting that the others must reference rather than replicate. It requires conversations about who owns each entity, what propagates between systems, and which figure is the basis for which decision.
These are the conversations that the organisation has been avoiding by blaming individuals. The blame conversation is easier in the moment. It is much more expensive over time.
Once the chain is examined, the recurring failures usually become traceable to specific structural decisions — a sync that runs in the wrong direction, a system held as authoritative for a question it cannot answer accurately, an ownership boundary that was never made explicit. The fixes are concrete. The individuals stop being the focus, because they were never the cause.
A few rules
A recurring failure is a structural diagnostic. If the same outcome happens repeatedly, the system is producing it. The individuals at the visible link are not the explanation.
Each system is answering its own question. Five systems holding stock data are answering five slightly different versions of “how much do we have.” Identify which question each is actually answering before reconciling the answers.
Authority must be assigned per question, not per system. Available-to-sell, on-hand, accounted, on-order — each is a different question. One system owns each answer. The others reference it.
The data analyst is often the first to see it. When someone is repeatedly failing to reconcile figures across systems, listen carefully. They are looking at a structural problem from the only vantage point that reveals it.
Blame is the cheap response. It feels conclusive and resolves the immediate conversation. It does nothing about the next failure, which the system will produce on schedule.
Richard King is CTO at Sixteen Pillars — technical leadership, architecture, and governance for organisations that need it without the overhead of a full-time hire.
Most technology problems are not technology problems. They are control problems.
The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.