Quality
and Chesterton’s Fence: When Your Organization Removes a Process Nobody
Understood — and Discovers Too Late That It Was the Only Thing Holding
Everything Together
The Fence You Never
Questioned
There’s a gate in every factory that nobody remembers installing. An
extra inspection step that appears redundant. A signature box on a form
that seems purely ceremonial. A temperature check that nobody can
explain. A quarantine hold that adds twelve hours to your lead time for
reasons that died with the engineer who designed it.
These are the fences of quality — the controls, checks, and
constraints that exist in every system without anyone being able to
articulate precisely why. They accumulate over years, sometimes decades.
They are the artifacts of lessons learned, crises survived, and
knowledge that was once urgent enough to codify into procedure but has
since faded into bureaucratic background noise.
And they are the first things to go when someone decides to
“streamline.”
G.K. Chesterton laid out the principle in 1929: “In the matter of
reforming things, as distinct from deforming them, there is one plain
and simple principle; a principle which will probably be called a
paradox. There exists in such a case a certain institution or law; let
us say, for the sake of simplicity, a fence or gate erected across a
road. The more modern type of reformer goes gaily up to it and says, ‘I
don’t see the use of this; let us clear it away.’ To which the more
intelligent type of reformer might well make answer: ‘If you don’t see
the use of it, I certainly won’t let you clear it away. Go away and
think. Then, when you can come back and tell me that you do see the use
of it, I may allow you to destroy it.’”
This is not conservatism dressed up as philosophy. This is a
diagnostic principle: the inability to explain why something exists is
not evidence that it shouldn’t. It is evidence that you don’t understand
your own system well enough to modify it safely.
In quality management, this principle is not a thought experiment. It
is a recurring catastrophe.
The Anatomy of an
Unexplained Fence
Every quality system has them. Walk into any manufacturing facility
with more than ten years of operating history and you’ll find processes
that have outlived their institutional memory. The incoming material
check that was added after a supplier shipped contaminated resin in 2011
— but the supplier was replaced in 2014 and the resin type was
discontinued in 2016. The dual-signature requirement on nonconformance
dispositions that was instituted after a suspiciously convenient
reclassification scandal that three managers still remember but nobody
talks about. The additional hardness test on a component that was added
because of a customer-specific requirement that expired when that
customer was lost in 2019.
Some of these fences are genuinely obsolete. The question is whether
you can tell the difference between the obsolete ones and the critical
ones — before you remove them.
The dangerous fences are not the ones with obvious purposes. The
dangerous ones are the ones whose purpose has become invisible precisely
because they work so well. The inspection that catches the defect you’ve
forgotten was possible. The parameter range that prevents a failure mode
that hasn’t occurred in so long that your FMEA lists it as “remote.” The
procedural step that was added after an escape that cost a customer $2
million and nearly cost you the relationship.
These controls are victims of their own success. They prevent the
problem so effectively that the problem disappears from organizational
consciousness. And then someone — usually someone competent, usually
someone well-meaning, usually someone with a spreadsheet showing cycle
time savings — asks the fatal question: “Why are we still doing
this?”
The Streamlining Trap
The pressure to remove unexplained fences comes from the best of
intentions. Lean initiatives. Cycle time reduction. Digital
transformation. Process simplification. The language is always positive:
“eliminate waste,” “remove non-value-added steps,” “empower the
operator,” “trust the process.”
And most of the time, the person proposing the removal is right. Most
of the fences in any quality system are obsolete. They were
reactions to specific conditions that no longer exist. They consume
time, add cost, and frustrate operators who have to perform actions that
feel meaningless. A rigorous review of any mature quality system will
reveal that a significant percentage of controls can be safely
eliminated.
But “most” and “all” are not the same word.
The distinction between the fences you can remove and the fences you
cannot is not found in whether the current team can explain them. It is
found in whether you have done the work to reconstruct the reasoning
that placed them there — and verified that the conditions that
necessitated them have genuinely changed.
This is where organizations fail. They confuse two fundamentally
different questions:
- “Can anyone explain why this exists?” — a question about current
knowledge - “Has the reason this was created been resolved?” — a question about
system state
The first question is easy to answer. You ask around, nobody knows,
and you conclude the fence is unnecessary. The second question requires
investigation. It requires digging into change histories, reviewing old
CAPA records, interviewing retired engineers, examining customer
complaint archives, and tracing the control back to its origin. It is
harder. It is slower. And it is the only question that matters.
The Paradox of Invisible
Prevention
The deepest problem with Chesterton’s Fence in quality systems is
that the most important fences are the hardest to see.
Consider a real scenario. An automotive supplier had, for twelve
years, an additional dimensional check on a critical machined surface —
a check that went beyond what the control plan required. It added ninety
seconds to every setup. Operators complained about it. Engineers
couldn’t find the engineering basis for it. The drawing tolerance was
±0.05mm, the process capability was 1.67, and the additional check
seemed redundant.
It was removed during a lean kaizen event. The team celebrated the
cycle time improvement.
Fourteen months later, a field failure. A safety-critical dimension
was drifting, and no one caught it because the additional check — the
one nobody understood — had been the only control that detected the slow
drift early enough to correct it. The Cpk of 1.67 was a historical
artifact; the process had shifted six months earlier due to a tooling
change, and the standard SPC chart hadn’t flagged it because the shift
was within control limits but crossed a functional boundary that the
original engineer had known about but never documented.
The additional check wasn’t redundant. It was the only control that
accounted for a failure mode known to one person — a person who had
retired three years before the kaizen event and had never been
debriefed.
The cost of the field failure was $4.2 million. The ninety seconds
saved per setup was worth approximately $18,000 per year.
The math of Chesterton’s Fence is asymmetrical: the cost of keeping
an unnecessary fence is typically small and ongoing. The cost of
removing a necessary one is typically catastrophic and delayed. This
asymmetry should inform the burden of proof.
The Right Way to Dismantle
Chesterton did not argue that fences should never be removed. He
argued that the threshold for removal should be understanding, not
ignorance. Applied to quality systems, this creates a practical
framework:
First, reconstruct the origin. Every control in your
system was added for a reason. Find it. Check CAPA databases, old
meeting minutes, engineering change orders, customer communications,
audit findings, and regulatory updates. If your documentation is poor —
and in most organizations it is — talk to the people who were there. The
tenured quality engineer who remembers “that thing with the German
customer in 2014” is a living archive. Use them before they retire.
Second, assess whether the condition still exists.
The reason for a fence may be obsolete. The supplier that shipped
contaminated material was replaced. The machine that had thermal drift
was rebuilt. The customer that required the extra check moved to a
different product. When the originating condition has genuinely been
resolved, the fence is a candidate for removal.
Third, verify through data, not opinion. Don’t ask
whether people think the control is necessary. Ask what the
data shows. If you remove an inspection step, can you demonstrate
through process capability, historical performance, and failure mode
analysis that the risk is controlled? If you eliminate a check, what is
the worst-case scenario, and how will you detect it?
Fourth, remove provisionally. Don’t delete —
suspend. Run a controlled trial where the fence is bypassed but the
output is monitored more closely. If no problems emerge over a
meaningful period — not weeks, but months or production cycles
sufficient to capture variation — then formalize the removal. If
problems emerge, you’ve lost nothing but a small amount of time.
Fifth, document the reasoning. Record why the fence
was originally installed, why it was removed, and what evidence
supported the decision. This documentation protects future teams from
re-learning the same lesson and creates the institutional memory that
prevents Chesterton’s Fence from recurring.
The Institutional Memory
Problem
Underlying the entire Chesterton’s Fence dynamic is a failure of
knowledge management. Organizations accumulate controls faster than they
accumulate understanding of those controls. The person who adds a
control typically understands its purpose deeply. The person who
inherits that control three years later sees only the procedure, not the
reasoning.
This is a documentation failure, but not the kind most organizations
think about. The issue is not missing procedures — most quality systems
are over-documented. The issue is missing rationale. Procedures
tell you what to do. Rationale tells you why. And the “why” is the first
thing lost to time.
The most resilient quality systems I’ve encountered share a common
trait: every control in the system has a documented reason for existing,
linked to a specific risk it mitigates. When the risk can be
demonstrated as resolved, the control can be removed with confidence.
When the risk persists, the control remains — even if nobody remembers
the original incident.
This is not complicated. It requires adding one field to your control
documentation: “Purpose.” Not the procedure’s name. Not its scope. Its
purpose — the specific failure mode, risk, or requirement it
addresses. With that single piece of information, Chesterton’s Fence
becomes a solvable problem instead of a recurring disaster.
The Dunning-Kruger Dimension
There is an uncomfortable overlap between Chesterton’s Fence and the
Dunning-Kruger effect. The people most confident in their ability to
identify unnecessary controls are often the people least familiar with
the system’s history. A newly hired process engineer with a fresh MBA
and enthusiasm for lean transformation is exactly the person who will
look at a twelve-year-old inspection step and see waste. And they will
be right — some of the time.
The expertise required to evaluate a control is not just technical
knowledge of the current process. It is historical knowledge of the
system’s evolution. It is awareness of the failures that shaped the
current state. It is respect for the accumulated wisdom embedded in
procedures that may look unnecessary but exist because someone —
possibly someone no longer with the company — learned a lesson the hard
way.
This is not an argument against new perspectives. Fresh eyes often
identify genuinely unnecessary controls that long-tenured employees
accept without question. The solution is not to resist change but to
demand rigor. You want fresh eyes and deep understanding. You
want the enthusiasm of the new engineer combined with the historical
knowledge of the quality veteran. Put them in the same room and let them
challenge each other.
The Customer’s Invisible
Requirements
Some fences exist not because of your failures but because of your
customer’s experiences — experiences they may not have shared with you.
I’ve encountered several instances where an additional control existed
because of a historical issue at the customer’s facility that your
company was never directly involved in, but that shaped the customer’s
requirements for all suppliers.
The customer may not even remember why they imposed the requirement.
It may be buried in a quality agreement that was signed a decade ago and
has been renewed automatically ever since. Remove the control without
understanding its origin, and you may be in contract violation — a
discovery that typically arrives in the form of a major nonconformance
during a customer audit.
Customer-imposed fences deserve special scrutiny because they carry
contractual weight even when the technical basis has evaporated. The
right approach is to engage the customer: “We’ve identified this control
and cannot trace its technical basis. Can you help us understand its
origin? If the underlying concern has been addressed, would you support
its removal?” Some customers will be grateful for the attention to
detail. Others will insist the control remain. Either way, you’ve
converted an unexplained fence into an understood one.
The Regulatory Fence
Regulatory fences are the most dangerous to remove because the
consequences extend beyond your organization. A control that exists to
satisfy a regulatory requirement — even one that seems outdated or
overly conservative — carries legal and compliance weight that doesn’t
diminish with time.
The trap is that regulatory requirements are not always labeled
clearly. A control added to satisfy an FDA observation, a TÜV
requirement, or an IATF 16949 finding may not be obviously regulatory in
nature. It may look like an internal best practice, leading an
improvement team to remove it without recognizing the compliance
exposure.
Before removing any control, check its regulatory pedigree. Was it
added in response to an audit finding? A customer-specific requirement
linked to a regulatory framework? A corrective action with regulatory
implications? If the answer is yes — or if you can’t determine the
answer — the fence stays until you can demonstrate compliance without
it.
Building a Fence-Aware
Culture
The long-term solution to Chesterton’s Fence is not better removal
procedures. It is better building procedures. Every new control
added to the system should carry its rationale forward:
-
Link controls to risks. Every inspection, test,
sign-off, and hold in your system should be traceable to a specific risk
it mitigates. This creates a living map of your quality
defenses. -
Assign ownership of rationale. The person who
adds a control is responsible for documenting its purpose. Make this a
non-negotiable part of the change process. -
Review periodically. Build an annual review into
your management review process where the oldest controls are examined
for continued relevance. This is not a lean exercise — it is a knowledge
preservation exercise. -
Create a “control genealogy.” Maintain a living
document that traces the history of your major quality controls: when
they were added, why, by whom, and what would happen if they were
removed. This is the institutional memory that prevents the next
generation from learning the same lessons the hard way. -
Test your fences. For controls that appear
unnecessary, run the provisional removal test. Monitor the output. If
nothing changes, the control was probably obsolete. If something changes
— even something small — you’ve just discovered the purpose of a fence
you didn’t understand.
The Humility of Quality
Chesterton’s Fence, at its core, is about epistemic humility. It is
about recognizing that your inability to explain something is a
statement about your knowledge, not about the thing itself. In quality
management, this humility is not optional — it is the difference between
continuous improvement and inadvertent destruction.
Every time you look at a control and think “that’s unnecessary,” you
are making a claim about your understanding of the system. The question
is whether that claim is justified. Can you explain not just what the
control does, but why it was added? Can you trace the chain of events
that led to its creation? Can you demonstrate that the conditions
requiring it have changed?
If you can, remove it with confidence. If you can’t, you have work to
do — and the fence stays until the work is done.
The most resilient quality systems are not the ones with the most
controls. They are the ones where every control is understood. Where the
purpose of each fence is visible, documented, and regularly challenged
by people with the knowledge and humility to know the difference between
streamlining and dismantling.
Your quality system is not a collection of procedures. It is a
repository of hard-won knowledge, encoded in controls that protect
against failures your organization has experienced, anticipated, or
inherited. Removing any of those controls without understanding what
knowledge they carry is not improvement. It is amnesia dressed up as
efficiency.
Go look at your system today. Find the fences nobody can explain. And
before you touch any of them, remember Chesterton’s warning: the fact
that you don’t see the use of something is not an argument for its
removal. It is an argument for your own deeper investigation.
The fence you save may be the one that saves you.
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 balance rigorous control with operational efficiency — and in
helping organizations understand that the controls they inherit are
often the most valuable ones they have.
