Every leader has lived this contradiction: a team that is plainly working flat out, and a customer who is plainly still waiting. Everyone is busy, nothing is idle, and yet the thing takes forever. Operational excellence is the discipline of resolving that contradiction, and the first surprise is that "everyone busy" is frequently the cause of the delay, not the cure for it.

The quick version

  • Operational excellence means delivering the right result reliably and repeatedly, not as a heroic effort, but as the normal output of how the work is set up.
  • Efficiency has two meanings, and they fight. Keeping people busy (resource efficiency) and getting work through fast (flow efficiency) pull in opposite directions; most organisations optimise the wrong one.
  • One thing limits the whole system. A process only moves as fast as its slowest step, so improving anywhere except the bottleneck just builds up work in front of it.
  • It lives in the culture. The versions that last rest on respect for the people doing the work and a steady habit of improving it, not on a binder of techniques.

The idea in depth: excellence is a property of the system, not the people

The most useful definition comes from the Shingo Model, the framework named for the Japanese industrial engineer Shigeo Shingo and maintained by the Shingo Institute at Utah State University (the model and its assessment guidelines were first published in January 2008). Its central claim is bracingly simple: ideal results require ideal behaviours, and behaviours are driven by the systems and culture around them. Excellent outcomes, in this view, are not produced by exceptional people trying harder, they are produced by ordinary people inside a system designed so that the right thing is also the easy thing. The model's principles put "Respect Every Individual" and "Lead with Humility" alongside the technical ones like "Improve Flow & Pull" and "Focus on Process," because it treats how you treat people as an operational variable, not a soft extra.

That changes where you look when something goes wrong. The reflex is to ask who dropped the ball; the operationally-excellent reflex is to ask what about the process made dropping it likely. A missed handover, or a step everyone gets wrong, is almost never a discipline problem and almost always a design problem. Pick the failure your team grumbles about most and, before you assign any blame, map the steps that led to it. Nine times out of ten the fault was baked into the route, not the runner.

Why being "efficient" can make you slower

Here is the idea that reframes the whole topic. There are two kinds of efficiency, and chasing one tends to wreck the other. Niklas Modig and Pär Åhlström lay this out in This Is Lean: Resolving the Efficiency Paradox (2012). Resource efficiency is keeping your people and machines busy, high utilisation, no idle hands. Flow efficiency is how quickly a single unit of work travels from "need identified" to "need met." Both sound like efficiency. They are not the same, and the paradox is that pushing resource efficiency to the limit destroys flow.

The mechanism is queues. When every person is loaded to 100%, every new piece of work arrives to find the next person already busy, so it waits. Modig and Åhlström's point is that an organisation obsessed with keeping everyone occupied generates a mountain of secondary work: chasing, re-explaining, expediting, handling the complaints the waiting itself created. The harder you push to look efficient, the more of this non-value work you manufacture, and the slower real work moves. It is the lesson any commuter knows, a motorway at 100% capacity isn't fast, it's a traffic jam.

A team loaded to 100% isn't operating at peak efficiency. It's a traffic jam that hasn't formed yet.

The practical fix is to stop measuring busyness and start measuring the wait. Take one important piece of work and track two numbers: the total elapsed time from request to delivery, and the actual hands-on working time inside it. The ratio between them, flow efficiency, tends to be shockingly low. Often under a quarter; sometimes single digits. That gap isn't your people slacking. It's work sitting in queues. Leave a little deliberate slack in the system, so the next step is free when work arrives, and you will frequently deliver faster end-to-end than a fully-loaded team ever manages.

flowchart LR
  A(["Resource efficiency
keep everyone busy (100%)"]) --> B(["Every task arrives to
a busy next step"])
  B --> C(["Work waits in queues"])
  C --> D(["Secondary work appears:
chasing, expediting, rework"])
  D --> E(["Slower end-to-end,
even though no one is idle"])
The efficiency paradox: maximising how busy people are can lengthen how long the work takes. Leaders Loop

Find the one constraint that governs everything

If flow is the goal, the next question is where to improve, and the answer is rarely "everywhere." Eliyahu Goldratt's Theory of Constraints, set out in his 1984 business novel The Goal, rests on one durable observation: every system has at least one bottleneck, a single slowest step that sets the pace for the whole thing. Goldratt's famous illustration is a line of hikers on a trail: the group can only move as fast as its slowest walker, no matter how quick everyone else is. Speed up a fast walker and you don't speed up the group; you just spread the line out.

The practical consequence is counter-intuitive and freeing: an improvement made anywhere other than the bottleneck does not speed up the system. Make a non-constraint faster and you simply pile up more half-finished work in front of the real blockage. Goldratt's five focusing steps follow from this: identify the constraint, exploit it (get every drop out of it before spending a cent), subordinate everything else to its pace, elevate it (add capacity if you still need to), then go find the next one. In other words: resist the pull toward the parts that are easy or visible to fix. Find the single step where work piles up, and guard that step's time as your scarcest asset. Most "we need more people / more budget" requests quietly evaporate once you see you'd been investing everywhere except the one place it mattered.

An honest limitation. These ideas describe how to make work flow; they say very little about whether you are flowing the right work. A process can be beautifully Lean and ruthlessly de-bottlenecked while efficiently producing something customers don't want, and operational discipline can curdle into rigidity that punishes the experimentation a changing market demands. There is also a sobering pattern in the evidence on continuous-improvement programmes: they stall far more often for human reasons, thin leadership commitment, vague goals, change fatigue, than for any flaw in the method (a point detailed in the Lean, Six Sigma & Kaizen explainer). Treat operational excellence as a way to do the right work superbly, never as a substitute for deciding what the right work is.

A worked example

Take a regional insurer's claims team, call it Meridian. (Illustrative figures throughout; this is a teaching example, not real data.) Customers complain that simple claims take "ages." The operations lead pulls the metric everyone reaches for first, staff utilisation, and it reads a proud 94%. Nobody is idle. By the only number being watched, the team is excellent. By the customer's experience, it is failing. That contradiction is the whole problem in miniature.

So they measure the right things instead. First, flow efficiency: a typical claim takes an illustrative 11 days end to end, but the actual hands-on work totals about 4 hours. Flow efficiency is therefore under 5%, the claim spends 95% of its life waiting in someone's queue. The team wasn't slow; the work was parked.

flowchart TD
  A(["Claim received"]) --> B{"What's the real
problem here?"}
  B -->|"Utilisation says"| C(["94% busy,
looks excellent"])
  B -->|"Flow efficiency says"| D(["~11 days elapsed,
~4 hrs of work,
95% waiting"])
  D --> E(["Find the constraint:
one senior assessor
signs off every claim"])
  E --> F(["Exploit & subordinate:
assessor only does
sign-offs; others prep"])
  F --> G(["~11 days → ~4 days
(illustrative), no new hires"])
Same team, two stories: utilisation flatters it; flow efficiency exposes the wait and points to the bottleneck. Leaders Loop

Next, the constraint. Mapping the route reveals a single senior assessor who must personally approve every claim above a trivial threshold. Every claim, however simple, eventually queues behind that one desk. That is the hiker setting the pace for the line. Applying the focusing steps, they exploit the constraint, the senior assessor stops doing claim preparation and document-gathering (which junior staff can do) and spends their whole day on the one thing only they can do: sign-offs. They subordinate the rest of the team to feed that desk a steady, ready-to-approve stream rather than a lumpy pile. The illustrative result: average resolution falls from roughly 11 days to about 4, complaints drop, and not one extra person was hired. Utilisation actually went down, and the team got faster. That inversion is the heart of the topic.

Frequently asked questions

Isn't operational excellence just cost-cutting with a nicer name?

It often gets used that way, which is why it has a mixed reputation. But the discipline as defined, by the Shingo Model and Lean thinking, is about removing waste and delay, which frequently lets you serve customers better and cheaper at once. Cost-cutting trims resources and hopes the work survives; operational excellence improves the work so the same resources do more. The tell is direction: cutting starts from a budget target, excellence starts from a customer outcome.

What's the difference between operational excellence and Lean or Six Sigma?

Think of operational excellence as the destination and the methods as the vehicles. Lean (remove waste, improve flow), Six Sigma (reduce variation), Kaizen (improve continuously) and the Theory of Constraints (manage the bottleneck) are specific disciplines you draw on. Operational excellence is the broader, principle-led state they aim at: a system that reliably produces ideal results because its culture and design make that the path of least resistance.

How do I measure it without drowning in dashboards?

Start with one number that resists gaming: flow efficiency (hands-on time ÷ total elapsed time) for your most important process. It exposes waiting, which utilisation hides. Pair it with one quality measure (how often you get it right first time) and one outcome measure the customer feels (time to resolution). Three honest numbers beat thirty vanity ones. Be wary of utilisation as a headline metric, it rewards exactly the busyness that slows you down.

We're a service or knowledge team, not a factory. Does this apply?

Yes, and arguably more, the waiting is just less visible. In a factory you can see inventory piling up; in a knowledge team the "inventory" is invisible: tickets in a queue, documents awaiting approval, decisions parked pending a meeting. The questions travel intact. Where does the work wait? What single step sets the pace? Are we measuring how busy people are, or how fast the work flows? The vocabulary changes; the physics doesn't.

Why do so many "operational excellence" initiatives quietly die?

Usually for human reasons, not technical ones. The recurring failure pattern across improvement programmes is weak and inconsistent leadership attention, objectives nobody can state plainly, and change fatigue, not faulty tools. The guard is to keep the scope small, tie every effort to a problem people actually feel, and have a leader stay visibly interested well past the launch event. Momentum is what fails first, long before method does.

Related in the Toolkit

Operational excellence is the destination; several Toolkit modules are the roads to it. The specific methods live in Lean, Six Sigma & Kaizen, and the cadence that turns one-off fixes into a habit comes from your delivery methodology.

Where to go next