19 Mar
Most ops problems aren’t caused by complexity. They’re caused by premature simplicity.
I was on a sales call recently with a company that wanted to standardize their operations across teams.
Their ask was simple: “We just need you to document a better way of doing it.”
I asked: “Do you have the current state mapped?”
No.
“Do you know why each team does it differently?”
Not really.
“Do you understand the constraints? What’s driving the variation?”
Silence.
Here’s what they were really asking: skip the diagnosis and jump to the solution.
I get it. It feels efficient. Why waste time documenting a broken process when you already know you want something better?
But here’s the problem. If you don’t understand the details, you’re not simplifying. You’re guessing. And guessing creates a new mess dressed up as a solution.
Premature simplicity is one of the most expensive mistakes companies make.
You standardize before you diagnose, and the standard doesn’t fit.
You automate a broken process, and now the breakage runs faster.
You cut corners before you understand the business, and wonder why nothing sticks.
It looks like progress. It feels like momentum. But six months later you’re back where you started. Except now you’ve burned budget, burned trust, and burned out the team that tried to make it work.
James Clear said it well:
“To simplify before you understand the details is ignorance. To simplify after you understand the details is genius.”
That second kind of simplicity is what actually scales.
Here’s what real simplicity looks like:
It looks like mapping the current state, even when it’s ugly, so you understand why things work the way they do before you change them.
It looks like documenting only what drives results. Not creating a 50-page SOP that no one reads.
It looks like giving teams guardrails, not rulebooks.
It looks like automating the boring stuff after it works manually. Not before.
It looks like killing the tools and steps that exist “just in case” but add zero value.
It looks clean. But it works hard.
That’s the difference between lazy design and intentional simplicity.
Lazy design skips the hard part. It jumps to the answer because the diagnosis feels slow. It creates something that looks simple but breaks under pressure.
Intentional simplicity earns the right to be simple. It does the work upfront so the solution actually holds.
Back to that sales call. The “aha” moment came when I reframed it:
“If we document a better way without understanding the current way, how will we know it’s actually better? And how will your teams trust it when they weren’t part of the process?”
We’re not in the business of making things look simple. We’re in the business of making things work.
Anything else is just lazy design.