Every transformation promises a "new operating model." Few can say what one is. Strip away the consulting gloss and a TOM is a small number of hard choices about how a company turns strategy into everyday work.

"We need a new operating model" is said in boardrooms with the confidence of a phrase everyone understands and the vagueness of one nobody has defined. Ask for specifics and you get a diagram with five boxes and an arrow, or a reorganization announcement, or a new responsibilities matrix. Each is a fragment. The operating model is the thing that should make the fragments cohere — and when it is missing, the fragments quietly contradict each other.

A working definition

An operating model is how an organization is configured to deliver its strategy — the arrangement of capabilities, processes, people, organization, information, and technology that turns intent into day-to-day operation. The current operating model is how you run today. The target operating model, or TOM, is how you intend to run in order to deliver the strategy you have chosen. The gap between them is the actual content of most transformation programs, whether or not anyone names it that way.

What it is made of

A useful TOM answers a consistent set of questions, and the questions are more durable than any template. What capabilities must we have, and how good must each be? How does value flow to the customer, and through which value streams? How are we organized to deliver those capabilities — and, just as important, how are decisions made and who is accountable? What information do we depend on, and where does it live? What technology underpins it? Notice that the org chart is one component among several. Most failed "operating model" work is a reorg wearing the costume of a TOM — it rearranges the boxes without touching the capabilities, decisions, or information flows that determine whether anything actually changes.

Why it should start from capabilities

There is an order that works and an order that does not. Starting from the org chart — who reports to whom in the new world — is the order that does not, because it optimizes structure before anyone has agreed what the structure is for. Starting from capabilities works: decide what the business must be able to do and how well, and the organization, information, and technology choices follow as means to that end. Capabilities are the stable spine of a TOM for the same reason they anchor everything else in this discipline — they change far more slowly than the structures built on top of them.

The choices are the point

A TOM is not really a document; it is a set of choices, and choices are defined as much by what they exclude as what they include. Will we standardize this capability globally or let regions tailor it? Centralize this function for scale or federate it for speed? Build this capability in-house or partner for it? These are genuine trade-offs with genuine costs on both sides. A TOM that reads as if every option is "world-class" and every tension is "balanced" has made no choices at all, which is why it changes nothing. The value is in the decisions a team was willing to commit to and be held to.

A worked example: the reorg that wasn't a TOM

A logistics company announced a "new operating model" that turned out, on inspection, to be a reorganization with a glossary. Three regional structures became two; some titles changed; a new layer of regional directors appeared. What did not change: the capabilities the business ran on, who actually decided what, where the operational data lived, or which systems the work depended on. Eighteen months later the same problems were intact, now distributed across two regions instead of three. The reorg had rearranged the people without touching the model they operated within, which is why it cost a great deal of disruption and changed almost nothing that mattered.

Contrast that with starting from the question the org chart skips: what must we be able to do, how well, and how should decisions about it be made? Answer that first and the structure becomes a consequence rather than the whole plan. A reorganization can be one output of a target operating model. It can never be a substitute for one.

The questions, in order

If a target operating model is a set of choices, it helps to know the order in which to make them, because the order is where most efforts go wrong. Start with strategy: what is the business actually trying to win, and what does that demand it be good at? From there, capabilities: which abilities must we have, and to what standard? Then value streams: how must value flow to the customer, and which capabilities does each stage lean on? Only then organization: how do we group and govern people to deliver those capabilities — and how are decisions made and owned? Then, last, information and technology: what must we know, and what must we run, to support all of the above. The sequence matters because each layer constrains the next. Decide structure before capabilities and you optimize the boxes before anyone has agreed what they are for; choose technology before value streams and you buy systems for work you have not yet defined. Run the questions in order and the answers reinforce one another; run them backwards and they fight.

This is also why a target operating model cannot simply be copied. Two companies in the same industry can adopt identical reference structures and still need different operating models, because they have made different choices about what to win and what to forgo. The diagram may look similar; the decisions underneath it are the strategy, and the strategy is the part no template can supply.

A practical consequence follows for anyone handed a target operating model to implement: read it backwards to test it. Start at the technology and organization choices and ask what capability each one is meant to serve, and what strategic aim that capability supports. If you can trace every structural and system decision back to a capability and an objective, the model is coherent. If you hit a choice that traces to nothing — a reorganization no capability needed, a platform no value stream asked for — you have found the part that was decided for reasons other than strategy, and it is usually the part that quietly undoes the rest.

Why most TOMs fail

They fail for two reasons, and neither is the quality of the diagram. The first is that they stop at the picture: a glossy target with no transition architecture — no sequenced path of changes from here to there — so the organization admires the destination and keeps driving the same road. The second is that they are never connected to funding and delivery, so the daily flow of decisions and money continues to run on the old model while the new one lives in a binder. A TOM only matters to the degree that real budget and real reporting lines bend toward it. Treat it as a living model the business steers by — current versus target, every gap traced to an initiative — and it becomes useful. Treat it as a deliverable to be filed, and it becomes another beautifully rendered destination no one is actually driving to.

Architects often treat the operating model as someone else’s problem — HR’s, perhaps, or the COO’s. This is a mistake. The operating model is the architecture, expressed through people, decisions, and incentives instead of systems and data.

You can have the cleanest target architecture in the world. If the operating model says budgets are owned by 27 business units that each fund their own IT, you will not get one platform — you will get 27. If the operating model says careers are made by launching new products, you will not get rationalization — you will get sprawl.

Systems follow incentives. Architecture follows accountability. If you want to change the architecture, you eventually have to change the operating model. If you don’t have a seat at that table, you’re drawing diagrams the org will silently overrule.

Digital & Transformation

A target operating model is a description of how an organization intends to run in the future in order to deliver its strategy — the intended arrangement of capabilities, value streams, people, organization, information, and technology. The "target" distinguishes it from the current operating model, which is how the organization runs today.

It is broader than an org chart. Structure (who reports to whom) is one element; a TOM also covers what the business must be able to do, how decisions are made, what information it relies on, and what technology supports it. Reducing a TOM to a reorganization is the most common way it fails to change anything.

A TOM is most useful when built from capabilities outward and paired with a transition architecture — the sequenced path from current to target. Without that path it is a destination with no route; with it, the gap between current and target becomes a portfolio of fundable, traceable changes.

A capability map, neatly tiered,
Was admired, applauded, revered.
Then a merger came through,
Split the company in two —
And the map simply up and disappeared.