Quality and Chesterton’s Fence: When Your Organization Removes a Process Step It Doesn’t Understand — and the Defect Rate That Was Under Control Becomes the Crisis Nobody Predicted

Uncategorized

Quality
and Chesterton’s Fence: When Your Organization Removes a Process Step It
Doesn’t Understand — and the Defect Rate That Was Under Control Becomes
the Crisis Nobody Predicted

There is a scene that plays out in manufacturing plants around the
world, several times a year, and it always follows the same script.

A new engineer joins the team. They review the process documentation.
They walk the line. They study the control plan. And then they point to
a step that makes no sense — an extra inspection, a redundant
verification, a seemingly pointless signature, a hold point that adds
twelve minutes to a cycle time that everyone agrees is already too
long.

“Why is this here?” they ask.

Nobody knows. The operator doesn’t know. The supervisor doesn’t know.
The quality engineer who wrote the control plan three years ago has
moved to another plant. The manager who approved it retired. The
original audit finding that triggered it is buried in a SharePoint
folder that nobody has opened since 2019.

“It’s probably legacy,” someone says. “I don’t think it’s needed
anymore.”

And so they remove it.

For two weeks, everything looks fine. The cycle time improves. The
team celebrates. The new engineer gets recognized for streamlining the
process. The productivity dashboard shows a beautiful green arrow
pointing upward.

Then, three weeks later, a customer finds a defect that hasn’t
appeared in four years. Then another. Then a third. The containment team
scrambles. The root cause investigation traces the failure back to the
exact step that was removed. The reaction is always the same: How
were we supposed to know that’s what it was for?

This is Chesterton’s Fence. And if you work in quality, it has
already happened in your organization — or it is about to.

The Original Principle

The writer G.K. Chesterton laid out the idea in his 1929 book The
Thing
. He described it as a fence in a field — you see it, you
don’t know why it’s there, and your first instinct is to tear it down.
His argument was simple and devastating: don’t remove the fence
until you understand why it was built.

The fence might be keeping livestock off a cliff edge. It might be
marking a property boundary that prevents a legal dispute. It might be
protecting a ground-nesting bird population. It might have been put
there for a reason that is invisible to you but critical to someone
else.

In manufacturing, the “fences” are everywhere. They are the extra
torque checks, the redundant sign-offs, the seemingly pointless gauging
steps, the hold points, the additional cleaning procedures, the warning
labels, the torque-to-yield bolts, the safety wires, the double-seals.
They are all the process elements whose purpose has been forgotten by
the people who currently operate the system.

And they are the most endangered species in any lean
transformation.

Why This Happens in Quality
Systems

The dynamic is almost mechanical in its predictability. Here is how
it unfolds:

First, institutional knowledge erodes. The people
who designed the process move on. They take new roles, retire, change
companies. The documentation they leave behind captures what
the process does but rarely captures why. Control plans list
inspection steps. Work instructions describe procedures. But the
reasoning — the specific failure that prompted the step, the customer
complaint that triggered the requirement, the regulatory finding that
demanded the control — that context lives in people’s heads, and people
are temporary.

Second, the process works. This is the cruel irony.
When a quality control is effective, it prevents the problem it was
designed to catch. Over time, the problem stops appearing. And when a
problem never appears, people begin to question whether the control was
ever necessary. We haven’t had that defect in three years — do we
really need to keep checking for it?
The control’s own success
becomes the argument for its elimination.

Third, cost pressure creates the motive. Every
process step has a cost — in time, in labor, in materials, in cycle
time. In a competitive environment, there is constant pressure to reduce
cost and increase throughput. Steps that seem unnecessary are
low-hanging fruit. They are easy to identify, easy to remove, and the
savings are immediate and measurable. The risk, by contrast, is abstract
and uncertain. “We might have a defect someday” is a hard sell against
“we’ll save forty-seven seconds per unit starting Monday.”

Fourth, the people making the decision are not the people who
will deal with the consequences.
The engineer who removes the
step gets promoted for improving productivity. The operator who catches
the fallout is three levels below them. The quality manager who has to
manage the containment is in a different department. The customer who
receives the defective product is in another country. The disconnect
between decision-maker and consequence-bearer is what makes Chesterton’s
Fence so persistent and so dangerous.

The Real-World Cost

I once consulted for a tier-one automotive supplier that manufactured
fuel injection components. Their process had a step where an operator
visually inspected each unit under a specific angle of light after a
surface treatment operation. The step added about fifteen seconds per
part, and it had been in the process for over a decade.

A new production manager looked at the data and noted that the visual
inspection had not caught a defect in over two years. The surface
treatment process had been improved, the defect rate for that particular
failure mode was essentially zero, and the inspection was consuming
operator time that could be used elsewhere. He removed it.

Within six weeks, three customer plants reported contamination
failures in the fuel system. The root cause was a subtle residue that
the surface treatment occasionally left on specific batches of raw
material — a condition that the visual inspection under angled light was
specifically designed to detect. The failure had been so rare that most
operators had never actually caught it, but the inspection was the only
barrier between that residue and the customer’s fuel rail.

The recall cost was in the seven figures. The customer audit that
followed took three months. The corrective action — which was to
reinstate the exact same visual inspection — took one afternoon.

The original reason for the inspection was documented in a quality
alert from eleven years earlier. It was three paragraphs long. Nobody
had read it.

The Lean Paradox

This creates a genuine tension in lean manufacturing, because lean
methodology actively encourages the elimination of waste. And from a
pure process perspective, a step that never catches anything looks
exactly like waste.

The paradox is this: a process step that prevents a problem
and a process step that does nothing can look identical in the
data.
If a control is perfectly effective, the defect rate for
the failure mode it addresses will be zero. If a control is completely
unnecessary, the defect rate for the failure mode it addresses will also
be zero — because there was no failure mode to begin with. You cannot
distinguish between the two by looking at outcomes alone.

This means that traditional lean tools — value stream mapping, waste
elimination, cycle time reduction — will flag both steps for removal.
Without understanding the purpose behind each step, you are just as
likely to remove a critical safeguard as a genuine waste.

The solution is not to stop eliminating waste. The solution is to
understand before you remove.

A Practical Framework

If your organization is going to streamline processes — and it should
— here is a framework that respects Chesterton’s Fence:

1. Document the “Why,” not just the “What.” Every
control plan, every work instruction, every process step should include
a brief explanation of why it exists. What failure mode does it address?
What customer requirement does it satisfy? What regulation does it
comply with? What historical problem does it prevent? This context is
not optional documentation — it is the difference between informed
improvement and reckless cutting.

2. Before removing any process step, require a purpose
analysis.
Ask three questions: Who put this step here? What
problem was it solving? Is that problem still relevant? If you cannot
answer all three, you are not ready to remove it. This is not
bureaucracy — it is due diligence.

3. Check institutional knowledge before checking
data.
Before you look at defect rates and cycle times, talk to
the people who have been on the line the longest. Operators,
technicians, veteran quality engineers — they carry context that no
database holds. They may know that the extra torque check exists because
of a specific batch of bolts that showed up in 2017 with inconsistent
hardness. They may know that the redundant signature exists because a
previous customer required dual verification on safety-critical
dimensions. This knowledge is perishable. Capture it before it’s
gone.

4. Pilot removals with containment. If you believe a
step can be safely removed, don’t remove it everywhere at once. Remove
it on one line, for one shift, with increased inspection downstream.
Monitor for ninety days, not two weeks. Some failure modes are rare
enough that they won’t appear in a fortnight but will appear within a
quarter. A pilot gives you data without giving your customer a
defect.

5. Make the cost of removal visible. When someone
proposes removing a step, document the assumed risk alongside the
expected savings. “Removing this inspection saves 47 seconds per unit
but removes our only detection point for residue contamination from the
surface treatment process. Current failure rate for this mode: unknown,
as it has been controlled for 11 years.” This transparency forces better
decisions.

6. Build a “fence registry.” For critical process
steps, maintain a living document that records the origin, purpose, and
current relevance of each control. Review it annually. Steps whose
purpose is genuinely obsolete can be safely removed. Steps whose purpose
remains relevant are preserved. Steps whose purpose is unclear are
flagged for investigation, not elimination.

The Deeper Lesson

Chesterton’s Fence is ultimately about humility — the recognition
that the absence of an obvious purpose does not mean the absence of a
purpose. In quality systems, this humility is essential.

Every process is a repository of lessons learned. Each step, each
control, each seemingly redundant verification was put there for a
reason. That reason may be obsolete. It may be redundant. It may be
completely unnecessary. But you do not know which until you
investigate.

The organizations that struggle most with quality are not the ones
that lack tools or techniques. They are the ones that keep learning the
same lessons — because they keep removing the controls that previous
lessons installed.

The fence is not the problem. Forgetting why the fence was built is
the problem. And in quality management, the most expensive mistake you
can make is not the improvement you failed to implement — it is the
safeguard you removed because you forgot what it was protecting.


Peter Stasko is a Quality Architect with 25+ years
of experience transforming organizations across automotive, aerospace,
and pharmaceutical industries. He specializes in building quality
systems that don’t just meet standards — they outlast the people who
designed them.

Scroll top