The three attributes of a Target Operating Model that actually works

This is Part 4 of the Rethinking the Target Operating Model series. The discipline has had a comeback — McKinsey's 2025 survey of 2,000 executives shows 63 percent of redesigns now meet most of their objectives, up from 21 percent in 2014. The success rate tripled because the traditional target operating model rested on two assumptions that no longer hold: that people execute the work, and that line leadership can translate principles into specific action. Part 2 — Why four out of five Target Operating Models failed for a decade walks through what changed and why. The broader frame this work sits inside is operating model architecture.

This article is the practitioner's view of what a modern target operating model actually looks like, and how to design one.

Dimensions and attributes are not the same axis

Before naming the attributes, one distinction has to be clear, because conflating the two is where most operating-model conversations go sideways.

Part 2 established the four dimensions every operating model designs across — WHAT work gets done, WHO does it, HOW it runs, and WHERE it happens. Those four are the surface area of any operating model, traditional or modern. They do not change. A 2003 TOM and a 2026 TOM both design across the same four.

What changed is the character of the design — how deep it reaches, whether it stays current, and who holds it after the consultants leave. Part 2 named three responses mainstream practice absorbed that account for the comeback. This article builds those responses into three attributes a modern target operating model has and the traditional version lacked.

Keep the two axes straight:

• The four dimensions are what you design across. WHAT, WHO, HOW, WHERE.
• The three attributes are what make the design work in the Age of AI.

A model can name all four dimensions and still fail all three attributes. That is most of the binders. The dimensions tell you the work is comprehensive. The attributes tell you whether it will run.

The three attributes

Three attributes separate a modern target operating model from the binder-era version: Operational Depth, Continuous Adaptation, and Execution Accountability — depth, cadence, ownership. They work as a set, not a menu. Here is what each looks like in practice.

Operational Depth — it reaches task level and lives in the systems

The design decomposes to the task. Process catalogs reach activities and tasks, role definitions are written at the work level, and automation rules and exception protocols are specified up front. This is not more documentation. It is encoded structure the organization runs against, rather than a slide it refers to.

Reaching deep is only half of it. The strategic layer and the operational layer also have to talk to each other — through tooling, not through hand-translation by line managers. Process mining gives an evidence-based view of how work actually flows. Workflow platforms hold the operational layer in the systems people use every day, not in documents filed after the engagement.

Depth is also what keeps the four dimensions coherent. Design them in silos and they drift apart — a decision in WHO that ignores what HOW makes possible is a decision that will reverse itself. When the model is encoded to task level, that contradiction surfaces as a broken handoff in the system, where someone has to fix it, rather than as a slide nobody reread. The same depth that reaches the work is what holds the dimensions together.

A target operating model is necessary but not sufficient. The model defines how work should flow; execution platforms define how it actually does. A category of platform is now emerging that turns the design into an operational asset by encoding taxonomies of activities, role mappings, and process catalogs the organization runs against rather than refers to. BizBlocz is one example, built on a structured catalog of business processes that connects operating-model decisions to executable work. Whether you use a platform like that or hold the equivalent in your own systems, the principle is the same: the operating model has to live somewhere the organization actually operates from.

Continuous Adaptation — it runs on a cadence and corrects itself

The model is reviewed on a defined cadence with real adjustment — quarterly, after each strategic move, or when a real exception fires. It is not signed off once and parked. Most of the value comes from the second and third turns of the loop, not the first design. The continuous-improvement loop is the discipline the binder-era TOM never had: run the model, watch where the friction is, adjust, re-run.

Set the cadence to the tempo of the business, not the planning calendar. Real-time embedded governance is right for fast-moving digital operations. Quarterly with an annual reset is fine for stable regulated operations. Both are wrong for an operation that has not honestly assessed which one it is. Annual reviews are not a cadence — they are an artifact of the budget calendar.

What turns a cadence into a discipline is the trigger. A calendar review asks "has anything changed?" on a fixed date and usually answers no. An event-driven model names its triggers up front: a strategic move (an acquisition, a market entry, a regulatory shift), a threshold breach (a cycle time or exception rate crossing a defined bound), a drift signal from the instrumentation (process mining showing the actual flow diverging from the designed one), or a new execution capability (a platform or agent that changes what HOW makes possible). Each trigger has a named owner and a defined response. The test of whether the loop is real is blunt: did the last two or three reviews actually change the model? A review that never produces a change is theater — scheduled, attended, and inert.

Execution Accountability — it is owned end to end, at every tier

Named roles, with budget and authority, hold the model after the design is delivered. This is the attribute the four-tier ownership model makes concrete — and the one most engagements get wrong. A CEO does not decompose tasks. A line supervisor does not set business-unit boundaries. Ownership confusion is one of the main reasons even sound TOM work fails to produce action, because the design says nothing about who holds which part of it.

Elliott Jaques' Stratified Systems Theory has organized managerial work into discrete levels since the 1950s, based on time-span of discretion. Jaques is rarely cited in TOM engagements, and the cost of ignoring him is exactly the ownership confusion most of them run into. The practical decomposition is four tiers.

Tier 1 — Strategic intent (CEO, board, executive committee). Markets served, business-unit boundaries, geographic footprint, make-versus-buy posture, capital-allocation logic. Time horizon 3 to 7 years. On the corporate calendar this shows up as strategy refresh, portfolio review, M&A integration thesis, or capital-allocation review.

Tier 2 — Architectural design (COO, CTO, CFO, CHRO, function leadership). Decision rights across functions, governance rhythm, performance-metric architecture, major technology choices. Time horizon 1 to 3 years. This is where the four dimensions are decided, and the tier most often actually labeled target operating model. Other labels: organization design, governance redesign, spans-and-layers review.

Tier 3 — Functional design (function heads, VPs, GBS leadership). Capability decomposition, end-to-end process design, vendor and partner integration, role definitions at the team level. Time horizon 6 to 18 months. Most of the model's specificity actually lives here, even though this tier is rarely branded "TOM." Labels: GBS implementation, finance transformation, HR transformation, shared-services design, capability build.

Tier 4 — Operational execution (line managers, supervisors, AI-orchestration roles). Task decomposition, daily workflows, automation triggers, exception handling, human-agent handoffs. Time horizon weeks to months. The tier most TOM frameworks do not address at all. Labeled by method: process automation, RPA deployment, agile transformation, Lean Six Sigma, AI agent deployment.

Tiers 3 and 4 are where the model meets the people who actually run the work — the GBS leader, the process owner, the line supervisor, the orchestration role managing a queue of agents. They are also the tiers most engagements never talk to. A design owned only at Tiers 1 and 2 is a design that stops at the altitude where the slides are pretty and never reaches the floor where the work happens.

The provider landscape mirrors the tier structure, which is part of why the gap is so persistent.

Strategy houses do excellent work at Tiers 1 and 2 and rarely follow it through to Tier 4. Process specialists do strong work at Tiers 3 and 4 but are not typically in the room when Tier 1 decisions are made. The cases where all four tiers are owned coherently are the cases where the work is brought inside.

The companies that span the full stack put a permanent capability inside the organization whose specific job is the operating model itself. ING Bank reorganized in 2015 into roughly 350 squads inside 13 tribes, with permanent tribe leads and chapter leads whose role is to evolve the model as the business changes, not to deliver it once and move on. Spotify built the same idea earlier, with Chapter Lead and Tribe Lead roles now borrowed by hundreds of large enterprises. Hyatt operates a permanent product-operating-model team with named ownership at the property level. Netflix treats its operating model as part of its talent system rather than its planning system, which is why the model is unusually coherent for a company at its scale. The roles that do this work — Chief Transformation Officer, Operating Model Office, product-operating-model leads — are now visible across the Fortune 500 where they did not exist a decade ago. Many are built with external operating-model advisory anchoring the design and an internal team running it ongoing.

The implication for any executive sponsoring a TOM engagement is direct: before approving the design, ask who owns Tier 3 and Tier 4 once the engagement ends, with the same specificity you would expect for Tiers 1 and 2. If the answer is named, with budget and authority, the engagement has a chance. If the answer is "the line organization will pick that up," the binder is already half-shelved.

The multi-sourced workforce: what a modern TOM is really designing for

The single change that broke the traditional operating model — the one Part 2 traced — is that work is no longer executed only by people. The modern workforce is multi-sourced (or hybrid): full-time employees, BPO and outsourcing partners, contractors and consultants, fractional and gig workers, deterministic automation and RPA, and now judgment-bearing AI agents. The traditional TOM was built for one kind of executor — the employee — and treated everything else as a downstream sourcing decision. A modern TOM designs the mix as a first-order question: which executor does which work, where the boundaries sit, and how the handoffs run.

This is the thing a practitioner most has to get right, and it is why the three attributes matter more now than they ever have. It is not a fourth attribute — it is not a separate quality of the design but the design challenge the three attributes exist to meet, and it raises the stakes on each:

• It demands more Operational Depth. You cannot allocate work across the mix from an executive sketch. The boundary is drawn task by task — this activity stays human, this one goes to the BPO partner, this one to an RPA bot, this one to an agent with a human in the loop, this one runs autonomously. That allocation only exists if the model reaches the task.
• It demands more Continuous Adaptation. The mix does not hold still. Agents get more capable month over month, BPO scopes come up for renegotiation, bots break or get superseded, and work that was human last quarter is automatable this one. The allocation has to be re-cut on a cadence, not set once.
• It demands more Execution Accountability. Each source needs an owner — the agent fleet, the BPO relationship, the orchestration that routes work across all of them. Tier 4 now includes orchestration roles managing capacity across humans and agents, not only supervisors managing staff.

Get this wrong and the model fails at exactly the point it was meant to help. Deloitte's State of AI in the Enterprise 2026 puts a number on the most visible slice: 84 percent of companies have not redesigned jobs to fit AI, and the rest are layering agent capacity onto roles designed for the work the agents were brought in to replace. But agents are only the newest entrant — the same failure happens when BPO scopes, contractor pools, and automation are bolted onto a model that still assumes employees do the work. The deepest version of the challenge — designing the operating model around AI agents as active participants — is Part 5 of this series.

Where this goes wrong, even now

Three patterns appear regularly on programs where the design itself was sound. Each is the failure of one attribute.

The model is treated as static even when the language is continuous (fails Continuous Adaptation). The leadership team agrees the model will be reviewed quarterly. The first review slips for an earnings cycle. By the third skipped review, the model is back to a binder.

Ownership stops at Tier 2 (fails Execution Accountability). The design is approved by the executive team, but nobody is named to own Tier 3 and Tier 4. It is signed off at the top and never reaches the floor, where the work actually changes. Governance designed for compliance rather than speed makes it worse — three layers of committee approval for any change build a clutch that will not engage.

The design never reaches the floor (fails Operational Depth). The model is sharp at the capability-map level and silent at the task level. The people who run the work cannot act on it without inventing the operational layer themselves — so they keep doing what they did before, and nothing changes below the executive deck.

Three questions for sponsors

Three questions in the first conversation will tell you whether you are buying a deck or building a discipline. Each maps to one attribute.

Who owns the operating model after the consultants leave? Named, with a job description, budget, and a governance role — at Tier 3 and Tier 4, not just Tiers 1 and 2. If "we will work that out," the project will produce slides. (Execution Accountability.)

How will the model adjust when the assumptions change? A documented review cadence, with an owner and a named trigger for unscheduled reviews. If "we will re-engage if needed," you are designing a binder. (Continuous Adaptation.)

Does the design reach the task level — including the human/agent line, drawn task by task — and what is the working assumption for how much of the work is agents in 36 months? A number with a rationale, even if the number is wrong. If "we will cross that bridge later," you are designing the operating model your competitors will have moved past. (Operational Depth.)

Does it close the gap?

So does modern target operating model design actually close the strategy-execution gap?

Three things are true at once. The discipline has improved — a tripled success rate is real. The gap itself is widening faster than at any point in the discipline's history, with AI as the engine. And modern TOM, done well, narrows the gap on a specific function without closing it across the enterprise.

The highly successful cases in McKinsey's data are the ones where all three attributes were delivered together. The partial cases had some and not others, and the failure modes are predictable. A model that reaches task level but is not owned never gets out of the binder. A model that is owned but stays shallow puts strong leaders in charge of an empty design. A model that corrects itself but never reaches the floor produces motion without action. The attributes are a set, not a menu.

We have spent more than three decades on the practitioner side of operating-model design, and the pattern across every successful redesign we have been close to is the same. The model was not a thing the leadership team commissioned and approved. It was a thing they used. The right test for whether your operating model is working is not whether it was approved at the steering committee. It is whether your VPs make decisions inside it without being reminded that it exists.

If they do not, what you have is a target operating model document. Not a target operating model.

For the full landscape of operating-model labels — Product, Agile, Agentic, and the rest — see the operating-model-types glossary. For what a modern TOM produces across all four dimensions, the series hub is the place to start.