Chesterton's Fence: The BPR Communication Trap That Kills Good Transformations

Chesterton's Fence: The BPR Communication Trap That Kills Good Transformations
TL;DR: In business process reengineering, the process nobody can justify is not automatically waste. Long-lived rules often survive because they hold invisible load — trust, liability, status, handoff discipline, exit costs. The trap is communication: clients argue from origin stories and surface friction, while the real function has already migrated. Stop asking "why was this built?" Start asking "what fails the week after we remove it?"
I am James, CEO of Mercury Technology Solutions. Hong Kong — August 2026
I have run a lot of BPR with clients.
Different industries. Different maturity. Same scene on loop:
A room full of smart people. A whiteboard covered in process maps. Someone points at a step and says, "This is stupid. Nobody knows why we do this. Kill it."
Heads nod. The energy in the room spikes. Progress feels imminent.
That is usually the moment the project starts dying.
Not because change is wrong. Because the room just walked into Chesterton's Fence without noticing, and the communication pattern around that fence is designed to produce confident, expensive mistakes.
The Fence
G.K. Chesterton's version is simple.
A reformer walks a country road, sees a fence, and decides it is useless. Tear it down. Chesterton stops him: fine — after you explain why it was put there. Once you understand the original reason, then we talk about removal.
Most people treat this as basic caution. Don't delete what you don't understand.
That reading is too shallow.
Chesterton's Fence is not a conservation slogan. It is an epistemology for living systems.
The hard part is not "don't touch old things." The hard part is realizing that the reason a thing still exists is almost never the reason it was created.
The BPR Version of the Same Mistake
In client rooms, the reformer sounds modern:
• "This approval chain is bureaucracy."
• "This dual-check is redundant."
• "This weekly meeting creates no decisions."
• "This form is pure friction."
• "This exception process is legacy thinking."
All of that can be true on the surface.
And still incomplete.
Because BPR teams usually interrogate a process with the wrong question set:
1. What was this designed to do?
2. Does anyone here still believe in that purpose?
3. Can we measure its current value in a dashboard?
If the answers are "unclear / no / not really," the process gets marked for death.
That is the communication trap.
People defend processes with origin stories. Systems keep processes for current ecological function.
Those are different things.
A necktie was once a practical cloth for soldiers — warmth, sweat, unit recognition. Nobody wears one today to wipe their face. The origin died centuries ago. The object survived because it grew a new job: status signal, occasion marker, identity compression in a sea of identical suits.
Same pattern in operations.
A dual-approval flow may have started as fraud control after one bad incident in 2014. Today, the fraud tool stack already covers that risk. But the dual-approval now carries a different load: political cover between departments, audit narrative for external parties, forced slowing of high-ego decision makers, and a social contract that says "nobody ships alone."
If you kill it because the 2014 story is dead, you may be correct about history and wrong about the system.
Why Communication Makes This Worse
BPR fails less often on process design than on how people talk about process design.
I keep seeing four traps.
Trap 1: Silence Gets Treated as Evidence
If nobody can defend a step in the workshop, the team treats silence as proof of waste.
Silence is not proof.
Silence often means:
• the people who know the real reason left the company
• the function is distributed across three teams, so no single owner can narrate it
• the value only appears under rare failure modes, not in weekly operations
• the rule is socially expensive to defend ("this exists because we don't fully trust each other")
In other words, the most important fences are the ones people are least willing to explain cleanly.
Trap 2: Local Pain Outvoteses Systemic Load
The person closest to the friction speaks loudest.
They feel the delay. They feel the rework. They feel the "why do I need three signatures?" humiliation.
What they do not feel — or do not own — is the incident the process prevents once every 18 months, the regulator conversation it makes survivable, or the internal civil war it suppresses.
BPR workshops overweight local pain and underweight low-frequency catastrophic load. That is a communication bias, not an analytical one.
Trap 3: Rational Explanation Destroys the Mechanism
Some rules work because they are hard to justify in pure utility language.
This is the costly-signaling layer.
A wedding that costs a year of income is "irrational" as a party budget. As a commitment device, the public cost is the point. Easy exit is not commitment. Expensive, witnessed, hard-to-reverse ritual is.
Organizations run on the same physics.
• Mandatory onsite rituals that look inefficient
• Rigid escalation paths that look theatrical
• Documentation standards that look obsessive
• Client communication templates that look bureaucratic
If you successfully reduce them to "optional best practice," you convert a non-negotiable commitment into a situational strategy. Situational strategies die by a thousand reasonable exceptions.
Once a fence becomes fully explainable as convenience, it stops functioning as constraint.
That is why smart reformers crash here. Smart people are trained to destroy anything they cannot justify in a clean sentence. They miss that "cannot be cleanly justified" is sometimes the feature.
Trap 4: Origin Debates Replace Failure-Mode Design
Clients love origin debates because they feel rigorous.
"Who created this?" "When?" "Under what policy?" "Is the policy still active?"
Useful archaeology. Bad decision engine.
The decision engine is:
• What breaks in week one if this disappears?
• What breaks in month six?
• Who absorbs the new risk?
• What informal workaround will appear by Friday?
• Does our replacement actually carry the hidden load, or only the visible step?
If you cannot answer those, you are not redesigning a process. You are cosplaying efficiency.
Bring in the Lindy Filter
There is a second tool that pairs cleanly with Chesterton's Fence: the Lindy Effect.
For things that do not naturally age the way bodies do — books, institutions, protocols, operating norms — longevity is information. A play that has run 100 days is more likely to run another 100 than a play that has run 10. A practice that survived 30 years of management fads, system migrations, reorgs, and hero-CEO cycles is carrying more proof than a three-year "transformation initiative."
Apply it to BPR:
• A three-year process may be someone's ego fossil. Interrogate hard.
• A thirty-year process is embedded in an ecology you partially see. Interrogate harder, cut slower.
• A process that repeatedly survived "let's kill this" campaigns is not surviving by accident. Every failed assassination attempt is data.
Age is not sacred. Age is a prior.
The older the fence, the stronger your burden of proof before demolition.
What Survives Is Not What Was Designed
This is the line I want burned into every BPR kickoff:
**The reason something still lives is almost never the reason it was born.**
Institutions mutate function the way biology does.
A monarchy that once meant conquest and divine right can later become a nonpartisan container for national identity. Remove it because the original theology is dead, and you may create a vacuum that party politics immediately fills.
Same in companies.
• The "pointless" weekly ops call is no longer a status meeting. It is the only cross-functional immune system left after Slack fragmented attention.
• The "redundant" paper trail is no longer operational necessity. It is litigation armor.
• The "outdated" client communication protocol is no longer about fax-era constraints. It is a trust ritual that prevents sales from overpromising in freeform chaos.
• The "overstaffed" dual ownership model is no longer inefficiency. It is succession insurance and internal checks against single-point corruption.
If your BPR language only measures throughput, you will classify load-bearing structure as waste.
The Hidden Fences Are the Real Ones
Physical process maps are the easy layer.
The dangerous layer is unwritten:
• who can challenge whom in a meeting
• which client requests get a same-day yes
• how bad news travels upward
• what "urgent" actually means in this culture
• which metrics people game and which ones they fear
• the half-second pause before someone contradicts a founder
These are fences too.
They keep the social machine from tearing itself apart. They are rarely documented. So transformation teams treat them as nonexistent.
Then the new process launches, the hidden fences collapse, and everyone is shocked that "change resistance" appeared out of nowhere.
It did not appear out of nowhere. You demolished load-bearing walls and called the dust "culture issues."
The Opposite Failure: Fence Worship
I am not arguing for process religion.
Fence worship is how incumbents launder privilege.
Every rent-seeker eventually learns the sentence: "You don't understand why this exists."
Sometimes that sentence is wisdom. Sometimes it is a shield for dead weight, captured workflow, and career insurance.
Some fences must come down. Slavery. Caste. Bound feet. Corporate equivalents exist: humiliation rituals dressed as "standards," bottleneck roles protected by mystique, approval chains whose only product is status.
If every generation refuses to act until full comprehension arrives, nothing reforms. Full comprehension never arrives. Complex systems do not grant clean omniscience before action.
So the real posture is harder than both extremes:
See the hidden structure. Then still decide.
Responsible reformers live in contradiction. They can perceive invisible supports and still say, "This must change, and I will own the unpredictable consequences."
Irresponsible reformers only see friction. Reactionary operators only see tradition. Operators worth hiring can hold both.
A Working Protocol for BPR Rooms
When a client points at a process and says "this is nonsense," I run a tighter sequence.
1. Separate Origin from Function
Write two columns on the board:
• Why it was created
• Why it still consumes oxygen
If the room can only fill column one, you are not ready to cut.
2. Hunt the Rare Failure, Not the Average Day
Ask: "Tell me about the last time this saved us, embarrassed us, or delayed a disaster."
Average-day analysis kills low-frequency high-severity controls.
3. Price the Silence
If nobody can explain the fence, do not celebrate clarity. Assign an investigation owner. Silence is a research ticket, not a demolition permit.
4. Map the Substitute Load
Before removal, force an explicit answer: which part of the new design carries each hidden function — trust, auditability, escalation, deterrence, training, political cover?
If the answer is "the new tool will handle it," demand the mechanism. Tools do not automatically inherit social functions.
5. Use Age as a Prior, Not a Verdict
New process, weak evidence of value: bias to cut. Old process, repeated survival: bias to instrument first, cut second.
6. Run a Controlled Demolition
Time-box the removal. Define rollback conditions before you start. Watch what informal processes spawn in the gap. The workaround that appears after deletion is often the real function confessing itself.
7. Protect Costly Signals on Purpose
If a ritual's power comes from being expensive, public, and hard to reverse, do not "streamline" it into a checkbox. Either keep the cost or admit you are choosing weaker commitment.
The Communication Standard I Want Clients to Use
Stop saying:
• "Nobody knows why this exists, so remove it."
• "This creates friction, so it is bad."
• "We can't measure it, so it has no value."
• "The original policy is obsolete, so the process is obsolete."
Start saying:
• "We cannot yet see the current function."
• "This friction may be the control surface."
• "Our metrics may be blind to the load this carries."
• "Origin death is not function death."
That shift sounds semantic. It is not.
It changes the emotional temperature of the room from crusade to engineering.
And BPR is engineering, or it is vandalism with better slide decks.
What This Means If You Are Leading a Transformation
If you are a CEO, COO, or transformation lead, your job is not to collect a body count of deleted steps.
Your job is to increase the system's ability to create value without catastrophic side effects.
That requires a different kind of courage than the consultant-theater version.
Consultant-theater courage says: "Be bold. Challenge everything. Kill sacred cows."
Actual courage says: "I can see the cow is sacred for a reason I only partially understand — and I am still accountable for whether the farm functions after I move it."
Or, in the other direction: "This sacred cow is a costume for rent extraction, and I will remove it knowing the priests will call me reckless."
Both can be right. The difference is diagnosis quality.
The Practical Reframe
Here is the compressed operating system:
1. Long-lived things rarely keep their birth purpose. Judge current niche, not origin myth.
2. Lindy is a prior. Survival through time is evidence, not superstition.
3. Unreasonable rules can be load-bearing precisely because they resist rational exception-hunting.
4. Hidden order is still order. Unwritten communication norms are process infrastructure.
5. Humility is for perception. Courage is for action. Chesterton's Fence is how you see. It is not a lifetime veto against change.
I have watched clients burn months "simplifying" their way into outages, churn, audit pain, and internal distrust — all while congratulating themselves for speed.
I have also watched clients use "complexity" as anesthesia, preserving broken workflows because someone senior once got burned and turned that scar into permanent law.
The winning move is neither nostalgia nor demolition cosplay.
See the fence. Name the load. Then decide with your eyes open.
That is the whole game.
Mercury Technology Solutions: Accelerate Digitality.
Originally published on MTS Blog & Research