When Fast Fixes Crowd Out Root Cause Problem Solving

The results came fast. A year in, the defect rate was down, the turnaround time was down, teams had A3s on the wall and could talk about them. Then it flattened. Not a collapse. Just nothing more.

Somebody says the team lost momentum. Somebody says people are tired of the program. Somebody proposes a refresh, new training, a renewed push from leadership. What nobody can say is what changed, because as far as anyone can tell nothing did. The same people are doing the same work in the same way that produced the gains.

Then there's the other thing that happens. A problem you know you solved comes back. You go looking and find the A3 closed, signed, and filed. Somebody remembers the countermeasure. Everybody agrees it worked. It's back anyway.

You did the root cause problem solving. Or you thought you did.

I've explained that pattern the usual ways over the years. Leadership attention moved on. The coaching stopped. The problem was harder than we thought. Sometimes those are true. I now think there's a duller explanation that covers more cases than I used to believe.

Two kinds of gains that look identical

Steve Spear shared a 2007 doctoral dissertation with me, written by Marcelo Pancotto at Harvard Business School. My thanks to Steve for passing it along.

Pancotto studied seventeen automotive assembly plants inside one company, at every stage of rolling out that company's version of a lean production system, from a designated model plant to one still working the old way. What makes the study unusual is the data. Rather than compare plants on overall productivity, he analyzed more than three million quality events per plant on average, looking at specific problem categories instead of a single defect rate.

His term for what he found is a “containing organization.”

Containment is the fix that doesn't ask why. A team member pulls the andon cord, the team leader arrives within seconds, fixes the defect, and the line keeps moving. The customer never sees the problem. That's containment, and Pancotto is careful to say it isn't a failure. A line can't stop until every cause is understood. If the defect is happening today, containing it protects the customer today. He calls that ability to respond a valuable capability, and I agree.

The difference is what happens after. When somebody follows the fix by examining causes, the fast response bought them a chance to investigate while the evidence was still in front of them. When nobody does, the containment has to keep being repeated, because the cause is still sitting there.

Both show up on the chart as the rate going down.

Why the numbers won't tell you which one you have

This is the mechanism behind the problem that comes back after the A3 is closed.

If containment is suppressing a defect before it reaches the inspection station, the person tracking that problem category watches the rate fall. Pancotto describes problem solvers closing projects believing they found and fixed the cause, when what actually happened was that a containment countermeasure quietly absorbed the defect. Lift the containment, and it comes back.

He found that plants improved faster on their lower-frequency problems than on their top problems, and interpreted that as evidence of the same pattern. The top problems were the likeliest to be contained, and so the likeliest to recur.

He also notes that the distorted signal reaches the operator. If containment somewhere else changes the feedback a person gets about their own work, it also changes what they can learn from that feedback.

And the flattening

A plant that gets better at deciding where to put its containment resources will improve, and it can improve quickly, because containment suppresses defects almost immediately. Once that allocation is optimized, those gains run out.

That's the shape from the opening. Fast gains, then a wall, with nobody able to point at what broke. Nothing broke. They were containing, and containment doesn't compound.

Nobody chose this

The part I find most useful is that none of this requires anyone to decide to skip the cause work.

Pancotto found that plant management framed the quality problem in terms of the aggregate defect rate for a production area, rather than the individual problem categories underneath it. That framing points attention at the areas with the worst overall numbers.

That is a sensible way to decide where to put containment resources. It's a poor way to decide where to investigate causes, because an area with a low overall rate can still hold specific problem categories with high defect rates.

So the question shapes the answer. Ask where the aggregate numbers are worst, and you steer attention toward containment. The metric does the skipping.

The company also required at least three open problem-solving projects per inspection station per shift. A project quota, aimed by a metric that tended to find containment opportunities.

The same thing in a hospital

Pancotto cites the 2002 fieldwork by Anita Tucker, Amy Edmondson, and Steve Spear, published as When Problem Solving Prevents Organizational Learning. They observed nurses for 197 hours and found diligent people working around missing supplies and broken processes, not escalating, and in doing so keeping the failures alive. Tucker's example was linens: when a delivery left a unit short, nurses borrowed from another unit and got on with the shift. Why the linens ran short went unexamined.

Most hospitals I've worked with have their own version. Patient cared for. Problem contained. Nothing about the supply chain changed, and the next nurse walks the same hallway.

That's containment performed by the person closest to the work, usually without anyone calling it that.

That doesn't mean every small problem needs an A3. But if a problem matters enough that people keep containing it, somebody eventually has to understand why it keeps happening.

What it asks of a leader

Pancotto's first conclusion is the practical one. In a complex process, the problem population is made up of many categories with low defect counts in each.A central group of problem solvers cannot keep up with a population shaped like that. He argues you need root cause capability that is decentralized and cheap enough to run many small investigations at once.

That's close to what Spear and Bowen described as Toyota's fourth rule in use in Decoding the DNA of the Toyota Production System, that improvement happens through the scientific method, under the guidance of a teacher, at the lowest possible level of the organization. Pancotto adds an empirical reason for the lowest-level part. When the problem population is that diverse, no central group can keep up with it.

The leader behavior that follows is small and easy to skip. After the fix, somebody has to ask why it happened, and somebody has to have the time, the skill, and the coaching to answer.

What the study doesn't tell us

All seventeen plants belong to one corporation, so this is a deep look at one company rather than a survey of many. Pancotto observed containment directly at the plants he visited and inferred its effects statistically, but he couldn't measure how much containment resource each plant was spending, because that data didn't exist. The fieldwork is automotive and roughly twenty years old.

None of that erases the pattern Pancotto documented. It does mean the honest version is that this is one well-documented case rather than a law.

What I don't know is how many of us could tell the difference in our own data. If your defect rate, your incident rate, or your turnaround time is improving right now, can you say which part came from somebody finding a cause and which part came from somebody catching the problem before it got out?

A guess about the company

Pancotto doesn't name the automaker, and he shouldn't. He signed a confidentiality agreement, gave the plants three-letter code names, and altered some of the problem-category data to protect the company.

But I was curious, so I asked Claude to read the dissertation and make a guess. Its guess was General Motors.

The reasoning is plausible: the principles the thesis lists for the company's production system, including standardization, continuous improvement, and built-in quality, line up closely with GM's Global Manufacturing System. So do the team leader and group leader structure and the timing of a rollout in which one plant was the designated model while another had barely started.

Ford also adopted Toyota-influenced production practices and similar language, so I wouldn't put much weight on the guess. I have no way to confirm the guess and no interest in trying. The finding doesn't depend on the badge.

Back to the point at hand

Before launching another Lean refresh, I'd go back to one problem we believe we solved and ask the people doing the work what they still have to do to keep it from reaching the customer. We might find that the improvement still depends on someone catching the same defect, finding supplies, or repeating a workaround.

That work matters. It protects customers and patients, and we should appreciate the people doing it. We should also examine the evidence that led us to call the problem solved. What changed in the process that produces the defect? A lower rate at the inspection station doesn't answer that by itself.

As a leader, I'd want to make that follow-up possible: give people time to investigate with someone who can coach them, then check whether the changes reduce the problem where it occurs. Keep the necessary containment in place while that work continues.

When someone reports that a “solved” problem is back, we have a reason to reopen the investigation. Before we ask the team to regain its momentum, we should understand how much of its time is still going into containing problems we thought were behind us.