Operating Model Design: The Skeleton, Not the Wiring

“Operating model” is one of the most overloaded terms in enterprise language. Ask five executives what it means and you will get an org chart, a process map, a technology architecture, a governance model and a list of locations.

The confusion is not academic. It is the reason operating model work so often produces a document that everyone approves and nobody can act on: the participants were designing different things.

A working definition

The operating model is the strategy-derived blueprint of how the organisation will actually run: what capabilities it needs, how those capabilities are arranged, how work flows between them, and where decisions are made.

Two words in that sentence carry the weight.

Strategy-derived. An operating model is not designed in the abstract. It is derived from a strategy — from where-to-play choices, from how the organisation intends to compete. An operating model designed without a strategy above it is just a reorganisation with better vocabulary.

Blueprint. It is a design, not an implementation. It specifies structure and intent. It does not specify which system handles which transaction.

That second distinction is where most operating model programmes go wrong, and it is worth being precise about.

Skeleton and wiring

Think of it as two layers.

The skeleton is the structural design: the capability model, how capabilities group into units, the decision rights, the flow of work between capabilities, the interfaces that must exist. This is derived from strategy, and it is a methodology question — it has right and wrong answers relative to the strategy it serves.

The wiring is the implementation: which systems, which integrations, which data flows, which platform, which vendor. This is an architecture question, and it is craft. It depends on the existing estate, on technical constraints, on skills available, on ten thousand specifics that no methodology can anticipate.

Both are necessary. They are not the same discipline, and they should not be conflated.

We are explicit about which side we work on: UNITE designs the operating model — the strategy-derived skeleton. Wiring your IT architecture remains your architects’ craft.

That boundary is stated deliberately. A system that claimed to do both would be overpromising, and the failure would land on your architects.

Why programmes conflate them

Because the wiring is more concrete and therefore feels more like progress.

Six weeks into an operating model programme, the skeleton work is producing capability definitions and decision-right maps — abstract artefacts that are hard to demo. Meanwhile a parallel workstream can show an integration diagram. Leadership attention drifts to the visible artefact, and the skeleton work is quietly compressed.

The result is an implementation with no defensible design behind it. Six months later, when the question arises of why the customer-service capability sits where it does, the honest answer is that it is where the systems put it.

What good skeleton work produces

Four artefacts, and they are all structural rather than technical.

A capability model. What the organisation must be able to do, expressed as capabilities rather than departments — because departments are an implementation of capabilities, not the other way around. Derived from strategy: each capability should be traceable to something the strategy requires.

A grouping rationale. Which capabilities sit together and why. This is where most of the real design work happens and where most of the disagreement lives, because grouping determines coordination cost.

Decision rights. Who decides what, at which level. This is chronically underspecified. Most operating model documents describe structure and leave decision rights implicit, which guarantees that the first difficult decision escalates.

Interfaces. Where capabilities must hand off to each other, and what has to pass across the boundary. Interfaces are where operating models fail in practice, and they are almost never designed explicitly.

The target operating model as a designed, traceable blueprint — not a reorganisation with better vocabulary.

The traceability requirement

There is one property that separates an operating model that survives from one that gets quietly abandoned: every element should be traceable to the strategy it derives from.

Not as documentation hygiene. As a working mechanism.

When the strategy changes — and within the lifetime of an operating model implementation, it will — the question is which parts of the design are still valid. If the design is traceable, that question is answerable by traversal: this strategic choice changed, therefore these capabilities and this grouping are in question.

If it is not traceable, the organisation faces a choice between implementing a design that no longer matches its strategy, or restarting. Both are expensive; the first is worse, because the misalignment is invisible until it produces symptoms.

The sequencing that works

The pattern we see work is unfashionably linear at the top and iterative below.

Strategy first, with enough specificity that capability requirements can be derived from it. Then the skeleton, designed against that strategy and traceable to it. Then wiring, designed against the skeleton by the people who know the estate.

What does not work is designing the skeleton and the wiring concurrently by different teams with different masters. That produces two designs that meet in a steering committee, and the wiring wins, because it has dates.

A practical test

Take your current operating model documentation and pick any structural element — a unit, a grouping, a reporting line.

Ask: which strategic choice is this derived from? Then ask the person who owns that element the same question.

If the answers differ, or if either answer is a historical explanation rather than a strategic one, the operating model is not strategy-derived. It is the accumulated residue of previous reorganisations, and it will keep producing coordination problems that no amount of implementation quality can fix.