Every product organization has something smart people want to delete.
A brittle approval step. A weird spreadsheet. A block of legacy code. A naming convention everybody ignores until it breaks a dashboard. A whiteboard interview loop half the company privately dislikes.
Destruction seduces us because it feels like clarity. The messy thing is obvious. The failure it is quietly containing usually is not.
If you are hiring product leaders, or trusting one with a platform, a roadmap, or a high-stakes workflow, this is one of the clearest judgment tests I know: can they tell the difference between clutter and structure before they start tearing things out?
The seduction of removal
An engineer gets a real dopamine hit deleting 500 lines of ugly code. A product lead feels real momentum killing an unloved process. A new executive wants to prove they are decisive, so they remove friction fast and call it simplification.
Sometimes they are right.
Sometimes the ugly thing was the last surviving record of a failure the system had already paid for.
That is the trap. Prevention is invisible when it works. Nobody holds a banquet for the person who kept the disaster theoretical. The meeting is calm. The metric stays stable. The customer never notices. So the safeguard looks unnecessary right up until the moment it disappears.
The posture I trust here is what I think of as humblident: confident enough to change a system, humble enough to assume the weird part might be load-bearing.
The Anatomy of the Fence
Chesterton's Fence is the rule that you should not remove a fence until you understand why someone put it there.
The original thought experiment is simple. You are walking down a road and a fence blocks your path. The amateur sees inconvenience and reaches for a saw. The serious operator stops and asks a different question: what problem was this built to prevent?
That is all the explainer most people need. In product work, the "fence" is rarely a literal fence. It is the awkward step in a workflow, the annoying approval, the ugly reconciliation script, the extra field in the form, the tribal-language rule, the clumsy interview ritual, or the outdated-seeming naming convention.
If you cannot explain the failure it was designed to stop, you do not yet have enough understanding to remove it safely.
Before you delete the thing, explain the disaster it was built to prevent.
High-stakes demolition
At industrial scale, this instinct shows up in ugly ways.
The Boeing 737 MAX story is one version of it. Compatibility pressure, training friction, and hidden system assumptions collided in a context where the cost of misunderstanding was catastrophic. The point is not that every product leader needs to become an aviation expert. The point is that invisible constraints do not become less real just because leadership gets impatient with them.
Public-health failures follow the same pattern. Oversight gets reframed as bureaucracy. A control surface looks slow, redundant, or expensive. Then the organization discovers that the "waste" was performing an important trust function after all.
That same logic scales down cleanly into product teams. Nobody dies when a PM removes the wrong approval step from a SaaS workflow. But teams do lose trust, misprice risk, corrupt data, ship the wrong metric, or create support debt that eats the next two quarters.
What the fence looks like in product work
The fence in product work is usually not glamorous.
- The ugly legacy code might be the only thing preventing a quarterly billing edge case from double-charging customers.
- The spreadsheet nobody respects might be the unofficial contract between support, operations, and engineering while the "real" system still cannot represent the workflow properly.
- The annoying approval step might be the only barrier stopping customer data exports from being handled casually.
- The awkward terminology rule might be the only thing stopping three teams from using the same word to mean three different states.
The one I see underestimated most often is hiring.
Technical recruiters and hiring managers are right to be suspicious of ritualized interview theater. A lot of whiteboard interviews are crude, stressful, and badly designed. But they survived for a reason. In many organizations, they are not really optimized to identify the best engineer. They are a blunt institutional defense against a catastrophically bad hire.
That does not mean the fence is good. It means you do not get to remove it responsibly until you can explain what bad outcome it was attempting to contain and what will replace that protection.
The three-question test
This is the version I would actually use on a team.
- What failure was this built to prevent? If the answer is "probably bureaucracy" or "nobody knows," stop. You do not understand the system yet.
- Where is that failure still possible today? Old safeguards often outlive their original environment, but many of them are still protecting a real risk somewhere else in the workflow.
- What is the replacement guardrail before removal? If the current fence is bad, fine. Replace it deliberately. Do not create an unguarded gap and promise the team you will clean it up later.
I like this test because it forces second-order thinking without turning change into theology. You are not asking whether the rule feels annoying. You are asking what new blast radius you are about to create.
In practice, the replacement is usually one of four things:
| Fence you want to remove | Hidden function it may be serving | Better replacement |
|---|---|---|
| Legacy approval step | catches trust or compliance risk | explicit policy + auditable automation |
| Weird spreadsheet | preserves cross-team operational truth | proper shared model with named ownership |
| Ugly legacy code path | protects a domain edge case nobody re-modeled | tests, observability, and a safe migration path |
| Clumsy interview ritual | screens out a known class of bad hire | more job-relevant assessment with clear failure signals |
When the fence should come down
Chesterton's Fence is not an argument for preserving every bad process forever.
Sometimes the old safeguard really is dead weight. Sometimes the world it was built for is gone. Sometimes the team has a better model, better instrumentation, and a safer way to contain the same risk. In those cases, keeping the fence is just sentimentality disguised as caution.
This is where a lot of otherwise smart people over-correct. They hear the principle and turn it into a veto on change. That is not the point.
The point is informed demolition.
If you can explain the original failure, show where that risk lives now, and put a better guardrail in place first, remove the fence. Tear it out cleanly. Simplify the system. Just do not confuse impatience with understanding.
It is the same logic as carrying a spare tire. Driving for years without using it does not prove it was useless. It proves the failure was rare. If you remove it, do it because you have roadside coverage, a better replacement plan, and a deliberate trade-off, not because the quiet years fooled you into thinking the risk disappeared.
Why recruiters, Heads of Product, and CPOs should care
For recruiters, this is one of the cleanest signals of seniority. A candidate who only talks about speed, simplification, and shipping is easy to find. A candidate who can explain hidden constraints, trust surfaces, failure containment, and safe replacement design is much rarer.
For Heads of Product and CPOs, this is operating discipline. A large part of the job is deciding which friction is waste and which friction is carrying risk, trust, or coordination weight the org has not modeled properly yet.
For product and program leaders more broadly, Chesterton's Fence is a useful check against a very modern failure mode: confusing visible mess with the real problem. The visible mess is often just the scar tissue. The real problem is that nobody captured why the scar formed, so the next confident person mistakes it for useless baggage and repeats the injury.
That is why I do not read this as a conservative principle. I read it as a product principle. Respect the unseen system. Then change it on purpose.
Related thinking
- Domain Bugs Cost More Than Code Bugs - why ambiguous language and hidden model drift break systems long before the code does
- Documentation Is a Product Surface - the KCS instinct that keeps invisible safeguards from living only in one person's head
- Your AI Demo Is Not Production Ready - another case where hidden operational constraints matter more than the surface-level demo
- The PM Who Ships Code: When Building Is the Research - why product judgment often gets sharper when you are close enough to the system to hit the edge cases
Further Reading
- Chesterton's Fence - Farnam Street - a concise version of the principle and its second-order-thinking implications
- Taking a Fence Down - The American Chesterton Society - source-oriented context for the original idea
- The Scout Mindset - Julia Galef - how to approach systems with curiosity instead of trying to win the argument
- Working Effectively with Legacy Code - Michael Feathers - the engineering playbook for changing inherited systems safely
