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.

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.)

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.

Before changing anything, investigate:

What fails: "This weekly meeting is a waste of time."

What works: "What problems was this meeting originally solving, and do those problems still exist?"

Always identify:

What fails: "No one uses this report anymore."

What works: "Let me check with all departments to understand how they use this information."

Look for unexpected uses:

What fails: "This approval process just slows things down."

What works: "What quality checks, relationship building, or knowledge transfer happens during this approval process?"

Think through the impacts:

What fails: "We'll just eliminate this and see what happens."

What works: "If we remove this, what safeguards need to replace it, and who needs advance notice?"

Design thoughtful transitions:

What fails: "We're replacing this system immediately."

What works: "We'll keep the community connection aspect while modernizing the information sharing."

Every system is a story. If you skip the prologue, you’ll misunderstand the plot.

True influence doesn’t come from breaking things.

It comes from knowing exactly what you’re breaking—and what you’ll replace it with.

So next time you think, “Why do we still do it this way?”—dig deeper.

You might just find an old solution that still has something to teach you.

Thanks for reading. Be easy!
Girvin