Operational excellence starts where work actually happens

More than once I’ve watched operational excellence being discussed at the wrong altitude.

We talk about frameworks, operating models, maturity levels, and target states. Which are all very useful concepts, but often the key failing is that we skip the part where we talk about where and how the work actually gets done.

The result is likely familiar to a lot of you…

• strategies that make great sense on slides but without tangible execution plans
• processes that look good on paper but without adoption plans
• and teams who quietly work around both to get critical ‘stuff’ done

To really improve operations, you must start closer to the ground and build momentum (if you look at any big shifts in history, you will note a theme).

 Why top-down improvements can stall out
I’ve been involved in plenty of improvement initiatives that had the best intentions and had been well designed but still didn’t land any measurable improvement forward.

Not because people resisted them, but because they didn’t line up with reality the operational teams are working within.

Many times, I’ve personally witnessed a new operational process being introduced to improve consistency and governance. It was logical, documented, and approved. But within weeks, teams had created unofficial shortcuts.

The following assumption killed adoption...

• cleaner handoffs than actually existed
• fewer interruptions than people experienced in the real world 
• and more context than was realistically available at the point of execution

 The process wasn’t wrong in any way! it was simply designed way too far from the people completing the work.

The workarounds are the signal
One of the most reliable indicators that something isn’t working isn’t complaints, it is the workarounds. While these can be somewhat hidden, any operational leader will be able to note these within their team.

You will start to see signs, people maintaining side spreadsheets, rely on specific individuals “who know how this really works”, and looking to bypass tools or steps to keep things moving in line with expectations.

These can be really frustrating, but they are telling you something important, we need to see recognise these behaviours aren’t (always) laziness or resistance. They’re adaptation to meet wider commitments and expectations.

Operational excellence improves fastest when leaders treat workarounds as data, not failure.

Why operating models fail without local context
Operating models are meant to create clarity and alignment. But when they are rolled out without enough grounding, they can unintentionally increase friction.

I’ve seen operating changes that:

• added steps but didn’t remove any
• introduced roles without adjusting decision rights
• clarified accountability on paper while blurring it in practice

From the operational team’s perspective, the work didn’t feel more excellent it just felt heavier.

Operational excellence shouldn’t be about adding structure. It needs to be clearly focused on removing unnecessary effort where it’s actually felt.

What changes when you design with the work at the centre? 
When improvement starts at the point of execution with a good level of base understanding, I’ve seen a few important things start to shift.

Ownership becomes clearer
Instead of abstract accountability, responsibility aligns with real decision making.

Metrics become simpler
You stop measuring activity and start measuring the friction…think of the delays, re-work, handoffs, uncertainty.

Improvements compound
Fixing something at the source often removes multiple downstream problems you didn’t even know were connected.

Some years ago I saw personally that addressing a single ambiguous handoff reduced incidents, shortened resolution times, and lowered escalation volume without changing any tools.

The system got better because the work got easier, which is exactly what we all want! 

 Excellence isn’t uniformity, it’s all about fit
One trap to avoid: assuming operational excellence means everything must look the same.

Consistency matters but forced uniformity often ignores context and can cause issues I referenced earlier. 

What matters far more is:

• clarity at decision points
• predictable behaviour under pressure
• and shared understanding of what “good” looks like in practice

Operational excellence is less about standardising everything and more about ensuring the system behaves reliably, especially when conditions aren’t ideal.

Closing thought
Operational excellence doesn’t begin with frameworks (they will come in to play later in the game)

It all starts with taking the time and paying attention to how work is done and kicking off your design from there.

Observe the work.

Reduce friction.

Operate with intent.