Week 23: "Best Practice" Is the Enemy of Improvement. Here's What to Do Instead.
"Best Practice" Is the Enemy of Improvement. Here's What to Do Instead.
I've lost count of the number of times a leadership team has asked me the same question.
"What's the best practice for this?"
They want the benchmark. The template. The proven model from Toyota, or Amazon, or Shell, or whoever is winning right now. They want to skip the thinking and go straight to the answer. Copy what works. Implement. Move on.
I understand the impulse. When you're under pressure, when the board is asking for results, when the market is shifting and you need to move fast — the idea that someone else has already solved your problem is enormously attractive. Just give me the playbook.
But after twenty years, forty-plus organisations, and a career that includes thirteen years at Shell, CI leadership at Johnson Controls across EMEA and Latin America, and Head of CI at KCA Deutag — I can tell you with absolute certainty that "best practice" as most organisations pursue it is one of the most dangerous concepts in business.
Not because the practices themselves are bad. But because copying them without understanding why they work almost always produces failure.
Let me tell you what happens when organisations copy Toyota.
I've watched it happen dozens of times. A leadership team visits a Toyota plant. They're impressed. The visual management, the pull systems, the andon cords, the kaizen culture, the relentless pursuit of waste elimination. It's beautiful. It's effective. It's everything they want their operation to be.
They come home inspired. They hire consultants. They install kanban boards. They put andon lights on the production lines. They create a kaizen programme. They start using Japanese words in their daily meetings.
Six months later, the kanban boards are decoration. The andon lights go off and nobody responds. The kaizen events have stopped because nobody can get people released from their "real work." The Japanese words have become a joke among the operators.
What went wrong?
They copied Toyota's practices without understanding Toyota's culture. They imported the tools without importing the thinking. They replicated the visible elements — the boards, the lights, the terminology — without replicating the invisible elements: the discipline, the leadership behaviour, the respect for people, the decades of cultural investment that makes those tools function.
A kanban board is not a visual management tool. It's the visible expression of a pull-based production philosophy supported by levelled scheduling, reliable processes, capable suppliers, and leaders who respond when the board shows a problem. Without all of those supporting elements, a kanban board is a piece of paper on a wall.
Copying Toyota without understanding Toyota is like copying a chef's recipe without understanding how to cook. You have the same ingredients. You follow the same steps. But the result isn't the same, because the chef's skill — the judgment, the timing, the feel for the process — isn't in the recipe. It's in the cook.
I saw the exact same dynamic at Shell, from the other side.
Shell's CI programme was successful. Genuinely successful. Billion-dollar-plus in documented savings. Three hundred practitioners trained. Twelve thousand FTEs touched. The programme had a methodology, a governance framework, a training curriculum, and a cadence that worked.
Other organisations looked at Shell's CI system and wanted to copy it. I fielded requests from industry peers, consultants, and benchmarking teams who wanted to understand "the Shell model" so they could implement it in their own organisations.
And I always gave them the same warning: be careful what you copy.
Shell's CI system worked because of Shell's operating environment. The company had a strong engineering culture that valued data and evidence. It had a mature management system that provided the governance backbone for CI deployment. It had operations directors who understood that visible leadership presence was non-negotiable. It had a scale that allowed investment in dedicated CI practitioners at every major site.
These conditions didn't exist in most of the organisations that wanted to copy the model. A mid-size manufacturer with a hundred employees can't replicate a programme designed for an operation of twelve thousand FTEs. A company with a command-and-control culture can't successfully deploy tools that depend on frontline empowerment. An organisation where leaders don't go to the Gemba can't sustain improvements that require visible leadership engagement.
The Shell model wasn't the answer. Understanding the principles behind the Shell model, and adapting them to a different context — that was the answer.
I call this the difference between "best practice" and "next practice."
Best practice says: someone else solved this problem. Copy their solution.
Next practice says: someone else solved a similar problem. Understand the principle behind their solution. Then design your own solution that applies that principle to your context.
The principle is transferable. The practice usually isn't.
Let me give you a concrete example.
One of the principles behind Toyota's production system is making problems visible immediately so they can be addressed before they propagate. The practice Toyota uses to implement this principle includes andon cords, visual boards, and fixed-position stop systems.
The principle — make problems visible immediately — is universal. It applies in manufacturing, in services, in drilling, in finance, in healthcare. Every operation benefits from surfacing problems quickly.
But the practice — andon cords and visual boards — is context-dependent. An andon cord makes sense on a production line where stopping the line prevents defects from propagating. It makes less sense in a shared services centre processing invoices. The principle still applies. The implementation must be different.
At Johnson Controls, we applied the principle of immediate problem visibility in a EMEA service operation by implementing a simple red-amber-green status board that was updated every morning during the stand-up. No technology. No Japanese terminology. Just a visual signal that told the team and the leadership where the problems were, every day, before the problems had time to escalate.
It worked brilliantly. Not because it was Toyota's practice. Because it was Toyota's principle, adapted to Johnson Controls' context.
Here's where this gets uncomfortable for consultants and for leaders who want quick answers.
Adapting principles to context is harder than copying practices. It requires understanding. It requires thinking. It requires knowing your own organisation — its culture, its capabilities, its constraints, its maturity — well enough to design solutions that actually fit.
Copying is fast. Adapting is slow. Copying feels decisive. Adapting feels uncertain. Copying produces a visible output — boards, templates, programmes — that leadership can point to and say "we're doing CI now." Adapting produces less visible but more durable results.
I've worked with organisations that preferred the visible copy over the invisible adaptation. The board on the wall looked good. The programme structure impressed the auditors. The leadership could present it confidently at the annual review.
But it didn't work. Because it wasn't theirs. It was borrowed. And borrowed practices, implemented without understanding, don't take root. They're transplanted organs that the organisational body rejects.
The organisations that succeed with continuous improvement are the ones that invest time in understanding why something works before deciding how to implement it.
At KCA Deutag, we didn't copy Shell's CI system. I'd spent thirteen years building Shell's system, so I understood it as well as anyone. But KCA Deutag was a different company. Different industry context, different organisational structure, different culture, different scale. Drilling operations have a fundamentally different rhythm than refinery operations.
What we did instead was extract the principles that made Shell's programme effective and rebuild them for a drilling context.
The principle of cadence — regular, non-negotiable reviews — we implemented through a format designed for rig-based operations, not office-based governance. The principle of visible leadership — Gemba walks, presence, follow-up — we adapted for a context where the "Gemba" was a drill floor, not a factory line. The principle of structured problem-solving — A3 thinking, root cause analysis — we deployed with examples and templates drawn from drilling operations, not manufacturing.
Same principles. Different practices. Better results than copying would have produced, because the practices fit the context.
There's one more thing I want to say about best practice, and it's the most provocative point.
Best practice, by definition, is backward-looking. It tells you what worked somewhere else, in the past, in a different context. It's a snapshot of someone else's journey at a specific point in time.
Improvement, by definition, is forward-looking. It asks: what's the next better way? Not what's the current best way somewhere else. What's the next step for us?
When you pursue best practice, you're aiming for where someone else is. When you pursue next practice, you're aiming for where you need to be. Those are rarely the same destination.
The organisations I admire most — and Shell was one of them at its best — didn't benchmark themselves against others to copy. They benchmarked themselves to learn. To understand principles. To challenge their own assumptions. And then they designed their own path forward.
So here's my challenge.
The next time someone in your organisation says "what's the best practice for this?" — challenge them.
Ask instead: "What's the principle behind the practice? And how does that principle apply in our context?"
It's a harder question. It requires more thought. It won't give you a template to implement by Friday.
But it will give you something better: an improvement that actually works. Because it's yours. Because it fits your culture, your capability, your constraints. Because it's built on understanding, not imitation.
Best practice is where improvement goes to die. Next practice is where it comes alive.
Which one is your organisation pursuing?
If you want to develop the depth of CI capability that allows your team to adapt principles to context rather than copy templates — the CI Practitioner Mastery Program builds exactly this skill across sixteen structured modules. Find it at stormholt.org/products/stormholt-self-paced-continuous-improvement-foundation.
New to Stormholt? Start here — it locates your stage in minutes.
Building capability? Stage III — Skill — the tools, the courses, the simulations.