Skip to main content
Andrew Haglund

Chesterton’s Fence

Today I learned about Chesterton’s Fence thanks to Merlin Mann’s Wisdom Project:1

Learn about Chesterton’s Fence. Then, actively resist altering a given situation before you understand the reasons why it’s remained unchanged for so long.

This piqued my interest and I read2 a post by Shane Parrish which summarizes G. K. Chesterton’s 1929 idea:

Do not remove a fence unless you know why it was put up in the first place.

One example is from Steve Blank’s The Elves Leave Middle Earth – Sodas Are No Longer Free about a startup CFO killing free snacks without understanding the knock-on effects. It’s a great anecdote.

Parrish’s post concludes (original emphasis):

It reminds us that we don’t always know better than those who made decisions before us, and we can’t see all the nuances to a situation until we’re intimate with it. Unless we know why someone made a decision, we can’t safely change it or conclude that they were wrong.

The first step before modifying an aspect of a system is to understand it. Observe it in full. Note how it interconnects with other aspects, including ones that might not be linked to you personally. Learn how it works, and then propose your change.

I’m sure you can apply this lesson to your life one way or another (otherwise it wouldn’t be in the Wisdom Project) but it resonated with me as a designer and someone who works in software.

You might have seen a portfolio piece from a UX designer who proclaimed, “I fixed Twitter!”3 with a beautiful reimagining of the interface. These projects can be a great way for designers to learn and explore their own taste but please be humble. You don’t have a full picture of the priorities and constraints the design team was under nor the problem they were asked to solve.

While the expression “Chesteron’s Fence” was new to me, the idea was not. I received it as advice and it changed my approach when I started my job at Agrible back in 2017. I was the first design lead at the startup and they had been making software for a few years. My instinct was to move fast and make changes but instead I spent my first few weeks listening to the team and learning the product before suggesting any process or design changes.

It’s a skill I try to practice when any new project comes my way. Stay open-minded and don’t think about your decisions in a vacuum.


  1. This is a story for another day but I built an app that shows Merlin’s wisdom on my iPhone home screen. I haven’t decided if I’m going to continue the project or publish to the App Store. For now it’s just for me. ↩︎

  2. Technically I didn’t read the article. Instead I used the Listen to Page feature in iOS 17, which comes in handy when you could use 5–7 minutes to rest your eyes. ↩︎

  3. Visual design was never Twitter’s issue. It was everything else. ↩︎