Chesterton's Fence Mental Model… | Faster Than Normal
Psychology & Behavior
Chesterton's Fence
Chesterton's Fence is the principle that you should never remove a rule, process, or institution until you understand why it was put there in the first place. G.K. Chesterton argued that a fence across a road exists for a reason — and the person who doesn't see the reason is exactly the person who shouldn't be allowed to remove it. In business and engineering, this mental model prevents well-intentioned reformers from breaking systems they don't fully understand. Before dismantling anything — a policy, a codebase pattern, a team ritual — first understand the problem it was solving. The fence may be ugly, but it might be the only thing between you and a stampede.
Model #0507Category: Psychology & BehaviorSource: G.K. ChestertonDepth to apply:
G.K. Chesterton: "Don't ever take a fence down until you know the reason it was put up." Before removing a rule, process, or structure, understand why it exists. The principle is deceptively simple and routinely violated. The fence is a metaphor for any inherited structure — a policy, a code path, a compliance check, a standing meeting. Someone built it. They had a reason. The reason may no longer apply. But the burden of proof lies with the person proposing removal, not with the fence.
Most "obviously stupid" policies were created to solve a real problem. The fence might be solving a problem you can't see. Amazon's "working backwards" from customer — but also understanding why legacy systems exist before replacing them. Stripe's gradual migration patterns: they don't rip out old infrastructure. They build alongside, understand the constraints, then migrate. The first principle: understand, then optimize. Destruction is the easy part. Understanding is the work.
New CEOs are prolific fence-destroyers. A newly appointed executive identifies processes that seem slow or bureaucratic and eliminates them in the first ninety days — signalling decisiveness. Six months later, the problems those processes were designed to prevent resurface. The compliance review that seemed redundant was preventing regulatory fines. The approval chain that seemed slow was catching errors. The weekly sync was the only mechanism keeping two teams aligned. The new CEO didn't remove bureaucracy. They removed load-bearing walls.
The principle is not a defence of the status quo. Chesterton was not arguing that fences should never be removed. He was arguing that fences should only be removed by people who understand why they were built. Blind preservation is as dangerous as blind demolition. The principle demands investigation, not inaction. It demands understanding before action — which is harder, slower, and less satisfying than action without understanding.
Engineers inherit codebases full of decisions they didn't make. A function that seems pointless. A configuration that seems redundant. A workaround that seems unnecessary. The temptation is to clean it up — delete the dead code, simplify the architecture, remove the guard clause that "never triggers." Then the edge case triggers. The system that handled it gracefully for three years now fails catastrophically, because the new engineer removed the fence without understanding that it was a retaining wall. Google's SRE teams formalised this insight: before removing any system behaviour, you must first document what it does and why it exists. If you can't answer both, you don't touch it.
Section 2
How to See It
Chesterton's Fence is invisible until the fence falls. The pattern: someone removes a constraint, process, or structure they didn't understand — and the consequence that the constraint was preventing arrives with the exact predictability that would have been obvious if anyone had asked "why is this here?" before removing it.
The diagnostic question is always the same: can the person proposing removal explain why the thing they want to remove was created in the first place? If they can, they may have a legitimate case for removal. If they can't, they are proposing to act on ignorance.
Technology & Engineering
You're seeing Chesterton's Fence when an engineer removes a "redundant" validation check from a codebase and production breaks within hours. The validation was handling an edge case that occurs once every forty thousand requests. The engineer saw dead code. The code was a load-bearing wall. The pattern is endemic in legacy systems: the older and more complex the codebase, the more fences exist — and the more tempting they are to remove, because the original builders are gone and their reasoning left with them.
Corporate Leadership
You're seeing Chesterton's Fence when a new CEO eliminates the weekly cross-functional sync as "unnecessary overhead" and within a quarter, two product teams ship conflicting features. The sync existed because three years earlier, the exact same coordination failure had cost the company a major account. The institutional memory lived in the head of a VP who left six months ago. The new CEO saw a meeting with no clear agenda. The meeting was a coordination mechanism disguised as a standing calendar invite.
Policy & Regulation
You're seeing Chesterton's Fence when a deregulation effort removes financial reporting requirements as "red tape" and a fraud scandal emerges eighteen months later — exploiting exactly the gap that the reporting requirement was designed to close. Every section of Sarbanes-Oxley corresponds to a specific corporate fraud technique that flourished in the absence of the constraint it reinstated.
Product & Design
You're seeing Chesterton's Fence when a product team removes a "friction-heavy" confirmation step from a deletion workflow, and customer support tickets for accidental deletions triple within a week. The confirmation step wasn't friction — it was protection. The team measured the step in clicks. The original designer measured it in irreversible data loss.
Section 3
How to Use It
Chesterton's Fence is a decision-making discipline, not a preservation instinct. The operational question is not "should I keep this?" It is "do I understand why this exists?" If yes, you can make an informed decision about whether to keep, modify, or remove it. If no, your first task is investigation — not action.
Decision filter
"Before removing any process, policy, feature, or structure, I must be able to articulate — in specific terms — what problem it was designed to solve, when it was created, and whether that problem still exists. If I can't answer all three, I don't touch it until I can."
As a founder
The fastest-moving founders are the most vulnerable to Chesterton's Fence violations. Speed selects for action over investigation. When something looks slow, the instinct is to cut it. The discipline is to add one question before every removal: who built this, and what were they responding to? At early-stage companies, the institutional memory often lives in one person's head. When that person leaves, every decision they made becomes an unlabelled fence. Build the habit of documenting the "why" behind non-obvious decisions.
The founder's specific vulnerability: removing constraints that were placed by investors, advisors, or early employees for reasons the founder never fully absorbed. A board reporting cadence that seems excessive may exist because a previous investor was burned by a company that went dark between board meetings.
As an investor
Every portfolio company you inherit comes with fences you didn't build. The temptation after an acquisition is to "clean house." The discipline is to spend the first ninety days investigating rather than demolishing. The most expensive mistakes in post-acquisition integration come from removing structures whose purpose was invisible to the acquirer but essential to the acquired company. When a management team describes their organisation's structures, ask about the ones that seem unnecessary. If they can explain the origin and current purpose, the structures are deliberate. If they can't, the structures may be debt — or they may be protecting against risks the management team has forgotten about.
As a decision-maker
Institutionalise the Chesterton's Fence question. Before any removal — a policy, a team, a product feature — require the proposer to document what the thing was originally designed to do and whether that need still exists. The cost of the investigation is hours. The cost of removing a load-bearing structure is months. Turn the question on yourself: before removing a constraint that a predecessor put in place, assume they were at least as intelligent as you and had access to context you don't.
Common misapplication: Using Chesterton's Fence as a universal defence of the status quo. The principle demands investigation, not preservation. A leader who says "we can't change anything because Chesterton's Fence" has misunderstood the principle as thoroughly as the leader who says "tear it all down." The correct application: investigate, understand, then decide. Some fences, once understood, should absolutely be removed — because the problem they solved no longer exists, or because a better solution is available. The principle protects against uninformed removal. It does not protect against informed change.
Section 4
The Mechanism
Section 5
Founders & Leaders in Action
The leaders who apply Chesterton's Fence most effectively treat inherited systems as evidence rather than obstacles. Before changing what they found, they decode why it exists.
Bezos built investigation into Amazon's decision architecture. The "disagree and commit" framework is Chesterton's Fence operationalised: before you disagree with a decision, you must first articulate the decision's logic better than its advocates can. You earn the right to disagree by proving you understand what you're disagreeing with. The six-page memo format serves the same function: by forcing the decision-maker to articulate the reasoning behind a proposal in narrative form, the memo makes the reasoning legible to anyone who might later want to challenge or reverse the decision. The memo is the fence's construction record. Without it, the next person to encounter the decision will see only a fence they don't understand — and the temptation to tear it down will be overwhelming. When Amazon considered changing its fulfilment architecture, the review process required teams to document every constraint in the existing system — including the ones that seemed arbitrary — before proposing alternatives. Constraints that new engineers wanted to eliminate often encoded hard-won operational lessons: shipping weight limits that prevented warehouse injuries, inventory placement rules that optimised for return logistics. The investigation didn't prevent change. It made change smarter.
When Jobs returned to Apple in 1997, the company had over forty products across a dozen confusing categories. The conventional narrative: Jobs slashed the product line to four products. The deeper story is Chesterton's Fence in action. Jobs spent months reviewing every product line — not to find reasons to keep them, but to understand why each one existed before deciding whether to cut it. He discovered that several product lines existed solely because the team that built them had political protection. Others existed because of OEM relationships that generated meaningful revenue. The investigation revealed which fences were load-bearing and which were decorative. The products Jobs killed were the ones where investigation revealed no structural purpose. The result was informed simplification — which is why it worked.
Lütke's 2023 restructuring at Shopify was disciplined large-scale fence removal. He eliminated the Deliverr logistics division, cut twenty percent of the workforce, and dissolved standing meetings and committees. But the restructuring was preceded by months of investigation into what each structure actually did — not what it was supposed to do on an org chart, but what function it served in practice. Lütke could explain why each eliminated structure had been created, what problem it was solving, and why that problem either no longer existed or could be solved differently. He wasn't tearing down fences he didn't understand. He was removing fences he understood better than the people who built them — which is why the restructuring succeeded where similar efforts at other companies produced chaos.
Section 6
Visual Explanation
Chesterton's Fence creates two divergent paths from the same starting point: encountering an inherited structure you don't understand. The uninformed path — removal without investigation — produces consequences that were entirely predictable. The informed path — investigation before action — produces a decision that accounts for the fence's original function.
The diagram traces two paths from the same starting point. Path A removes the structure immediately and discovers the consequence it was preventing. The result is rebuilding the fence at higher cost, having learned through failure what investigation would have revealed for free. Path B investigates the purpose before acting. With purpose understood, the decision branches: keep the fence if the problem it solves still exists, or remove it if the problem has been resolved. Both paths can arrive at the same endpoint (removal). The difference is cost. Path A pays the cost of the consequence plus remediation. Path B pays only the cost of investigation — which is always cheaper.
Section 7
Connected Models
Reinforces
Second-Order Thinking
Second-order thinking asks "and then what?" after every proposed action. Chesterton's Fence asks "why is this here?" before any proposed removal. The two reinforce each other: a decision-maker who applies second-order thinking to a proposed removal will naturally arrive at the Chesterton question. A decision-maker who applies Chesterton's Fence will naturally engage second-order thinking about the consequences of removal.
Tension
First Principles Thinking
First principles thinking creates direct tension with Chesterton's Fence. A first-principles thinker asks "what should this system look like if I designed it from scratch?" Chesterton's Fence asks "why does this system look the way it does?" The tension is not a contradiction — it is a sequence. Apply Chesterton's Fence first (understand the existing system) and first principles second (redesign from foundations if the rationale no longer holds).
Reinforces
Survivorship Bias
Survivorship bias warns that we study only what survived. Chesterton's Fence adds: the things that survived often survived for reasons we can't see. A process that has existed for ten years has demonstrated decade-long utility. The absence of a visible reason is not evidence that no reason exists. It is evidence that the observer's information is incomplete.
Reinforces
Organisational Debt
Chesterton's Fence operates at the intersection of decision theory, systems thinking, and organisational design. It draws its power from the recognition that inherited structures encode information — and that destroying a structure without extracting its information is a permanent loss. The models above map the relationships: the models that explain why fences are built, the models that predict the consequences of uninformed removal, and the thinking tools that make investigation productive.
Section 8
One Key Quote
"In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle. 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 will do well to 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.'"
— G.K. Chesterton, The Thing: Why I Am a Catholic (1929)
The power is in the inversion. The reformer assumes that not seeing a reason is sufficient justification for removal. Chesterton inverts the burden: not seeing a reason is precisely why you are not qualified to remove it. Your ignorance is not an argument for action. It is an argument for investigation. The person who sees the use of the fence and still wants to remove it has earned the right to do so. The person who doesn't see the use has earned only the right to go away and think.
The principle's endurance — nearly a century later, it is invoked in software engineering, public policy, organisational design, and military strategy — is itself a Lindy Effect demonstration. The fence metaphor has survived because the cognitive error it describes is permanent. Every generation of reformers encounters structures they didn't build, fails to see the use of them, and reaches for the demolition tools. The principle doesn't prevent the error. It names it — which, for the people paying attention, is enough.
Section 9
Analyst's Take
Faster Than Normal — Editorial View
Chesterton's Fence is the most violated principle in corporate leadership. Every CEO transition, every acquisition integration begins with a leader surveying inherited structures and deciding which ones to demolish — usually within ninety days, usually without understanding what they're demolishing.
The pattern is consistent: the speed of demolition correlates inversely with understanding. The leader who makes sweeping changes in the first month understands the least. The leader who spends six months investigating before changing anything understands the most. The market rewards the first leader with press coverage and punishes the second with impatience. The market is wrong.
The tech industry's version is the "refactor everything" syndrome. A new engineering lead inherits a codebase, finds it messy, and proposes a ground-up rewrite. The rewrite takes eighteen months and reproduces approximately seventy percent of the functionality — because the original system's remaining thirty percent consisted of edge-case handling that nobody documented. Stripe's approach — gradual migration, building alongside, understanding before replacing — is the correct application. Understand the fence. Then decide.
The most effective leaders spend their first ninety days asking "why does this exist?" rather than "why does this still exist?" The difference in framing is transformative. "Why does this still exist?" assumes the structure is outdated. "Why does this exist?" assumes nothing. The first question biases toward removal. The second biases toward understanding.
The principle has a dark counterpart: Chesterton's Fence is routinely weaponised by people who want to prevent change. A bureaucrat who says "we can't change this because there must be a reason it exists" is not applying the principle. They are hiding behind it. The principle demands investigation, not paralysis. The investigation may reveal that the fence serves no current purpose — in which case removal is required.
The operational takeaway: the cost of investigating a fence before removing it is measured in days. The cost of removing a load-bearing fence without investigation is measured in quarters. Every leader faces this asymmetry. The ones who internalise it build organisations that move fast and break the right things. The ones who ignore it move fast and discover — always too late — that the thing they broke was holding everything else together.
Section 10
Test Yourself
Chesterton's Fence is invoked both by people who want to prevent reckless change and by people who want to prevent any change at all. The diagnostic skill is distinguishing between legitimate application (investigation should precede removal) and illegitimate application (the principle used as a shield against all reform). These scenarios test whether you can identify when the principle is being applied correctly, when it's being violated, and when it's being weaponised.
Is Chesterton's Fence being applied correctly?
Scenario 1
A new CTO eliminates the security team sign-off on deployments, calling it 'redundant with automated scanning.' Three months later, a security vulnerability in production causes a data breach. Post-mortem reveals the security team had been catching an average of two critical vulnerabilities per week that automated scanning missed.
Scenario 2
A product manager investigates a confirmation step in checkout, learns it was added three years ago after a batch of orders shipped to outdated addresses. The PM confirms the address system now correctly flags outdated addresses and proposes removing the step. The VP approves.
Scenario 3
A CFO pushes back on raising an expense approval threshold, saying 'That process exists for a reason.' When asked what the reason is, the CFO says 'It's always been that way' and declines to provide data on what the process has caught.
Section 11
Top Resources
Chesterton's Fence draws from conservative philosophy, systems thinking, engineering culture, and organisational design. The concept is simple — understand before removing — but its application spans every domain where inherited structures exist. Start with Chesterton's original passage, extend through Taleb's systematic treatment of why old things survive, and ground the practice in the operational literature on organisational change and technical systems.
The original source. Chapter four, "The Drift from Domesticity," contains the fence passage. Chesterton's argument is broader than the single metaphor — he is making a case for epistemic humility in reform.
Taleb's Lindy Effect and his concept of "iatrogenics" — harm caused by intervention — extend Chesterton's Fence into a systematic framework. Taleb argues that evolved systems (biological, cultural, institutional) encode more information than any individual observer can perceive, and that intervening in these systems without understanding their full complexity produces harm that exceeds the original problem. The most rigorous modern treatment of why inherited structures deserve investigation before modification.
Scott documents the catastrophic consequences of what he calls "high modernist ideology" — the belief that complex systems can be redesigned from first principles by experts who understand the formal structure but not the informal knowledge embedded in existing arrangements. The case studies — Soviet collectivisation, Brasilia's urban planning, compulsory villagisation in Tanzania — are Chesterton's Fence violations at civilisational scale, where reformers destroyed functional systems they didn't understand and replaced them with rational designs that failed.
Documents how Amazon institutionalised the investigation-before-action discipline. The six-page memo and narrative-driven decision structure force decision-makers to articulate reasoning before proposing changes.
Norman's concept of affordances provides the design lens for Chesterton's Fence. A well-designed fence communicates its purpose through its structure: a guardrail along a cliff edge is self-evidently protective. A poorly designed fence — a process with no visible rationale, a policy with no documented origin — invites removal because its function is invisible. Norman's framework explains why some fences survive scrutiny and others don't, and how to design systems whose rationale is self-documenting.
Chesterton's Fence — Why understanding must precede removal. Two paths diverge at an inherited structure: investigate first, or demolish first.
Organisational debt is accumulated structural dysfunction. Chesterton's Fence is the diagnostic that prevents mis-identifying functional structures as debt. A leader paying down organisational debt must distinguish between structures that persist because no one made the decision to change them and structures that persist because they serve a purpose that isn't immediately visible. Chesterton's Fence is the diagnostic that separates the two.
Reinforces
Technical Debt
Technical debt is the accumulated cost of shortcuts in code. Chesterton's Fence applies: before refactoring or removing "legacy" code, understand what it does and why it exists. Stripe's gradual migration patterns exemplify this — building alongside old systems, understanding constraints, then migrating. The alternative is removing fences you don't understand.
Leads-to
[Inversion](/mental-models/inversion)
Inversion asks "what would guarantee failure?" Chesterton's Fence asks "what would removing this structure reintroduce?" Both shift from forward analysis to backward analysis. The inverted question — "what problem would reappear if I removed this?" — is the operational form of the Chesterton investigation. Buffett's "Rule No. 1: Never lose money" is inversion. Chesterton's Fence is the structural corollary: never remove a constraint until you understand what it was preventing.
