What an operating model is
An operating model is how a business actually gets work done: which decisions are made where, who holds authority over what, how work moves between functions, what is measured, and what those measures reward.
It is distinct from the organization chart, which describes reporting lines rather than decision flow. Two companies with identical structures can have completely different operating models, and the operating model is the one that determines the result.
Most operating models were not designed. They accumulated — through growth, reorganisation, and the addition of controls after things went wrong. Each addition was reasonable at the time. The composite was never reviewed as a whole.
How to recognise this as your constraint
Four signals, each observable without a diagnostic exercise.
Every function reports acceptable performance and the overall result does not move. This is the clearest indicator. It means the problem is in the space between functions, which no single function measures or owns.
Decisions require an unusual number of people to agree. Where authority has been distributed across functions without a mechanism to resolve disagreement, the default resolution is delay.
The same issue is escalated repeatedly. Recurring escalation of one topic means the decision has no owner at the level where it arises. Escalation is functioning as a substitute for allocated authority.
Improvement initiatives deliver locally and not in aggregate. Each function optimises its own portion; the total is unchanged because the constraint is in the handoffs nobody owns.
Why this is difficult to see from inside
Two reasons, and both are structural rather than a failure of attention.
Everyone sees their own portion. A function head sees their function performing well, because it is. The gap is in the interval between functions, and it is nobody's reporting line.
The sequence is treated as given. The order in which work happens is usually the order it has always happened. Once a sequence has been in place long enough, it stops being a decision anyone remembers making and becomes a description of how the work is.
The most productive question available to an executive team is therefore a simple one: which of these steps genuinely has to wait for the one before it?
What the question surfaces
In a turbine maintenance engagement, the constraint was the length of the maintenance window. Disassembly, inspection and reassembly ran strictly in series, with decision points between stages, and access, isolation and safety preparation layered on top.
Each stage was managed competently and improved against its own targets. The available time was not inside the stages. It was in the order they ran in — a sequence that had been inherited rather than designed, in which steps waited on each other that did not have to.
That is the characteristic shape of an operating-model constraint. No component is underperforming. The coordination between components is where the result is lost, and no component's improvement plan can reach it.
A BMW engagement produced a less intuitive version of the same finding. The subject was robotic automation, and the redesign did not make the robots faster or add more of them. It changed the sequence and allocation of the work they were doing, and the number of robots the process required came down. The counter-intuitive part is worth sitting with: more automation was not the answer to an automation problem.
What operating-model redesign involves
Map the path end to end, across functions. Follow the work from the decision that starts it to the result that ends it, through every function that holds a step, a dependency, or an approval. The map is not the deliverable; locating where time and decisions accumulate is.
Test each dependency. Establish for each step whether it genuinely depends on the prior step, or whether the order is convention. This is where most of the available change is found.
Reallocate decision rights. Name who decides what, at what level, and what happens when there is disagreement. Distributed authority without a resolution mechanism produces delay reliably.
Hold the conditions fixed. State the cost and quality conditions the redesign must respect before it starts. Speed bought by lowering either is not a redesign; it is a trade, and it should be made explicitly if it is made at all.
What this requires from the executive team
An operating-model redesign cannot be delegated to any single function, because no single function holds the authority to change how the others coordinate. It needs a sponsor who can convene the people who own each step — including those who only hold a decision.
That is a real precondition and worth stating before an engagement rather than discovering during one. Where an executive sponsor cannot convene that group, the work will produce a design and not a change.
Where this does not apply
Where the constraint is genuinely within one function — a capacity limit, a skills gap, a piece of equipment — it can be resolved there, and framing it as a coordination problem adds cost without adding insight. The test is whether the functions individually report acceptable performance. If one does not, start there.