Stop Removing “Outdated” Systems Too Quickly

In the 17th century, a strange problem was eroding trust in the economy.

People were literally shaving money.

Coins—then made from gold or silver—were trimmed around the edges. The shavings were collected, melted down, and resold.

The coins stayed in circulation, looking mostly normal—but with slightly less value each time.

The fix?

A simple design choice: ridged edges.

The moment a coin was clipped, you could see it. It made tampering visible. Trust was restored.

Fast forward to today, and those ridges are still on most coins.

Not because people are clipping them—but because it became part of the system. It helps the visually impaired distinguish coin types. It’s a design legacy with new uses.

And that’s the point.

Sometimes the systems or rules you want to change were put there to solve problems you’ve forgotten—or never knew existed.

Before you try to improve something, ask:
What problem was this originally trying to solve?

If you don’t know, pause.

That’s the wisdom behind Chesterton’s Fence—a principle by philosopher G.K. Chesterton, who argued that if you find a fence in the road and don’t know why it’s there, you shouldn't tear it down until you understand its purpose.

You don’t have to love the fence.

But you do have to learn why it was built.

I’ve touched on this before, but after hearing several folks say last week that a system needed to be updated simply because it was old, it reminded me how important it is to remember.

This Matters for Influence

Experts, analysts, and leaders often pride themselves on being problem-solvers.

But real influence isn’t just about solving.

It’s about framing.

About understanding the architecture of a system before you redesign it.

And that means resisting the urge to dismiss outdated-seeming processes or assumptions until you’ve done the work of uncovering their origins.

Change without context is just chaos.

Now, I’m not suggesting that change for the sake of change is inherently bad, but I am saying it is never good to simply ignore the past thinking or wisdom behind what exists.

I see this as understanding past context to adapt to new contexts. (And you still need to think strategically without overanalyzing.)

Understanding Before Improving is Essential

Try using the FENCE Framework:

F - Find the Original Problem
E - Examine Who Benefits
N - Notice Unintended Functions
C - Consider Removal Consequences
E - Evolve Rather Than Eliminate

Let’s get it.