The Risk of Fixing What Isn’t Broken

The wall didn't make sense. It wasn't a boundary, it didn't support anything. The wall was just there. And that bothered Nolan.

In a small coastal town, an old stone wall cut diagonally across the community garden. Unlike the garden's other walls, this one appeared to serve no purpose. It didn't enclose anything, support climbing plants, or mark a boundary. It simply stood, weathered and moss-covered, seemingly random among the flower beds.

When Nolan became the mayor, removing the wall topped his agenda. "It disrupts the garden's flow and takes up valuable growing space," he explained at a town meeting. He pushed to tear it down and the town council agreed, eager to cleanup the space.

The day before demolition, Nolan went to the garden to take final measurements. He found an elderly woman named Margaret sitting on a bench nearby.

"You're here about the wall, aren't you?" Margaret asked.

"Yep," Nolan replied, hardly looking up from his notes. "It'll be gone tomorrow."

"Ya know, my grandfather built that wall fifty years ago," Margaret said. "We used to lose most of the garden in the winter storms before that. The winds come through this valley like a funnel."

Nolan smiled politely but continued his work. "That was a long time ago and progress, my dear, requires change."

Margaret sighed and left without another word.

The wall came down the next day. Nolan proudly showcased the garden's new open design in the local paper.

When winter arrived, so did the first major storm. Awakened by howling winds, Nolan remembered Margaret's words, and first thing in the morning, he drove to the garden. What he found was devastation. Plants had been uprooted, delicate flowers shredded, and months of work destroyed. The wind tore through the garden exactly as Margaret had warned, following the channel her grandfather had blocked decades ago.

In his eagerness to clean things up, Nolan fell into a common trap: assuming that just because something's purpose wasn't obvious, it had no value. This is what’s known as Chesterton's Fence, a principle that warns against removing or changing something before fully understanding why it was put there in the first place.

So this week, let's talk about Chesterton's Fence—what it is, when to make changes and when to wait, the importance of documenting decisions, and how to avoid learning the hard way why something was there in the first place.

What is Chesterton’s Fence

The concept of Chesterton’s Fence comes from G.K. Chesterton’s 1929 book, The Thing: Why I Am a Catholic. He describes a scenario where someone finds a fence in the middle of a field and says, “I don’t see the point of this fence. Let’s take it down!” A wiser person replies, “If you don’t understand why it’s there, you shouldn’t remove it until you do.”

Chesterton was making a broader argument about conservatism and reform, warning against reckless change. In the book, he describes a scenario:

To be clear, Chesterton wasn’t against change. He just argued that before dismantling something, you should understand why it was built in the first place. Many rules, traditions, and systems exist to solve problems that might not be obvious (until they’re gone).

You can see this in lots of places:

• A company scraps an old policy, only to realize it was preventing bigger issues.

• A team removes an approval step in a process, leading to costly mistakes.

• A city tears down a historic building, only to lose a tourist attraction that supported local businesses.

Just because something’s purpose isn’t obvious doesn’t mean it’s useless—it may be solving a problem you haven’t encountered yet.

When to Make Changes. When to Wait

Change is a tricky thing. Not every “fence” should stay standing forever. Some systems really are outdated, some traditions do need to evolve, and some policies should be removed. But how can you tell the difference between something that’s pointless and something that’s protecting you from a hidden problem?

Before grabbing that sledgehammer, here are some questions worth asking yourself:

• "What was this thing actually supposed to solve?" Even if nobody remembers, that doesn't mean there wasn't a good reason. Just ask the company that streamlined their hiring process only to get flooded with low-quality hires they used to filter out.

• "Is this still relevant today?" Fair question. Some fences were built for problems that disappeared long ago. Like companies that still require faxed documents when everyone else moved to secure digital signatures a decade ago.

• "What if we just... wait and watch for a bit?" Sometimes observing how things actually work reveals that seemingly useless processes are quietly preventing disasters.

• "What else might break if we remove this?" Changes ripple. The team that axed their weekly meetings to "save time" didn't expect their communication to completely fall apart.

• "Can we test this before going all-in?" Instead of demolishing the entire wall, maybe remove one section and see what happens. Small experiments prevent big regrets.

Chesterton’s Fence isn’t an argument against change. It’s a guide for thoughtful change. The goal isn’t to keep everything the same forever; it’s to make sure you’re not solving one problem while creating a bigger one. Sometimes, the smartest move is simply to wait, watch, and learn before acting.

The Case for Writing Things Down

I'll be honest, documenting things hasn’t always been my strong suit. It's often felt tedious, like something that slows things down rather than moves things forward. When you're in the middle of solving problems, the last thing you want to do is pause and write about why you're doing what you're doing.

But as I've gotten older (and wiser?) and done this long enough to see history repeat itself, I've realized just how important documentation is. Decisions get made, people move on, and years later, someone will inevitably ask, "Why did we do it this way?" Too often, the answer is a shrug.

At Sporcle, so much institutional knowledge has lived in conversations rather than documents. With a team of long-time staffers, we’ve relied on an oral tradition to pass down history, decisions, and lessons. That worked until we started hiring new people. Over time, we’ve had to be more intentional about writing things down, not just to track decisions, but to give future teams a clear starting point instead of making them relearn the same lessons the hard way.

This is the other side of Chesterton's Fence. It's not just about being careful before tearing things down. It's about leaving breadcrumbs so that the next person doesn't have to rebuild the fence just to understand why it was there in the first place.

If documenting things feels like a chore, here's a mindset shift that I have found helpful: Write things down as if you're writing a note to yourself, five years from now.

And here are a few simple ways to make documentation a bit easier:

• Capture decisions, not just processes. What changed? Why? What problem were we solving?

• Make it easy to find. A well-documented policy buried in an inbox is as good as lost.

• Keep it lightweight. Documentation doesn’t have to be a massive report. Sometimes a few bullet points are enough.

• Use AI to help. Tools like AI-generated meeting summaries, searchable knowledge bases, and smart tagging can make documentation easier without adding extra work. (More on how AI can simplify this process in a future newsletter.)

It’s not about writing for the sake of writing. It’s about giving the next person a map instead of making them rediscover the terrain.

In Conclusion

The hardest lessons are the ones we don't see coming. The ones we only understand after we've torn down the wrong wall, removed the wrong rule, or dismissed something as pointless only to realize, too late, why it was there.

Chesterton's Fence isn't about resisting change. It's about making smarter changes. Nolan's garden disaster wasn't just a coincidence or bad luck - it was an unforced error caused by dismissing history without understanding it first (a touch of hubris might have been in there as well).

When you run into something that seems unnecessary or outdated, resist the urge to immediately "fix" it. Ask questions. Seek out documentation. Talk to the veterans who've been around.

And when you do make a change? Write it down. Document not just what you did, but why you did it. Because the only thing worse than learning a painful lesson yourself is forcing someone else to learn it all over again when you could have left them a map.

As always, thanks for reading,
Derek
Oh and have something interesting you think I should write about? You can reply to this email (or any other Chief Rabbit email) to suggest it. 

Hold up!

Could I get you to take this tiny, little poll to help me improve this newsletter. Your input helps me choose both content and partners that'll be most valuable to you. It takes juuuust a few seconds.

If you’d like to support my work, you can buy me a coffee on Ko-Fi! ☕✨ Every bit helps me keep creating. Thank you! 💛

Also, if you like newsletters, check out some on this list, I get a little referral when you sign up. They're all free!

JOIN THE WARREN

Chief Rabbit reaches about 25,000 readers each week with actionable strategies for productivity, mindset shifts, and leadership to help you turn small changes into remarkable outcomes.

🙏 Thank You

That's all for now. See you next week.

You can also follow me on Threads or Bluesky where I sound off on all sorts of nonsense on LinkedIn where I tend to be a touch more serious.
Also, thanks for being someone who reads to the bottom of the email, you're a special human.