── ── Decision-making
Chesterton's Fence
Chesterton's Fence is the principle that you should not remove or change an existing rule, structure, or process until you understand why it was put there. The reformer who can't explain the original purpose isn't yet qualified to dismantle it. Only after grasping its reason are you fit to judge whether it still serves one.
How it works
When you encounter a rule or process that seems pointless, resist the urge to scrap it. First investigate: who built it, what problem were they solving, and does that problem still exist? Often the fence was protecting against something now invisible because the fence has been working.
Once you genuinely understand the original purpose, you can make an informed decision. Sometimes the reason is obsolete and removal is correct; sometimes it reveals a risk you'd have walked straight into. Either way, you act with knowledge instead of assumption.
When to use it
- Inheriting a codebase, process, or contract whose constraints seem arbitrary
- Joining or acquiring a company and questioning its established practices
- Considering removing an approval step, check, or 'legacy' workflow
- Reforming a policy that the team complains about but predates everyone
When not to use it
Not an excuse to preserve everything — once you understand the reason and it's genuinely obsolete or harmful, remove the fence decisively.
Worked example
G.K. Chesterton's parable of the road
In his 1929 book The Thing, G.K. Chesterton described a fence across a road that a reformer wants to clear away. The wiser response, he argued, is: '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.' The point is that apparent uselessness usually reflects ignorance of the original purpose, not its absence.
Why it matters for founders
Fast-moving founders love to delete process, and that instinct is often right — but the most expensive deletions are the ones that quietly removed a safeguard nobody remembered installing. Understanding why a thing exists before killing it is cheap insurance against re-learning an old lesson the hard way. deciqAI's agents investigate the original intent behind a system before changing it, so cleanup doesn't reintroduce the problem the fence was solving.
Install this skill (free, MIT)
npx skills add deciqAI/knowledge-skillsFAQ
Doesn't this just protect bureaucracy and bad rules?
No — it requires you to understand the rule, not to keep it. Understanding often reveals a rule is obsolete, which then justifies removing it with confidence rather than guesswork.
What if nobody remembers why the rule exists?
Then the missing rationale is itself a warning. Investigate the history, the incidents it may have prevented, and the cost of being wrong before you remove it.