It's the System 98% of the Time. Deming Said 94%. Your Instinct Says It's the Person.

When a client brings me a performance problem, it arrives with a diagnosis attached. Usually a name. Sometimes a team, sometimes a role, but it's a person, and the request is to confirm it and help them handle it.

In my engagements, that diagnosis turns out to be wrong roughly 98% of the time. What presents as a talent or performance problem is a systems problem – the process, the flow, the incentives, the information the person didn't have. A genuine people problem exists. I've found them. They're rare.

That 98% is an estimate from experience, not a measurement. I haven't kept a tally with a denominator. It's the number I'd give you if you asked me over coffee how often I've been surprised in the other direction, and the answer is almost never.

Which is roughly what Deming said, in almost the same hedged form, decades ago in a different industry:

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.

He was talking about manufacturing variation, I'm talking about software teams, and neither of us ran a controlled study. He was explicit about that too – his 1975 paper says the percentages are "intended only to indicate that, in my experience, problems of the system overshadow special causes."

So this isn't two studies agreeing. It's two practitioners, separated by a discipline and a working lifetime, reaching for a number to describe the same experience and landing four points apart. That's weak evidence and it's a strong prompt, and the prompt is the interesting part: why does the estimate keep coming out this lopsided when the instinct in the room always points the other way?

What a systems cause looks like from the inside

The reason the systems explanation loses the argument isn't that it's implausible. It's that it's boring and diffuse, and it doesn't come with a name attached.

A missed deadline caused by a person is a story: he didn't start early enough. A missed deadline caused by the system is an accounting exercise: requirements that arrived late because the person who writes them was pulled elsewhere, an environment that was down for a stretch, a review that sat unassigned over a weekend because the rotation has a gap nobody documented, an estimate that never had slack in it because estimates here get negotiated down as a matter of routine. Several contributing conditions, none of them anyone's fault in particular, and every one of them likely to recur.

Nobody wants to present the second version to a board. It sounds like an excuse even when it's an audit, and the person delivering it has to say "this will keep happening" rather than "I've dealt with it." So the first version wins in the room, over and over, on presentation quality rather than accuracy.

There's a tell for this, and it's the cheapest diagnostic I know: ask how many times this has happened before with different people in the chair. If the answer is "a few," you have your answer already and the name attached to the current instance is noise.

Your instinct isn't lazy. It's cued.

The best answer I've found is in Repenning and Sterman's work on process improvement, and it's a cognitive explanation rather than a moral one, which is what makes it useful.

Attributing a shortfall to worker effort fits every cue people use to infer cause. Effort immediately precedes the output. It correlates with it. It happens in the same place, to the same object, in front of you. Process problems break all three – they precede the failure by weeks, the correlation is imperfect and often invisible, and the cause sits somewhere else in the building entirely.

So the person standing nearest the bad outcome gets the attribution, and not because anyone is being unfair. The evidence genuinely looks like that from where they're standing. This is the fundamental attribution error doing its ordinary work in an operational setting, and it's why the diagnosis arrives before I do.

The trap is that the wrong diagnosis builds its own evidence

This is the part of their paper I'd want every founder to read, and it's why the error persists rather than self-correcting.

Managers who believe people are the cause take actions that follow from that belief – tighter monitoring, more pressure, individual targets, less slack for anything that isn't visible output. Those actions push people to behave exactly the way the belief predicts. They stop investing in improvement work, because improvement work doesn't show up in the thing being measured. Quality drops, so monitoring tightens again. Repenning and Sterman describe the endpoint plainly: the beliefs get embedded in the physical structure of the organisation, and you end up with conflict, mistrust, and control structures that prevent useful change of any kind.

Run that loop for eighteen months and you have a team that genuinely does look like the team you thought you had. The diagnosis manufactured its own confirmation. Nobody lied and nobody was incompetent, and the conclusion is still wrong.

Harvard Business Review restated the 94% for a modern audience a couple of years ago, which tells you the finding has been available the whole time. Availability isn't the constraint. The loop is.

How to tell the rare real one

I'm not arguing nobody is ever the problem, and a framework that can never return "it's this person" isn't a diagnosis, it's an ideology. So here's how I separate them.

Look at whether the pattern travels. If the same role fails under three different people, it's the role. If one person fails in three different systems, that's a signal about the person. Most organisations have never run that comparison, because they've only ever had one version of the seat.

Look at whether the conditions were actually present. Did they have the information, the authority, the time, and a clear definition of what good looked like? If any of those is missing, you haven't tested the person yet – you've tested the system and read the result off the nearest human.

Look at whether it's capability or conduct, because they get conflated constantly and they're completely different problems. Someone who can't yet do the work in a system that never taught them is a systems problem with a training answer. Someone who won't – who's been told, understands, has what they need, and doesn't – is a real people problem, and that one has to be dealt with promptly, because carrying it is its own kind of unfairness to everyone else on the team.

What this costs you if you get it backwards

The asymmetry matters here. Treat a systems problem as a people problem and you lose the person, keep the problem, and hire someone who will fail the same way inside a year – and you've spent the team's trust to do it, because everyone else could see the machine was broken.

Treat a people problem as a systems problem and you'll waste a quarter improving a process that was fine. That's expensive, and it's recoverable, and the team will forgive it because you were at least looking in a direction that suggested you thought well of them.

Given that neither Deming nor I can give you a defensible denominator, the honest advice isn't "assume 94%." It's that when you're genuinely unsure, the two errors don't cost the same, and you should let that asymmetry break the tie.