Quality
and Chesterton’s Fence: When Your Organization Removes a Process Step
Without Understanding Why It Was Put There — and the Safeguard Nobody
Remembered Installing Became the Failure Nobody Saw Coming
Peter Stasko — Quality Architect, 25+ years in manufacturing
excellence
The Parable of the Fence
There is an old principle attributed to the English writer G.K.
Chesterton that goes something like this: before you tear down a fence,
you should first understand why it was built. It sounds almost too
simple to be worth stating. And yet, in manufacturing and quality
management, violating this principle has caused more catastrophic
failures than almost any other cognitive error I have witnessed in a
quarter century of consulting across automotive, aerospace, medical
devices, and electronics.
Organizations are constantly under pressure to simplify, streamline,
reduce cycle time, and cut costs. These are legitimate goals. Lean
manufacturing and continuous improvement demand them. But there is a
critical difference between eliminating waste and eliminating safeguards
you simply do not recognize as safeguards. The first is improvement. The
second is catastrophe waiting to happen.
I have watched engineers remove inspection steps because “we haven’t
found a defect here in three years” — not realizing that the absence of
defects was the direct result of that inspection step existing. I have
seen managers delete process parameters from control plans because
“nobody knows why those are there” — not realizing that the person who
put them there retired five years ago and took the institutional memory
with them. I have observed entire layers of quality control stripped
away during cost reduction initiatives, only for the organization to
discover, eighteen months later, that those layers were the only thing
standing between normal variation and a full product recall.
This is Chesterton’s Fence in action. And it is one of the most
expensive lessons an organization can learn.
Why the Fence Gets Torn Down
Understanding why organizations repeatedly fall into this trap
requires understanding the forces that drive the behavior. It is not
stupidity. It is not carelessness. It is a confluence of systemic
pressures and cognitive blind spots that make removing the fence feel
not just reasonable but necessary.
The Pressure to Simplify
Lean manufacturing teaches us to eliminate waste. Six Sigma teaches
us to reduce variation. Continuous improvement teaches us to question
everything. These are powerful philosophies that have transformed
manufacturing for the better. But they come with an implicit assumption:
that the people doing the eliminating can correctly distinguish between
waste and value-added activity. When they cannot — when a process step
looks like waste but is actually a critical safeguard — the improvement
becomes a degradation.
The pressure to simplify is compounded by the fact that the people
making the decisions are often several layers removed from the process
floor. A value stream map drawn in a conference room does not always
capture the tacit knowledge embedded in a process step that an operator
has been performing for a decade without anyone documenting why.
The Tyranny of the Recent
Organizations suffer from a chronic inability to remember their own
history. The quality engineer who designed a process fifteen years ago
is gone. The failure mode and effects analysis that justified a
particular inspection step is buried in a document control system nobody
has logged into for years. The customer complaint that triggered the
addition of a process parameter is a faint memory, if it is remembered
at all.
When the institutional memory of why something exists has been lost,
the thing itself becomes vulnerable. It looks arbitrary. It looks
unnecessary. It looks like a candidate for removal. And because the
organization has no easy way to recover the reasoning behind it, the
removal proceeds without objection.
The Metrics Trap
Modern quality systems are metric-driven. If something cannot be
measured and linked to a key performance indicator, it tends to be
questioned. But some safeguards are preventive rather than detective.
They do not catch defects — they prevent them from occurring in the
first place. And prevention is notoriously difficult to measure.
How do you measure the number of defects that did not happen because
of a process step? You cannot. You can only measure what did happen. And
when a preventive step has been doing its job effectively for years, the
data shows nothing: no defects, no escapes, no customer complaints. This
absence of evidence is then interpreted as evidence of absence. The step
looks useless. The fence looks unnecessary.
Anatomy of a Fence Removal
Let me walk through a pattern I have seen repeat across dozens of
organizations, in different industries, on different continents. The
details change, but the structure remains remarkably consistent.
Phase One: The Observation
Someone — often a new engineer, a consultant, or a manager recently
transferred from another department — notices a process step that seems
redundant. It might be a secondary inspection, an additional torque
verification, a redundant cleaning step, or a process parameter that
seems to duplicate information already captured elsewhere. They ask
around. Nobody can clearly articulate why the step exists. The
documentation is vague or missing. The operator performing the step
shrugs and says, “I’ve always done it this way.”
Phase Two: The Justification
The observation escalates into a proposal. The step is classified as
non-value-added. A time study shows it adds forty-five seconds to the
cycle time. A cost analysis shows it consumes labor hours that could be
redirected. A comparison with industry benchmarks shows that competitors
do not perform this step. The proposal to remove it is supported by
data, logic, and the prevailing improvement methodology.
Phase Three: The Removal
The step is removed, typically as part of a larger process
optimization initiative. The change is documented in a revision to the
control plan. Operators are retrained. The line runs faster. Cycle time
drops. Labor cost decreases. The metrics improve. The team
celebrates.
Phase Four: The Latent Period
For a while — sometimes months, sometimes years — nothing visibly
changes. The process continues to produce conforming product. Customer
complaints do not spike. The metrics remain stable. The organization
concludes that the removal was successful. The lesson is generalized: if
this step could be removed without consequence, perhaps others can be
too.
Phase Five: The Failure
Then something shifts. A supplier changes a raw material formulation.
A machine ages past a maintenance threshold. A new operator with
slightly different technique joins the line. An environmental condition
— humidity, temperature, vibration — drifts outside its normal range.
The latent variation that the removed step was quietly absorbing now has
nowhere to go. Defects appear. Customer complaints escalate. An internal
investigation begins. And the root cause analysis traces back to the
step that was removed years ago — the step whose purpose nobody had
documented, whose function nobody had understood, and whose absence
nobody had thought to question.
The Institutional Memory
Problem
At the heart of Chesterton’s Fence in quality management lies the
problem of institutional memory. Every process in a manufacturing
environment is the product of years — sometimes decades — of accumulated
knowledge, lessons learned, and responses to specific failures. But this
knowledge is rarely captured in a form that survives personnel turnover,
organizational restructuring, and the natural decay of documentation
systems.
Tacit Knowledge
vs. Explicit Knowledge
Most of the reasoning behind process steps exists as tacit knowledge
— knowledge that lives in the heads of experienced operators and
engineers. They know that a particular temperature range matters because
they remember the batch that failed when the oven drifted above it in
2014. They know that a secondary visual inspection catches a specific
defect mode that the automated system misses because they personally
found three units last year. But this knowledge is not written down
because it feels obvious to the people who hold it. It is only when
those people leave that the knowledge gap becomes visible — and by then,
it is often too late.
The Documentation Gap
Quality systems require documentation. Process flow diagrams, control
plans, failure mode and effects analyses, work instructions — these are
all standard elements of a compliant quality management system. But the
quality of this documentation varies enormously. In many organizations,
the FMEA that originally justified a process step was written as a
compliance exercise, not as a genuine engineering analysis. The control
plan lists the step but does not explain the reasoning behind it. The
work instruction describes what to do but not why.
When the “why” is missing from the documentation, the step itself
becomes a Chesterton’s Fence — a structure whose purpose is not
immediately apparent to anyone who was not involved in its creation.
The Generational Transfer
Failure
Manufacturing organizations face a demographic challenge that
exacerbates the Chesterton’s Fence problem. Experienced engineers and
operators are retiring in large numbers, and the knowledge transfer to
the next generation is often incomplete. The new engineer inherits a
process they did not design, documentation they did not write, and a set
of practices whose origins are lost to history. They are expected to
improve the process — but they are improving something they do not fully
understand.
This is not a criticism of new engineers. It is a systemic failure of
organizational knowledge management. The fence was built by people who
are no longer there. The reasons for building it died with their
departure. And the people who inherited the fence are under pressure to
justify every cost, every cycle time increment, every non-value-added
activity.
Recognizing the
Fences in Your Organization
Not every process step is a fence worth preserving. The challenge is
distinguishing between genuine safeguards and actual waste. Here are the
patterns that should trigger extra scrutiny before removal.
Steps That Were
Added After a Specific Failure
If you can trace a process step back to a corrective action — a
customer complaint, an internal rejection, an audit finding — it is
likely a fence. The fact that it has not caught a defect recently does
not mean it is unnecessary. It may mean it is working exactly as
intended.
Steps That Involve
Redundancy
Redundant inspections, duplicate measurements, and secondary checks
often look wasteful on the surface. But redundancy in quality systems is
usually intentional. It exists because the primary control has a known —
or suspected — failure rate. Removing the redundancy removes the safety
net.
Steps With No Clear Owner
If nobody in the organization can explain why a step exists, that is
not evidence that the step is unnecessary. It is evidence that the
organization has lost the knowledge of why it was put there. This is
precisely the situation where Chesterton’s principle demands
caution.
Steps That Are
Expensive or Time-Consuming
The steps that are most tempting to remove are the ones that cost the
most — in time, labor, or materials. But cost is not a proxy for lack of
value. The most expensive step in your process may also be the most
important one. The cost of the step should be weighed against the cost
of the failure it prevents, not against the budget target of the
quarter.
A Framework for Responsible
Removal
Chesterton’s principle does not mean that no fence should ever come
down. It means that the burden of proof should be on the person
proposing removal, not on the person defending retention. Here is a
practical framework.
Step One: Recover the
Rationale
Before removing any process step, make a genuine effort to understand
why it was added. Review historical FMEAs. Search corrective action
databases. Interview experienced operators and retired engineers if
possible. Check customer complaint records from the period when the step
was introduced. The goal is not to find a reason to keep the step — it
is to find the truth about why it exists.
Step Two: Assess the Risk
If the rationale cannot be fully recovered, apply a precautionary
risk assessment. What failure modes could this step be preventing? What
would be the consequence if those failure modes occurred? What is the
likelihood that conditions have changed enough to make those failure
modes irrelevant? Be honest about what you do not know.
Step Three: Test Before You
Commit
If you decide to remove the step, do it as a controlled experiment,
not a permanent change. Remove it temporarily. Monitor the process
closely. Track not just defect rates but also leading indicators —
process variation, capability indices, near-miss reports. Set a defined
review period. If nothing changes, you have data to support the removal.
If something changes, you have an early warning before the damage
becomes irreversible.
Step Four: Document
Everything
If you remove the step, document the reasoning, the data, and the
risk assessment that supported the decision. If you keep the step,
document why it is there so the next person does not have to ask. Every
fence should have a sign explaining its purpose.
Step Five:
Build Knowledge Transfer Into the System
The long-term solution to Chesterton’s Fence is not to never remove
fences. It is to ensure that the reasoning behind every process step is
captured, maintained, and accessible. This means investing in knowledge
management systems that go beyond compliance documentation. It means
creating cultures where experienced people are incentivized to share
what they know. It means treating institutional memory as the asset it
is.
The Bigger Picture:
Humility in Improvement
There is a deeper lesson in Chesterton’s Fence that goes beyond
process steps and quality systems. It is a lesson about humility. The
assumption that we can look at a system, quickly identify what is
unnecessary, and remove it without consequence is an assumption of
omniscience. It assumes that if we do not understand something, it must
not have a purpose.
But complex systems — and manufacturing processes are complex systems
— contain interdependencies that are not always visible. Actions have
second-order and third-order effects. A step that seems pointless in
isolation may be critical in the context of the whole system. A
parameter that seems arbitrary may be compensating for an upstream
variation that is not being monitored.
The best quality engineers I have worked with share a common trait:
they are slow to remove and quick to investigate. They treat every
process step as a potential safeguard until they have positive evidence
that it is not. They ask “why does this exist?” before they ask “can we
remove this?” They respect the accumulated wisdom of the system, even
when that wisdom is not immediately apparent.
This is not conservatism. This is engineering discipline. And in a
world where the cost of a single quality failure can dwarf the savings
from a hundred successful process optimizations, it is also sound
economics.
Practical Takeaways
-
Before removing any process step, invest time in
understanding why it was added. The absence of an obvious
reason does not mean there is no reason. It may mean the reason has been
forgotten. -
Treat long-standing process steps as hypotheses worth
testing, not as waste worth eliminating. Run controlled
experiments before making permanent changes. -
Document the “why,” not just the “what.” Every
process step in your control plan should have an accompanying rationale
that survives personnel turnover. -
Beware the silence of successful prevention. A
step that produces no defects, no findings, and no incidents may be the
most valuable step in your process — precisely because it is
working. -
Respect institutional memory. When experienced
people leave, they take knowledge with them. Invest in capturing that
knowledge before it walks out the door. -
Apply the precautionary principle when the rationale is
lost. If you cannot determine why a step exists, the default
should be to keep it, not to remove it.
Conclusion
Chesterton’s Fence is not an argument against improvement. It is an
argument for understanding before action. In quality management, the
stakes are too high for anything less. Every process step is a decision
someone made in response to a specific set of circumstances. Those
circumstances may still be relevant. That decision may still be correct.
And the fence that looks pointless today may be the one standing between
your organization and the failure it was built to prevent.
The next time you look at a process step and think, “Why do we do
this?” — stop. That question is the right one. But the next step should
be to find the answer, not to eliminate the question. The fence may be
old, it may be ugly, and it may seem to serve no purpose. But before you
tear it down, make sure you understand what it was keeping out.
Because in quality, the fences we remove without understanding are
the ones we end up rebuilding after the damage is done — at ten times
the original cost, with a customer who will never fully trust us
again.
Peter Stasko is a Quality Architect with over 25 years of
experience in manufacturing excellence across automotive, aerospace,
medical device, and electronics industries. He specializes in helping
organizations build quality systems that are not just compliant but
genuinely effective — systems that prevent failures rather than just
detecting them after the fact.
