# The Value of Proven Systems

**Created:** 2025-08-01\
**Category:** Timeless Lessons, System Thinking, Field Notes

I know someone, let’s call him Tom, who was wildly successful in business. Ran it for over 40 years and retired a multimillionaire. He knew what he was doing because he earned it. The knowledge wasn’t theoretical. It came from four decades of trying, failing, refining, and building a system that worked.

In 2008, after the crash, Tom offered to back someone named Jerry, who had just lost his job. He gave Jerry $2 million to start the same business. The catch? Tom wasn’t just handing over money. He handed Jerry Tom's blueprint. A full breakdown of how to run the business. A system that worked. All Jerry had to do was follow it.

And at first, he did. For four years, everything went great—profits, growth, stability, exactly what Tom’s plan predicted.

Then Jerry did what most people do: he started making changes.

Not huge ones. Just tweaks. A few “improvements.” Personal touches. Things he thought made sense.

And that’s when it all fell apart. The moment Jerry deviated from the proven system, results tanked. And the more he adjusted to fix the fallout from his changes, the worse things got. Eventually, the business failed, and Tom pulled the plug.

Why?

Because Jerry couldn’t see what Tom’s system was protecting him from. The value wasn’t just in what the system did; it was in everything it avoided. Forty years of trial and error baked into one streamlined process. All the “don’t do this” lessons were invisible to Jerry.

This story exposes a dirty little secret:

When people are handed something proven, a working system, a time-tested plan, or even a productivity book, they seldom follow it as-is.

They tweak it. Personalize it. Cut what they don’t like.\
And in doing so, they break it.

It’s human nature to want ownership. But customizing before understanding is a fast track to predictable failure, especially when the original was built on decades of refinement and learning what not to do.

Jerry thought he could improve a machine he didn’t even know how to operate.

It’s like baking a cake. You can’t remove eggs or cut the flour in half and still expect it to rise. The recipe isn’t just a suggestion; it’s the result of someone else’s failed experiments. The moment you start tweaking without understanding, it’s no longer that cake on the box. It’s something else. And when it fails, you can’t blame the recipe.

Systems are the same way. Change them too early, and you’re not improving anything; you’re just throwing away the part you didn’t recognize that was holding it together.

<figure><img src="https://474306782-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F3YVknxQjTY2AXSlwtWgR%2Fuploads%2FXeJtzKucGQgoHqNhnZ1m%2FScreenshot%202025-07-31%20at%208.36.53%E2%80%AFPM.png?alt=media&#x26;token=1c4126fb-f935-4be5-8179-f225c977b684" alt=""><figcaption></figcaption></figure>

All of my posts are intrinsically tied together. I've been using and talking about the same system for 40 years, and how it has evolved. Most problems aren’t the result of not knowing what to do; they’re the result of not following what already works. Here is my earlier post. That little book in the image? That’s the system I’ve been talking about for decades.
