Chesterton's Fence: understand why it was built before you tear it down
Before removing any inherited system, process, or organizational structure, document why it was originally created and what problem it solved—if this context cannot be reconstructed, you lack sufficient information to safely remove it.
Why This Is a Rule
G.K. Chesterton's fence principle: if you find a fence across a road and can't understand why it's there, you should not remove it — because the fence was built by someone who had a reason, and your inability to see the reason doesn't mean the reason doesn't exist. It means you have less information than the builder.
Inherited systems, processes, and structures are Chesterton's fences. They look unnecessary, redundant, or bureaucratic from the outside. But they were created by someone responding to a specific problem — a problem that may recur if the structure is removed. The "redundant" approval process might have been created after a $200,000 error. The "unnecessary" backup system might have been installed after a data loss incident.
The rule requires you to document the original purpose before removal. This documentation effort produces one of two outcomes: you discover the original reason and can evaluate whether it still applies (informed removal), or you cannot discover the original reason and must proceed with caution (the reason might still be active).
When This Fires
- Before removing any process step, review gate, or organizational structure you inherited
- When simplifying systems that seem unnecessarily complex
- During any "let's cut the red tape" initiative
- When a new leader arrives and wants to remove "unnecessary" processes
Common Failure Mode
Removing things because you can't see their purpose: "Nobody knows why we do this, so it must be useless." The inability to find the purpose might reflect organizational knowledge loss, not the absence of purpose. The process might be preventing a problem that hasn't occurred precisely because the process exists — survivorship bias applied to organizational design.
The Protocol
Before removing any inherited structure: (1) Ask: "Why was this created? What problem did it solve?" (2) Search for the answer: ask long-tenured team members, read historical documents, check incident reports from the period when it was created. (3) If the original purpose is found → evaluate: does this problem still exist? If yes → keep or redesign. If no → safe to remove. (4) If the original purpose cannot be reconstructed → proceed with extreme caution. Consider a trial removal (disable for one cycle, monitor for the problem it might have been preventing) rather than permanent elimination.