# Chesterton's Fence G.K. Chesterton's principle, stated in 1929: if you come across a fence in the middle of a road and cannot see why it is there, do not remove it. Go away and think. Come back when you understand why it was built. Only then are you in a position to decide whether it should stay or go. The principle is not conservative. It is not an argument against change. Chesterton's point is that the person who can explain the fence's purpose is in a far better position to remove it safely than the person who cannot — because the person who cannot understand it may be dismantling a constraint that is solving a problem they haven't yet seen. ## The structure of the error The error Chesterton is naming is a specific kind of confidence failure: the assumption that if *you* cannot see the purpose of something, it probably doesn't have one. This conflates *your* ignorance of a reason with the *absence* of a reason. It happens most readily with: - Old practices that no longer look relevant ("we've always done it this way — but why?") - Rules with no obvious beneficiary ("who is this protecting, exactly?") - Roles that seem redundant ("do we really need this position?") - Systems that appear to be overhead ("can't we just cut this step?") Each of these is a fence. Some genuinely should be removed. But the question "why is this here?" is not rhetorical — it is diagnostic. The answer reveals what was being protected and whether that protection is still needed, unnecessary, or needed in a different form. ## In organisational change Chesterton's Fence is one of the most consistently violated principles in organisational change work. Restructures remove roles before understanding what informal coordination they were providing. Process improvements cut steps before understanding what errors they were catching. Technology migrations eliminate workarounds before understanding what system failures the workarounds were compensating for. The consequences appear later, often disguised: the incidents that start occurring after the "simplification," the coordination failures after the restructure, the quality issues after the process improvement. By then the connection to the removed fence is invisible, because the problem solved by the fence is now a problem again, but it presents as a new problem rather than the return of an old one. The organisational version of the principle: before removing any structure, role, ritual, constraint, or process — find at least one person who can explain what problem it was solving. If no one can, that is evidence for investigation, not for removal. It means the institutional memory has already been lost, and the fence's purpose may be invisible precisely because it has been working. ## In coaching and facilitation Coaching clients who are redesigning their teams, processes, or ways of working frequently identify things they want to eliminate: redundant meetings, approval steps, check-in rituals, documentation requirements. Chesterton's Fence is a useful pause before the intervention. The questions: - "Who put this in place, and what were they trying to prevent?" - "Has the problem this was solving actually gone away, or have we just stopped seeing it?" - "What would we expect to see if we removed this and the original problem returned?" This reframes the conversation from "is this useful?" (which invites opinion) to "what was this solving?" (which invites investigation). The investigation often reveals either that the fence can safely come down, or that there is a real problem that the fence is masking in an inefficient way and which deserves a better solution. Applied to coaching itself: supervision requirements, contracting rituals, debrief structures, session notes — all are fences. Understanding what each is protecting makes it possible to decide consciously whether to maintain it, replace it, or let it go. ## The complementary move Chesterton's Fence pairs naturally with [[Enabling vs Governing Constraints]]: the fence is a governing constraint. The question Chesterton is asking is whether it should remain governing or be replaced with an enabling constraint — or removed entirely. You can only answer that question if you understand what the fence was governing. It also pairs with [[Inversion]] (the pre-mortem move): before removing the fence, ask "if we remove this and something goes wrong, what would the failure look like?" The imaginative act of failure often reveals the protection the fence was providing. ## See Also - [[Enabling vs Governing Constraints]] — understanding constraint type before removing a constraint; governing constraints have purposes that enabling constraints may serve better - [[Domain Confusion Creates the Wrong Moves - Deep Dive]] — removing a fence that was managing complexity as if it were managing a merely complicated problem - [[Entrained Thinking]] — the mirror error: keeping a fence indefinitely because removing it requires seeing the situation freshly; both errors share the same cognitive root - [[Theory of Constraints]] — the constraint in Goldratt's sense is often a fence worth keeping; elevating the wrong constraint (removing the wrong fence) can shift the bottleneck to a worse location - [[Socio-Technical Systems]] — many organisational fences are sociotechnical: they were compensating for a mismatch between the social and technical system; removing them without fixing the mismatch re-exposes the friction - [[The Shadow Side of Coaching]] — coercive change removes fences for the change-maker's convenience without understanding what the coachee was protecting; the fence often represents a legitimate self-protective structure