Strategic Operating Model: How Structure, Governance, Processes, Technology & Talent Turn Strategy into Results

Strategic operating model is the system through which strategy becomes repeatable organisational behaviour: the combination of structure, governance, decision rights, value streams, processes, technology, data, talent, incentives, performance management and operating cadence that determines how important work is actually done. A strategy can choose where to compete, what value to create and which capabilities matter, yet still fail if the operating model sends decisions to the wrong level, separates people who must collaborate, rewards the wrong behaviour, slows information, duplicates work or places technology on top of a broken process.

A strong operating model connects strategic priorities to everyday execution. It decides which work belongs in business units, which capabilities should be shared, who owns an end-to-end outcome, which decisions are centralised or decentralised, how cross-functional processes flow, how governance forums work, how data and digital platforms support decisions, how human and AI roles fit together, how talent is deployed, how performance is measured and how the organisation learns when the model no longer fits. In this sense, operating-model design sits between abstract strategy and detailed organisation design: it is the blueprint for how the enterprise will behave.

This guide develops a first-principles theory of strategic operating models, operating model design, organisational structure, governance, decision rights, value streams, cross-functional processes, shared services, product and platform models, technology and data architecture, AI operating models, talent systems, incentives, performance management, management cadence, accountability and strategy execution. It explains why boxes-and-lines reorganisations often disappoint, how to translate strategy into design principles, how to build the model around value creation rather than departmental history, how to redesign human–AI workflows, how to diagnose operating-model debt and how to test whether a redesign is actually improving the system.

This article owns a distinct job inside the eduKateSingapore Strategy library. Strategic Positioning owns where to play and what to refuse. Strategic Capabilities owns what the system must be able to do repeatedly. Strategic Resource Allocation owns where scarce resources move. Strategic Coherence owns whether the parts reinforce one another. Strategic Execution owns coordinated action and accountability. Strategic Operating Model owns the architecture that makes those choices repeatable.

The Short Answer

A strategic operating model is the deliberately designed system of structure, accountability, decision rights, governance, processes, information, technology, talent, incentives and management routines through which an organisation repeatedly executes its strategy.

The operating model is not the strategy itself. It is not the organisation chart. It is not one workflow, one software platform or one meeting cadence. It is the integrated design that determines where work sits, who decides, how information travels, how shared capabilities are used, which interfaces matter, what behaviour is rewarded and how the system corrects itself.

That distinction matters because many organisations change visible structure without changing the mechanics underneath. They rename functions, redraw reporting lines, create new titles and announce transformation, yet the same approval bottlenecks, incentives, data fragmentation and cross-functional friction remain. The chart changed. The operating model did not.

Evidence and Scope Boundary

This guide explains operating-model mechanisms that appear across contemporary strategy and organisation research. McKinsey’s current operating-model work describes a modern design system that extends well beyond structure into purpose, value agenda, ecosystem, leadership, governance, processes, technology, behaviours, rewards, footprint and talent. Strategy& similarly treats operating-model transformation as the connection between strategy, people, governance and technology, while Bain’s operating-model work emphasises structure, accountability, governance, behaviours, processes, information and technology as a linked blueprint. Recent BCG work on AI-enabled transformation adds explicit attention to human–AI roles, reporting cadence and escalation pathways. These sources provide reference points; the frameworks and examples below are original teaching constructions.

1. Why Strategy Needs an Operating Model

Strategy makes choices about direction. An operating model makes those choices executable.

Imagine a company decides to compete through premium specialist service. That strategy implies something about customers, capabilities and economics. But the strategy is incomplete as an operating system until the company decides how specialist knowledge is developed, where customer decisions sit, how cases move across functions, how exceptions are handled, which technologies support expert work, how incentives protect quality and how much authority the frontline has.

A different company chooses scale and low cost. Its operating model may need more standardisation, central procurement, automated workflow, tighter process control, high asset utilisation and fewer exceptions. If it copied the specialist firm’s operating model, it would import the wrong behaviour.

The operating model therefore answers a practical question:

Given this strategy, what must the organisation repeatedly do, and how must work be arranged so those behaviours are normal rather than heroic?

The phrase rather than heroic matters. A strategy that depends on exceptional people constantly bypassing the formal system does not yet possess a robust operating model. Heroic effort can keep an organisation alive, but it also hides broken interfaces, unclear ownership and underbuilt capability.

Operating-model design converts strategy into a set of organisational design problems:

Which outcomes need end-to-end ownership?
Which capabilities should be shared across the enterprise?
Which decisions should be central, local or jointly governed?
Which workflows should be standardised and which should vary?
Where should technology automate, augment or merely inform?
What information must be common?
Which incentives make the intended behaviour rational?
Which governance forums are genuinely necessary?
How quickly should the system detect drift?

When these questions remain unanswered, strategy leaks into improvisation. Each function interprets priorities locally. Decisions accumulate at the top. Technology teams build systems around different assumptions. Performance measures pull in different directions. The organisation becomes active without becoming coordinated.

2. Operating Model vs Organisation Structure

Organisation structure is one component of an operating model. It describes formal units, reporting relationships and often the distribution of accountability. The operating model is broader.

Two companies can have almost identical organisation charts and operate very differently.

One may give country leaders genuine pricing authority. Another may require central approval. One may run product development through autonomous cross-functional teams. Another may distribute product decisions across functions. One may share customer data across the enterprise. Another may keep it fragmented by business unit.

The chart cannot show all of this.

Organisation Structure	Operating Model
Formal units and reporting lines	How the whole organisation repeatedly creates value
Who reports to whom	Who decides what, with which information and authority
Functions, divisions, regions, teams	Value streams, capabilities, processes, governance and interfaces
Relatively visible	Partly formal and partly behavioural
Can be redrawn quickly	Changes only when work, incentives and decisions actually change

This explains why reorganisations often disappoint. Leaders change reporting lines because structure is visible and administratively controllable. But the organisation’s deeper behaviour may be driven by budgets, incentives, approval rights, technology architecture and habits that remain untouched.

A useful diagnostic is to ask what would be different on Monday morning if the structure changed. If people still wait for the same approvals, enter data into the same systems, attend the same meetings, optimise the same metrics and protect the same local budgets, the practical operating model may have barely moved.

3. Start With Strategic Design Principles

An operating model should be derived from strategy through explicit design principles.

Bain’s operating-model work makes this connection clearly: structure should follow strategy, and leaders should translate strategic intent into a small set of design principles before making detailed organisation choices. The value of a design principle is that it converts an abstract ambition into a criterion that can guide competing design decisions.

Consider a company whose strategy depends on local market adaptation within a trusted global brand.

Useful principles might include:

global standards protect brand, safety and shared data,
local units control customer-facing adaptation within those standards,
scarce specialist capabilities are shared rather than duplicated,
customer decisions should sit as close as possible to current market information,
cross-market learning should travel through common platforms and review routines.

These principles are more useful than saying “be agile” or “empower teams”. They establish what should be central and what should be local.

A design principle should pass four tests:

Strategic: it follows from a real strategic choice.
Discriminating: it helps choose between plausible designs.
Operational: it changes where work, authority or resources sit.
Bounded: it states enough limits to prevent every interpretation from claiming compliance.

“Customer-centric” fails these tests unless it changes a decision. “Customer-segment teams own end-to-end onboarding outcomes, while risk thresholds remain centrally governed” is more useful because it specifies ownership and boundary.

Design principles create coherence before detail. They also reduce politics because debates can refer back to agreed strategic logic rather than to which executive prefers which structure.

4. Build Around Value Creation, Not Departmental History

Organisations inherit functions, committees, systems and boundaries from earlier strategies. Over time, those arrangements can become invisible assumptions.

Operating-model redesign begins by asking how value is created now and how it should be created under the chosen strategy.

This means mapping end-to-end value streams.

A value stream is the chain of activities and decisions that produces an outcome for a customer, learner, citizen or internal user. Examples include:

lead to customer onboarding,
idea to product launch,
order to fulfilment,
incident to resolution,
diagnosis to intervention,
policy concept to implemented public service.

Functions remain important because expertise must be developed somewhere. But value flows across functions.

A customer does not experience finance, operations and technology as separate departments. The customer experiences one journey. A student does not experience curriculum, assessment and tutoring as separate internal systems. The student experiences whether learning works.

High-performing operating models therefore need both functional depth and end-to-end accountability.

Too much functional power can create silos. Too much process ownership can weaken specialist standards. The design problem is to make the two reinforce rather than compete.

One useful arrangement gives functions responsibility for capability, standards and talent development while value-stream leaders own end-to-end outcomes.

The resulting matrix can work only if decision rights are explicit. Otherwise every cross-functional issue becomes negotiation.

This is why operating-model design quickly moves from value streams to decisions.

5. Decision Rights Are the Skeleton of the Operating Model

Decision rights determine who has authority to make which decisions, who must be consulted, who supplies information, who can challenge and who owns the consequence.

They are one of the most powerful parts of an operating model because decisions occur repeatedly.

A slow or ambiguous decision right creates recurring friction. A clear decision right can remove that friction across hundreds of cases.

Consider pricing. If every local discount requires central approval, consistency may be protected but responsiveness may collapse. If every salesperson can set any price, speed improves but margin and positioning may erode.

The useful design is often neither total centralisation nor total decentralisation. It is a bounded decision architecture.

For example:

central leadership sets strategic pricing principles and risk thresholds,
business units choose within defined bands,
exceptions outside the band escalate,
data from local decisions feeds periodic threshold review.

This pattern combines coherence, speed and learning.

Decision-right design should examine five questions:

Where is the most relevant information?
How reversible is the decision?
How much system-wide coordination does it require?
What is the consequence of a poor local decision?
How quickly must the decision be made?

Decisions based on fast-changing local information often benefit from decentralisation. Decisions involving shared standards, scarce capital, systemic risk or irreversible commitments often need stronger central coordination.

BCG’s 2026 work on AI-powered transformation offices makes the same logic visible in a new context: leaders should explicitly define team structure, governance, decision rights and the division between human-led and AI-augmented roles rather than adding agentic capability without redesigning authority.

The principle is broader than AI. Operating models work when authority follows the economics and information of the decision.

6. Centralisation vs Decentralisation Is a Design Problem, Not an Ideology

Operating-model debates often become arguments about whether power should sit at the centre or at the edge. That framing is too crude.

Some decisions benefit from centralisation because they involve shared standards, scarce resources, systemic risk or enterprise-wide coordination. Others benefit from decentralisation because they depend on local information, speed and adaptation.

The strategic question is not “Which model is better?” It is “Which decision belongs where, given the strategy?”

Centralisation can create:

economies of scale,
consistent standards,
shared investment,
stronger control of systemic risk,
better reuse of scarce expertise,
enterprise-wide data coherence.

It can also create:

slow decisions,
distance from local reality,
overloaded headquarters,
uniform solutions where context differs,
loss of accountability at the edge.

Decentralisation can create speed, entrepreneurship and better use of local information. It can also create duplication, inconsistent customer experience, incompatible technology, fragmented data and competition between units.

A mature operating model therefore distinguishes decision domains rather than choosing one doctrine for the entire organisation.

Decision Type	Often Benefits From	Why
Enterprise risk threshold	More central control	Consequences cross unit boundaries
Local customer response	More local authority	Information is immediate and contextual
Shared technology standards	Common governance	Interoperability and security matter enterprise-wide
Daily staffing adjustments	Local decision	Conditions change quickly
Large capital commitment	Central coordination	Scarce capital and portfolio consequences
Product experiment within guardrails	Decentralised execution	Learning speed matters

This logic can produce hybrid models. Global standards coexist with local execution. Shared platforms coexist with independent product teams. Central investment governance coexists with local experimentation budgets.

Hybrid models fail when boundaries are ambiguous. Local teams believe they have authority until headquarters overrides them. Central functions believe they own a decision while business units believe the opposite. Meetings multiply because no one knows whose answer is final.

The repair is not more consultation. It is explicit authority.

One useful operating principle is to centralise what must remain coherent and decentralise what benefits from proximity to information.

Another is to move exceptions rather than routine decisions upward. If ninety percent of cases can be handled safely inside a standard, the operating model can reserve senior attention for the difficult ten percent.

This is strategically powerful because senior attention is itself scarce.

7. Governance Is the Decision System, Not the Meeting Calendar

Governance is often confused with committees. Committees are only one possible mechanism.

Governance is the system through which authority is exercised, decisions are challenged, risks are escalated, commitments are reviewed and accountability is enforced.

A governance system should answer:

Which decisions require collective judgement?
Which decisions belong to one accountable owner?
Which evidence must be available?
Who can challenge?
What triggers escalation?
How are unresolved conflicts closed?
When is a decision revisited?

Weak governance tends to fail in two directions.

The first is under-governance: unclear authority, inconsistent risk decisions, duplicated investment and weak accountability.

The second is over-governance: too many forums, too many approvals and too much escalation for routine work.

Both can slow execution.

A good governance model distinguishes recurring decision types. Some deserve a standing forum. Some deserve one owner. Some deserve a temporary review because the issue is novel. Some should never leave the operational team unless a threshold is crossed.

This makes escalation pathways important.

An escalation should not mean “someone senior is uncomfortable”. It should be triggered by conditions such as:

risk above an agreed threshold,
capital beyond delegated authority,
cross-unit conflict that cannot be resolved locally,
breach of a protected standard,
evidence that the strategy assumption has changed,
an irreversible decision outside the approved plan.

These triggers protect senior attention from becoming a default queue.

Governance should also be asymmetric. A routine reversible decision should not require the same process as a high-consequence irreversible one.

This is especially important in AI-enabled organisations. If every AI-assisted action requires senior approval, the technology’s speed advantage disappears. If consequential automated decisions receive no governance, risk can scale quickly. The operating model should classify decisions according to consequence, reversibility and evidence quality.

Governance therefore acts as a routing system for judgement.

8. Management Cadence Turns Governance Into a Living System

An operating model needs rhythm.

Management cadence is the pattern of reviews, planning cycles, operating meetings, performance conversations, resource decisions and strategic resets through which the organisation notices change and responds.

A cadence can be too slow. Problems persist because evidence reaches decision-makers after the opportunity to respond.

It can also be too fast. Teams spend so much time reporting and adjusting that they cannot execute long enough to learn anything.

A useful cadence separates different clocks.

Operational clock: immediate flow, incidents, exceptions and service continuity.
Performance clock: recurring review of outcomes, capacity, quality and bottlenecks.
Resource clock: deliberate reallocation of money, talent and attention.
Strategic clock: review of positioning, capabilities and major assumptions.

The clocks should interact without collapsing into one meeting.

If every operational issue is treated as a strategic issue, leadership becomes reactive. If strategic assumptions are never revisited because weekly operations dominate, the organisation can execute yesterday’s strategy very efficiently.

A strong cadence therefore creates a path from signal to decision.

For example, a recurring rise in customer complaints may first appear in an operational review. If the issue persists, it enters a performance review. If evidence shows a structural capability gap, it enters resource allocation. If it reveals that the customer promise itself is wrong, it reaches strategic review.

The point is not hierarchy for its own sake. It is to match the decision level to the nature of the problem.

Cadence also determines how quickly learning travels. A team can discover something valuable locally, but without a route into the wider system the lesson remains local.

This is why operating-model design should include not only decision forums but knowledge flow between forums.

9. Accountability Means Ownership of Outcomes, Not Possession of Activities

Many organisations assign responsibility for tasks without assigning accountability for outcomes.

One team owns marketing. Another owns sales. Another owns onboarding. Another owns service. Everyone can report strong activity while customer retention declines.

Operating models need end-to-end accountability.

An accountable owner should be able to:

see the full outcome,
access the information needed to diagnose it,
influence the major contributors,
escalate cross-boundary constraints,
recommend resource movement,
be evaluated on the result rather than one internal activity.

This does not imply one person has unilateral power over every function. It means someone is responsible for integrating the system around the outcome.

Accountability without authority creates frustration. Authority without accountability creates risk.

The two should be paired.

A common failure is to appoint an owner but leave budgets, people and decisions elsewhere. The owner becomes a coordinator who can request but not change.

Another failure is to give authority but keep performance measures functional. A product leader is told to own customer value but engineering, marketing and operations are each rewarded on separate metrics that conflict with the product outcome.

Real accountability requires coherence between ownership, decision rights, incentives and information.

10. End-to-End Processes Reveal Where the Operating Model Is Actually Broken

Processes show the operating model in motion.

An organisation can have a sensible structure and still fail because work crosses boundaries badly.

Common symptoms include:

the same information entered several times,
work waiting between functions,
unclear acceptance criteria,
repeated escalation,
large exception queues,
manual reconciliation between systems,
metrics that optimise one stage while harming another.

These are not merely process problems. They are clues about ownership, decision rights, technology and incentives.

Suppose onboarding takes twenty days. Mapping the process reveals that actual work consumes four days. The remaining sixteen are queues, approvals and waiting for information.

The high-leverage intervention may not be “work faster”. It may be changing which information is required upfront, which approvals are truly necessary, and who can decide exceptions.

This is why McKinsey’s recent process work emphasises rethinking the way work gets done rather than simply digitising an existing sequence.

A process redesign should ask:

What outcome does the process exist to create?
Which steps genuinely change that outcome?
Where does work wait?
Which information is repeatedly missing?
Which approvals exist because of real risk?
Which decisions can move closer to the work?
Which exceptions should be separated from the routine path?

Separating routine work from exceptions is especially powerful. Routine cases can move through a simpler pathway. Difficult cases receive the attention they need without forcing every case through the same heavy control.

That pattern becomes increasingly important when automation is introduced.

11. Interfaces Matter More Than Internal Perfection

Many operating-model failures occur at interfaces rather than inside teams.

One function completes its work correctly, but the next function cannot use the output. One system contains accurate data, but another system interprets the field differently. One team delivers on time, but the receiving team receives no context about risk or assumptions.

An interface is the agreement between two parts of the system about what passes across the boundary.

A strong interface specifies:

what information or work product is transferred,
the quality standard,
timing,
ownership,
exception handling,
correction when the handoff fails.

This can sound technical. It is also deeply organisational.

Sales and operations need an interface around promises. Product and engineering need an interface around requirements. Finance and business units need an interface around investment. Teachers and parents need an interface around evidence and next action.

A good interface reduces the need for repeated negotiation without pretending that every case is identical.

Interfaces are high leverage because the same boundary is crossed repeatedly. One improvement can reduce friction hundreds of times.

They are also fragile. A poor common standard can scale misunderstanding.

Therefore interfaces need versioning and feedback. When new cases repeatedly break the standard, the standard should change.

12. The Role of the Centre Must Be Designed, Not Assumed

Every multi-unit organisation faces a question: what should the centre do?

The centre can allocate capital, set standards, provide shared services, build capabilities, manage risk, coordinate strategy, own platforms, develop talent or directly control operations.

Trying to do all of these equally can create a headquarters that is expensive, slow and unclear.

The role of the centre should follow the strategy and the economics of sharing.

A diversified group with unrelated businesses may need a lighter centre focused on capital allocation, governance and a few enterprise capabilities.

A tightly integrated platform business may need a stronger centre owning technology, data, brand and risk standards because these assets create value across units.

A useful centre should create more value through coordination and shared capability than the cost and friction it introduces.

This creates a test for every central activity:

Would the business units be worse off if this capability were entirely local, and is the central version actually better enough to justify common control?

If the answer is weak, the activity may not belong at the centre.

Shared services deserve the same test. Centralising payroll, procurement or technology can reduce duplication. It can also create a slow internal monopoly if service quality is poor and users have no recourse.

A well-designed shared service needs clear service levels, transparent demand, customer feedback and a route for continuous improvement.

The centre should not become a place where accountability disappears.

13. Product and Platform Operating Models Change the Unit of Organisation

Traditional organisations often organise technology work around projects: define scope, fund the project, deliver the system, hand it over, move on.

Product and platform operating models change the unit of organisation from temporary delivery to enduring responsibility.

A product team owns an outcome or user need over time. A platform team owns a reusable capability used by several products.

This can improve speed and accountability because the same cross-functional team discovers, builds, operates and learns.

McKinsey’s 2026 technology agenda reports that top-performing companies are increasingly adopting product and platform models that align technology delivery with strategy and make cross-functional decisions faster. The mechanism is not the label “product”. It is the concentration of skills and authority around an enduring outcome.

A product operating model usually requires:

a persistent product mission,
cross-functional capability,
an accountable product leader,
access to users and performance data,
funding that survives beyond one project milestone,
technical ownership through operation and improvement.

The model can fail if teams are renamed as products but remain dependent on annual project approval, fragmented functional incentives and external decision rights.

Platform models create a different design challenge.

A platform should provide reusable services that reduce the cost of many products. Identity, payments, data access, observability, developer tooling or common AI evaluation can operate this way.

Platforms create leverage only if teams actually reuse them.

A platform that forces every product into awkward constraints can become centralised technical debt. A platform that offers no advantage over local solutions becomes optional infrastructure nobody adopts.

Good platform governance therefore treats internal product teams as users. Adoption, reliability, developer effort, speed and exception demand are evidence about whether the platform is creating value.

Product and platform models should not be copied into every function. Some work remains transactional, specialist or episodic. The strategic job is to identify where enduring cross-functional ownership improves the value stream.

14. Data Architecture Is Part of the Operating Model Because It Shapes Decision Quality

Data is not a separate technical layer that can be repaired after organisation design.

Data determines what the organisation can see, compare and decide.

If each business unit defines customer, product, revenue, risk or performance differently, enterprise decision-making becomes reconciliation.

This creates an operating-model problem because local autonomy has produced incompatible information.

Some information should therefore be governed as enterprise infrastructure.

Common elements can include:

core definitions,
data ownership,
access rules,
quality standards,
lineage and provenance,
retention,
correction processes.

This does not imply one central database for every purpose. It means the operating model knows which information must remain coherent enough for shared decisions.

Data ownership should also be linked to work. A central data team cannot always determine whether a customer record is meaningful. The team closest to the process may understand the context. The operating model needs shared standards and local stewardship.

This is another hybrid design.

AI increases the importance of the issue because models can amplify information inconsistencies. If different units label the same concept differently, automated systems may reproduce the fragmentation at machine speed.

Data architecture therefore becomes strategic when decision systems, AI agents and automation depend on common information.

A useful data-operating-model test asks:

Which enterprise decisions require comparable data?
Who is accountable for the meaning of each critical field?
Who can correct errors?
How quickly does correction propagate?
Which local variation is legitimate?

These are organisational questions disguised as technical questions.

15. Technology Architecture Encodes the Operating Model

Technology does not merely support an operating model. Over time, technology can hard-code it.

A workflow system determines who can approve. A CRM determines which customer information travels. An ERP shapes how resources are recorded. An identity system determines who can access which capability. An API determines which teams can interact without manual coordination.

This means technology architecture should follow operating-model choices rather than quietly make them by default.

Legacy technology can preserve an obsolete operating model. A company decentralises pricing authority, but the system still requires central approval. A school wants teacher-level intervention, but assessment data arrives only at term end. A public service wants one citizen journey, but every agency uses separate identity and case systems.

The formal policy changes. The technical operating model remains.

Technology architecture should therefore be evaluated against the intended work design:

Does information travel to the right decision point?
Can local teams act within approved boundaries?
Are common capabilities reusable?
Can exceptions be identified and routed?
Can the system be changed without rebuilding everything?
Can important actions be audited?

Modularity becomes valuable because operating models change. A tightly coupled system makes every organisational change expensive. A more modular architecture can preserve stable interfaces while allowing teams and workflows to evolve.

This is not an argument for maximum technical modularity. Excessive fragmentation can increase integration cost. The architecture should match the organisational need for both coherence and change.

Technology governance belongs inside the operating model because architecture decisions create future constraints.

16. Human–AI Work Design Requires a New Division of Labour

Artificial intelligence changes operating models because it changes which tasks are scarce.

Drafting, coding, classification, search and analysis may become much cheaper. Verification, judgement, source quality, exception handling and accountability may become relatively more important.

BCG’s 2026 work on AI-powered transformation offices explicitly recommends defining which roles remain human-led and which are augmented by AI, alongside governance, decision rights, reporting cadence and escalation paths. Its separate 2026 work on AI productivity makes the same broader point: productivity gains become real value only when work, roles and structure are redesigned.

This suggests a practical operating-model sequence.

Map the current workflow.
Identify the decision, not only the task.
Separate routine transformation from consequential judgement.
Decide where AI can prepare, recommend, execute or monitor.
Define human ownership of exceptions and outcomes.
Redesign controls around the new failure modes.
Remove obsolete steps instead of automating them.

The distinction between preparation and decision is especially important.

An AI system can prepare options, summarise evidence or identify anomalies without owning the final decision. In some low-risk contexts it may execute inside predefined boundaries. In high-consequence contexts human approval or independent verification may remain necessary.

The operating model should state this explicitly.

Otherwise organisations create ambiguous accountability: humans assume the system decided; system designers assume humans reviewed; nobody owns the consequence.

AI can also change span of control. If managers receive better information and routine coordination is automated, one manager may support a larger system. But if AI generates more exceptions, outputs or decisions requiring review, managerial load can rise rather than fall.

Capacity created by AI is not automatically value.

The operating model must decide what the released capacity will do instead.

That may mean more customer interaction, deeper analysis, faster product iteration, lower cost or fewer errors. Without a deliberate destination, productivity can disappear into additional complexity.

17. Talent Architecture Determines Whether the Model Has the Skills It Assumes

An operating model is only credible if the required talent exists or can be built.

Designs often fail because they assume capabilities that the organisation does not possess.

A decentralised model assumes local leaders can make broader decisions. A product model assumes cross-functional product judgement. An AI-enabled model assumes people can evaluate machine-generated output and redesign workflows. A platform model assumes engineering depth and internal product management.

These are talent assumptions.

A strategic operating model should therefore include:

critical roles,
required skills,
leadership behaviours,
career paths,
mobility across units,
build-buy-partner choices,
succession for scarce roles.

Talent architecture is broader than headcount.

An organisation can have enough people and still lack the few capabilities its operating model needs most.

This is why strategic workforce planning should distinguish roles by leverage, scarcity and learning time.

A role can be important but easy to source. Another can be small in number but impossible to replace quickly.

The second role deserves stronger succession and retention design.

Talent should also move with strategy. If the organisation changes the source of value but leaves its strongest people concentrated in yesterday’s businesses, the formal strategy and actual capability diverge.

Resource allocation therefore includes talent allocation.

A mature operating model can move high-quality people toward strategic bottlenecks without permanently weakening the functions that develop them.

18. Incentives Tell People Which Operating Model Is Real

Incentives are one of the fastest ways to discover the real operating model.

If collaboration is praised but promotions reward local financial performance only, local optimisation is rational.

If product teams own customer outcomes but functional leaders control careers, people may remain more loyal to functions than products.

If experimentation is encouraged but failure damages performance ratings, teams will avoid real experiments.

Incentives include more than money.

promotion,
status,
access to leaders,
resource control,
recognition,
job security,
what receives praise or punishment in meetings.

These informal incentives can overpower formal design.

Operating-model design should therefore trace the incentives attached to each critical behaviour.

If the strategy needs enterprise collaboration, some measures should reflect enterprise outcomes. If it needs local entrepreneurship, people should have meaningful authority and consequences around local performance. If it needs quality, volume should not be the only rewarded result.

Incentive design also needs boundaries because people adapt aggressively to measurement.

One metric can become the goal and stop being a good measure.

This is why incentive systems should combine outcomes, mechanism quality and protected boundaries rather than optimise one proxy.

19. Performance Management Should Diagnose the System, Not Only Judge People

Performance management often focuses on evaluating individuals. An operating model also needs performance management to understand the system.

A useful performance system asks:

Are strategic outcomes improving?
Are the mechanisms moving as expected?
Where are queues and constraints appearing?
Which interfaces produce rework?
What capacity is being consumed?
What unintended behaviour is appearing?

This is different from a dashboard full of departmental KPIs.

Departmental metrics can be useful, but the operating model needs end-to-end measures.

A fulfilment system might track:

customer promise kept,
end-to-end cycle time,
error and rework,
queue age,
exception rate,
cost per successful outcome.

These measures cross functional boundaries.

Performance management should also distinguish a poor result caused by weak execution from one caused by a flawed model.

If teams follow the designed process and still produce the wrong outcome, the operating model may need redesign. Punishing execution will not repair the architecture.

Conversely, a sound operating model can fail because people ignore it or lack capability.

The review should separate design failure from adoption failure.

20. Culture Is the Informal Operating Model

Formal operating models describe how work is supposed to happen. Culture strongly influences how work actually happens.

Culture is visible in repeated social consequences:

who can challenge a senior person,
whether bad news travels upward,
whether people protect local territory,
whether mistakes are hidden or examined,
whether commitments are treated as real,
whether collaboration produces status or inconvenience.

This makes culture part of the operating model rather than a separate soft topic.

A decentralised structure requires trust and clear boundaries. If the culture punishes local mistakes harshly, decisions will drift back upward.

A learning model requires people to surface uncertainty. If leaders reward certainty and punish dissent, the information system becomes distorted.

A cross-functional model requires shared success. If status comes from controlling resources, functions will defend boundaries.

Culture cannot be changed by slogans alone. It changes when operating mechanisms change repeatedly.

Leaders can alter:

what gets reviewed,
who is invited into decisions,
what behaviour is rewarded,
how failure is handled,
how conflict is resolved,
what leaders personally model.

These practices teach the real rules.

Culture therefore becomes a test of whether the formal operating model is believable.

21. Footprint, Outsourcing and Ecosystem Choices Are Operating-Model Decisions

An organisation does not need to perform every activity itself.

The operating model should decide what is owned, partnered, outsourced, automated or accessed through an ecosystem.

This choice should follow strategic importance and capability economics rather than fashion.

Activities may be good candidates for external provision when they are:

standardised,
available from capable suppliers,
not a major source of differentiation,
easy enough to specify and monitor,
not so sensitive that external dependence creates unacceptable risk.

Activities may deserve stronger internal ownership when they contain:

distinctive know-how,
critical customer relationships,
sensitive data,
high-consequence judgement,
strategic learning,
interfaces that determine future architecture.

Outsourcing can lower cost while weakening learning. Bringing work in-house can increase control while raising fixed cost and management burden.

The operating model should therefore consider not only current efficiency but future capability.

Geographic footprint creates similar trade-offs.

Co-location can accelerate collaboration. Distributed models can access talent and resilience. Regional hubs can balance scale with local proximity.

The correct footprint depends on the work.

A highly interdependent innovation process may benefit from dense interaction. Transactional work may not. Customer-facing decisions may need local presence while shared analytics remain global.

Modern operating models increasingly include partners, platforms and external specialists. Strategy& explicitly frames the operating model alongside ecosystem choices because value can be created through networks rather than inside one legal entity.

This expands governance beyond the firm.

The model must define data access, standards, service levels, risk ownership, escalation and exit rights across organisational boundaries.

A partner relationship without a governance interface can become a permanent source of ambiguity.

22. The Operating Model Should Be Built Around the Capability System the Strategy Requires

A strategy rarely depends on one capability. It depends on a system of capabilities that reinforce one another.

The operating model gives that capability system a home.

Suppose a business competes through rapid specialist problem solving. It may need:

high-quality sensing,
expert diagnosis,
fast access to cross-functional knowledge,
authority to act near the customer,
post-case learning,
technology that surfaces prior solutions.

The operating model should connect these capabilities rather than distribute them as unrelated functional programmes.

This is where Strategy&’s capabilities-driven logic is especially useful: clarify how value will be created, identify the differentiating capabilities required, then design an operating model that consistently enables those capabilities.

The operating model can support capabilities through:

where specialists sit,
how they are funded,
which technology they share,
how knowledge is captured,
which decisions they own,
how junior capability is developed,
how demand is prioritised.

A capability that exists in principle but is inaccessible in the workflow is not fully operational.

For example, a company may employ excellent data scientists but require three months to obtain data access. The talent exists. The operating model prevents the capability from working at strategic speed.

This is why Strategic Capabilities and operating-model design are adjacent but distinct. Capabilities describe what the system can do. The operating model describes how those capabilities are organised, connected and activated.

23. Resource Allocation and the Operating Model Must Agree

An operating model can declare priorities that the budget quietly reverses.

A company says product teams own outcomes, but funding remains annual and project-based. A business says local markets have authority, but headcount and capital require central negotiation. An organisation says shared capabilities matter, but every business unit protects its own budget.

The allocation system is therefore part of the operating model.

Funding models shape behaviour.

Project funding encourages temporary delivery.
Product funding supports enduring ownership.
Central capability funding encourages reuse.
Business-unit funding encourages local accountability.
Innovation pools can preserve experimentation outside ordinary business cases.

No model is universally correct.

The question is whether the funding logic supports the work architecture.

Resource governance should also allow movement. A strategic operating model becomes rigid when every dollar and role is permanently attached to historical units.

This is why dynamic reallocation is important. The system needs a cadence and authority for moving resources when constraints, opportunities or evidence change.

The full allocation machinery belongs to Strategic Resource Allocation. Here the key point is architectural: an operating model cannot empower a unit while denying it every meaningful resource decision.

24. Strategic Coherence Is the Test of the Operating Model

An operating model is coherent when its major elements support the same strategic logic.

Consider a company that competes through rapid customer adaptation.

A coherent operating model might include:

customer-segment teams with local authority,
shared data standards,
modular technology,
fast experiment budgets,
enterprise risk guardrails,
incentives tied partly to retained customer value.

An incoherent model might decentralise teams while preserving central approval for most customer decisions, reward cost reduction above adaptation and run a monolithic technology platform that requires long release cycles.

The organisation would be structurally decentralised and operationally centralised.

This is why operating-model design should be audited across elements, not one element at a time.

Strategic Need	Operating-Model Question
Speed	Are decisions, data and deployment close enough to the work?
Consistency	Which standards and platforms must be common?
Innovation	Can teams experiment without enterprise-wide permission?
Scale	Which capabilities can be reused?
Resilience	Where are single points of failure and recovery responsibilities?
Specialisation	How do scarce experts influence many cases without becoming bottlenecks?

The table does not prescribe a design. It exposes contradictions.

For the full system-fit layer, see Strategic Coherence.

25. Execution Tests the Operating Model Every Day

Operating models are often designed in workshops and tested in operations.

Execution reveals where the model is incomplete.

A decision that seemed clear still escalates. A shared service cannot meet demand. A product team lacks access to one critical specialist. A local unit technically owns a decision but fears violating informal expectations.

These are not necessarily signs the entire model is wrong. They are evidence about where formal design and practical behaviour diverge.

A strong implementation process therefore captures operating-model exceptions.

For each recurring exception, ask:

Was the design unclear?
Was capability missing?
Did technology prevent the intended action?
Did incentives contradict the rule?
Did the situation expose a new legitimate exception?

This turns execution into design feedback.

The mistake is to solve every exception through informal workaround. Workarounds keep the organisation moving but accumulate hidden operating-model debt.

Execution should make repeated workarounds visible enough for redesign.

For coordinated action and accountability, see Strategic Execution.

26. Operating-Model Debt Accumulates When Exceptions Become Architecture

Operating-model debt is the accumulated burden created when temporary workarounds, legacy rules, duplicated capabilities and unresolved design contradictions become permanent.

Examples include:

a special approval added after one failure and never removed,
parallel reporting systems maintained after a merger,
local tools built because the shared platform was too slow,
committees created for old priorities that still meet,
roles that exist mainly to translate between incompatible processes,
spreadsheets that reconcile systems no one has integrated.

Each item may be rational in isolation.

Together they create complexity.

Debt compounds because new initiatives must route around the old complexity. The organisation needs more coordinators, more controls and more data translation.

Symptoms include:

growing approval time,
duplicate teams,
unclear ownership,
large exception volumes,
high meeting load,
many manual interfaces,
slow onboarding of new staff,
difficulty explaining how a decision actually gets made.

Operating-model debt should be managed like technical debt: not all of it needs immediate elimination, but high-cost debt should be visible and prioritised.

A useful debt register records:

the workaround,
the original reason,
current burden,
dependencies,
risk of removal,
owner,
review date.

The point is not bureaucratic documentation. It is to stop temporary complexity from becoming invisible.

27. Leading Indicators That the Operating Model No Longer Fits

Operating models should not be redesigned continuously. Constant reorganisation destroys learning and accountability.

But operating models also should not be treated as permanent.

Strategy&’s strategic operating-model work argues for proactive review because markets, technology, capability and organisational context change.

Useful warning signs include:

decision time rises despite stable complexity,
senior leaders become bottlenecks,
local teams repeatedly build duplicate capabilities,
customers experience fragmented journeys,
technology teams spend most effort integrating internal systems,
resource movement is slower than strategic change,
employees cannot explain who owns an outcome,
important work happens through shadow processes,
new strategy depends on capabilities the current model cannot deploy,
AI or other technology changes the relative cost of tasks materially.

One sign by itself may not justify redesign.

The pattern matters.

A stable organisation can tolerate some friction. A changing strategy can make the same friction critical because the old model now blocks the new value logic.

A major acquisition, new business model, regulatory shift, platform strategy or AI transformation can all justify deeper review.

The review should begin with strategy and system behaviour, not a preselected reorganisation.

28. Redesign the Operating Model in a Deliberate Sequence

Operating-model redesign is itself a strategic programme. Trying to change every element at once can create organisational paralysis.

A disciplined sequence is:

Restate the strategy. What has changed in where to play, how to create value or what capabilities matter?
Define design principles. What must the new model make easier?
Map value streams and critical decisions. Where does value cross boundaries?
Design accountability and decision rights. Who owns what?
Design structural and capability homes. Where should teams and shared capabilities sit?
Redesign governance and cadence. How will decisions, escalation and learning work?
Align processes, data and technology. Does the technical system support the new model?
Align talent, incentives and performance. Can people succeed inside the design?
Stage the transition. What changes first, and what must remain stable?
Measure operating behaviour. Is the model actually functioning?

This sequence is iterative rather than perfectly linear.

Technology constraints may force a structural adjustment. Talent scarcity may change centralisation choices. A pilot may reveal that a decision right needs more guardrails.

The goal is not to freeze the design early. It is to keep each detail traceable to the strategic logic.

A useful redesign should also specify what will not change.

Too much simultaneous change makes it difficult to know what worked and destabilises essential operations.

The operating model should protect continuity while changing the architecture that needs to change.

29. The Transition Operating Model Matters as Much as the Target Model

Organisations often design a future operating model and under-design the transition between current and future states.

This is dangerous because the organisation must continue serving customers, students or citizens while roles, systems and authority are moving.

A transition operating model answers temporary questions:

Which old decisions remain in force?
When do new decision rights begin?
Who resolves conflicts between old and new structures?
Which systems are authoritative during migration?
How are duplicate roles handled?
What information must be preserved?
Which performance expectations are temporarily adjusted?

Without explicit answers, people make reasonable but incompatible assumptions.

A new product team believes it owns prioritisation while the legacy project steering committee still approves scope. A local business unit believes authority has moved while the technology system still routes approval to headquarters.

The organisation now has two operating models.

Temporary duplication can be necessary. It should be deliberate and time-bounded.

One useful transition device is a cutover map:

Operating Element	Current State	Transition Rule	Target State
Decision authority	Central committee	Local authority begins for defined cases on date X	Local decision within guardrails
Data source	Legacy system	Dual reporting with reconciliation	New common platform
Funding	Project budgets	Existing projects run out; new work uses product funding	Persistent product allocation
Performance	Functional KPIs	Add end-to-end measures before old metrics retire	Outcome plus capability measures

The transition model should disappear when the target becomes stable. If temporary committees, duplicate reporting or dual systems remain indefinitely, they become new operating-model debt.

The transition also needs communication that explains practical behaviour. Employees do not need only the future vision. They need to know which rule applies today.

That is why transition design belongs inside operating-model design, not inside a separate communications workstream.

30. Mergers and Acquisitions Expose Operating-Model Assumptions Quickly

Mergers create an immediate operating-model question: what should be integrated, what should remain distinct and how quickly?

Companies often focus first on structural integration because it is visible. The deeper value and risk sit in capabilities, customers, systems, decision rights and culture.

An acquisition thesis might depend on:

shared distribution,
cross-selling,
technology reuse,
procurement scale,
talent access,
geographic reach,
combined product capability.

Each synergy implies an operating-model change.

Shared distribution requires decisions about customer ownership. Technology reuse requires architecture and data standards. Procurement scale requires centralisation of some supplier decisions. Talent access requires mobility and career rules.

If the synergy thesis does not specify operating-model changes, it remains financial arithmetic.

Integration speed should vary by element.

Some areas benefit from rapid integration: financial control, safety, security or critical data definitions.

Other areas may need preservation: local customer relationships, specialist culture, product experimentation or a distinctive brand.

Over-integration can destroy the capability that justified the acquisition.

Under-integration can leave the synergies unrealised.

A useful integration principle is to integrate where shared operation creates strategic value and preserve autonomy where local differentiation matters more.

This requires explicit evidence. “One company” is not by itself a sufficient reason to centralise every function.

31. Growth Changes the Operating Model Before Leaders Notice It

A model that works for twenty people can fail at two hundred. A model that works for one location can fail across ten.

Growth increases coordination demand.

Informal communication stops reaching everyone. Founders become decision bottlenecks. Exceptions multiply. New managers interpret standards differently. Customer variation rises.

This does not mean every growing organisation should become more bureaucratic.

It means that coordination mechanisms must evolve.

Useful additions can include:

clearer decision rights,
shared data definitions,
reusable onboarding,
explicit quality standards,
management layers where span of control has become unrealistic,
common platforms,
formal escalation for rare but high-consequence exceptions.

The challenge is adding only the coordination the system now needs.

Too little structure creates chaos. Too much structure creates friction before scale justifies it.

A useful growth test is to ask which mechanism that once worked informally has now become unreliable.

Perhaps everyone once knew the founder’s judgement. Now new teams need an explicit principle. Perhaps one spreadsheet once coordinated orders. Now the organisation needs shared workflow. Perhaps customer issues were once solved by memory. Now information needs a durable system.

Growth therefore converts tacit operating models into explicit ones.

32. Resilience Must Be Designed Into the Operating Model Before Crisis

Operating models optimised only for normal conditions can become fragile under stress.

Resilience design asks what must continue when people, suppliers, systems or facilities are unavailable.

It should identify:

critical functions,
single points of failure,
minimum viable service,
decision rights during disruption,
backup information and communication paths,
cross-trained roles,
recovery sequence.

Resilience does not require duplication everywhere.

The strongest resilience investment targets dependencies whose failure propagates widely.

For example, a company may accept lower redundancy in a non-critical internal tool but build stronger recovery around identity, payments and core customer data.

A school may tolerate temporary delay in one administrative process but require continuity in safeguarding, communication and essential learning.

Crisis operating models also need pre-agreed authority.

If every urgent decision must travel through normal governance, the organisation may respond too slowly. If crisis authority has no boundary, temporary emergency power can become permanent ambiguity.

Therefore the model should define crisis triggers, temporary decision rights and the conditions for returning to normal governance.

Resilience is part of operating-model quality because the operating model is expected to work across a plausible range of conditions, not only on an average day.

33. Operating Models Under Uncertainty Need a Stable Core and Adaptive Edge

An operating model cannot be rebuilt every time the environment changes.

It needs enough stability for people to learn how the system works and enough adaptability to respond when assumptions change.

A useful architecture separates a stable core from an adaptive edge.

The stable core can include:

purpose,
ethical and safety boundaries,
critical data standards,
enterprise identity,
core decision principles,
shared infrastructure.

The adaptive edge can include:

local workflow,
experiments,
tactical pricing inside guardrails,
channel choices,
temporary team composition,
implementation sequence.

This architecture protects coherence while allowing adaptation.

Modularity and explicit interfaces make the boundary possible.

The stable core should itself be reviewed at a slower strategic cadence. If the market, technology or business model changes enough, even core elements may need redesign.

For the broader uncertainty logic, see Strategy Under Uncertainty.

34. An Education Operating Model Connects Learning, Teaching, Assessment and Support

Operating-model thinking applies to education because learning is also produced by a system of roles, information, routines and decisions.

Consider a tuition centre whose strategy is diagnostic small-group teaching.

The strategy depends on more than small class size.

The operating model needs to answer:

How is a learner’s first weak point identified?
What evidence is recorded?
Who decides the next intervention?
How does the tutor adapt without losing curriculum direction?
How is parent communication linked to actual evidence?
How does knowledge travel between tutors?
Which standards are common and which judgements remain professional?

If small groups exist but tutors use completely different diagnostic logic, the strategy may not produce repeatable capability.

If assessment produces detailed data but no protected time to respond, the information flow has no operational effect.

If parents receive frequent reports but the reports do not say what the learner should do next, communication activity does not necessarily improve learning.

A coherent education operating model links:

curriculum sequence,
diagnostic observation,
teaching response,
practice,
feedback,
assessment,
family communication,
review of transfer.

The model should also protect teacher judgement. Standardisation can improve handoffs and consistency, but teaching is not a production line. Learners differ, evidence is incomplete and professional interpretation matters.

Therefore standardise the interface where possible and preserve judgement where context matters.

This principle allows a small education organisation to scale quality without pretending every child needs the same response.

35. A Small Business Operating Model Must Be Simple Enough to Run Without a Corporate Bureaucracy

Small businesses need operating models too, but they should not copy large-company bureaucracy.

The operating model can be extremely simple if it answers the important questions.

Consider a fictional specialist repair company with twelve employees.

Its strategic promise is accurate diagnosis and reliable repair rather than maximum volume.

A suitable operating model might specify:

one experienced technician owns final diagnosis for difficult cases,
routine intake is prepared by trained staff using a common template,
technicians can approve work inside defined cost thresholds,
customer promises are recorded before the job enters the queue,
repeat failures trigger a weekly review,
specialist time is protected from routine administrative work.

This is an operating model even without departments, committees or sophisticated software.

As the business grows, the model can evolve.

The founder may need to transfer decisions. A second specialist may be developed. Inventory responsibility may become a distinct role. Customer communication may need standardisation.

The small-business operating model should preserve the source of advantage while removing founder dependence.

A useful small-business test is whether the company can deliver the customer promise for a week without the owner making every ordinary decision.

If not, the owner may still be the operating model.

36. Public Institutions Need Operating Models That Combine Legitimacy, Reliability and Adaptation

Public-sector operating models face a different problem from private firms because they must create public value under legal authority, political accountability and distributional obligations.

Efficiency matters, but efficiency is not the only objective.

Public operating models may need to balance:

consistency and local discretion,
speed and due process,
privacy and information sharing,
equity and administrative simplicity,
specialist judgement and transparent rules,
central standards and agency autonomy.

Decision rights require particular care because authority is constrained by law and public accountability.

A technically efficient workflow can still be a poor operating model if it places decisions outside legitimate authority or prevents meaningful appeal.

Public systems also have long-lived infrastructure and inter-agency dependencies.

A citizen may experience one life event that crosses housing, healthcare, education, transport and social support. Internally, those are separate institutions. The operating-model challenge is to create usable interfaces without erasing legitimate differences in mandate.

Singapore provides a useful methodological context because a compact but complex public system makes interdependence visible. Land, transport, housing, education, water and economic policy interact. This does not imply that one particular institutional design is universally correct. It illustrates why operating models must be evaluated as systems rather than as isolated agencies.

Public operating-model quality can be judged partly by whether citizens can receive reliable service without needing to understand the internal architecture themselves.

37. Worked Case: An AI-Enabled Operating Model Without Automation Theatre

Consider a fictional professional-services organisation called Northbridge Advisory.

Its strategy is to provide high-quality specialist analysis faster than traditional competitors while preserving evidence quality and accountable human judgement.

Management initially proposes a simple AI plan: give every consultant a generative assistant and measure how many hours are saved.

That is a technology deployment, not yet an operating model.

The firm maps one end-to-end workflow:

client question received,
scope clarified,
evidence gathered,
analysis prepared,
specialist interpretation,
quality review,
client communication,
learning captured.

The map reveals that drafting is not the main delay. Scope ambiguity, evidence retrieval and reviewer availability create most waiting.

Automating drafting alone would increase output into the review queue.

The operating-model redesign therefore targets the whole system.

Step 1: Clarify decision rights

Consultants may use AI to prepare search plans, summaries, comparison tables and draft analyses. Only qualified specialists may approve material conclusions. Client-facing recommendations require an accountable human owner.

Step 2: Build a shared evidence interface

Every material claim must link to a retrievable source, confidence assessment or explicit assumption. AI-generated prose without traceable evidence cannot enter the final review state.

Step 3: Separate routine and exception pathways

Low-risk factual transformations can pass through automated checks. Novel, contested or high-consequence claims route to specialist review.

Step 4: Change the review cadence

Senior reviewers stop reviewing every draft linearly. They review claims by consequence and exception. This protects scarce expertise.

Step 5: Redefine performance

The organisation stops measuring AI success through output volume alone. It tracks end-to-end cycle time, reviewer load, correction rate, client outcome, unsupported-claim rate and rework.

Step 6: Reallocate released capacity

If preparation time falls, consultants use part of the released capacity for deeper client interaction and part for more rigorous stress-testing. The benefit is intentionally captured rather than absorbed into more drafts.

This operating model changes human work as well as machine work.

Junior staff need stronger source evaluation, model supervision and problem-framing skills. Senior specialists need to design evaluation standards and teach judgement, not simply edit prose.

The firm also needs a governance route for new AI use cases. Every experiment should not require executive approval, but new use involving sensitive client data or consequential automated action should cross a higher threshold.

The case demonstrates why AI operating-model redesign cannot be reduced to “humans plus tools”. The structure of authority, evidence, workflow, talent, performance and resource allocation all change together.

38. The Strategic Operating Model Diagnostic

A diagnostic should reveal whether the operating model supports the strategy or quietly contradicts it.

The following diagnostic can be used at enterprise, business-unit, school, public-service or small-business scale.

Dimension	Diagnostic Question	Typical Failure Signal
Strategy	What strategic choices must the model make executable?	Design begins from current structure rather than future value
Value streams	Who owns outcomes across functional boundaries?	Every function succeeds while the end result fails
Decision rights	Are important decisions located near the right information and risk?	Constant escalation or local overreach
Governance	Do forums exist for real decisions rather than reporting?	Meeting proliferation and delayed closure
Processes	Where does work wait, repeat or require manual reconciliation?	Large queues and exception volumes
Interfaces	Are handoffs explicit and usable?	Repeated clarification and rework
Centre	Does central coordination create more value than friction?	Headquarters bottlenecks and duplicated local workarounds
Technology	Does architecture support the intended decision and workflow model?	Policy changes but systems preserve old authority
Data	Can critical information be trusted and compared?	Reconciliation becomes a permanent function
Talent	Does the model have the skills it assumes?	Roles exist without usable capability
Incentives	Are rewarded behaviours compatible with strategic behaviour?	Local optimisation and hidden gaming
Performance	Can leaders distinguish design failure from execution failure?	People are blamed for structural problems
Culture	Do informal consequences reinforce formal authority?	People avoid decisions they technically own
Resilience	Can critical functions continue under plausible disruption?	Single points of failure dominate
Adaptation	How does the model learn when assumptions change?	Workarounds accumulate instead of redesign

The diagnostic should not be converted automatically into one score.

Different strategies need different operating-model fingerprints.

A highly regulated utility and an early-stage software company should not receive the same ideal answer.

The purpose is to expose contradictions and dependencies.

A useful review can then identify the smallest set of design changes that remove the strongest contradiction.

This prevents operating-model work from becoming an enterprise-wide redesign by default.

39. Common Strategic Operating Model Failure Modes

Structure-first redesign

Leaders redraw reporting lines before clarifying strategy, value streams or critical decisions. The organisation experiences disruption without a stronger operating logic.

Centralisation by habit

Decisions remain at headquarters because they always have, even though local teams now have better information and mature capability.

Decentralisation without guardrails

Units receive autonomy without shared standards, risk thresholds or interoperable technology. Speed improves locally while enterprise coherence deteriorates.

Matrix without decision rights

Two leaders share accountability but no rule determines who decides. Collaboration becomes negotiation and escalation.

Governance theatre

Committees meet frequently but make few consequential decisions. Reporting substitutes for governance.

Shared-service monopoly

Centralisation removes duplication but creates a service bottleneck with weak accountability to internal users.

Product-team theatre

Project teams are renamed product teams while funding, authority, architecture and career systems remain unchanged.

Platform theatre

A platform is built centrally without clear internal users, adoption economics or product ownership. Teams route around it.

Technology-first transformation

New software automates old complexity. The organisation accelerates work that should have been removed.

AI task optimisation

One task becomes faster while the end-to-end workflow remains constrained. Review, verification or decisions become the new queue.

Talent-by-headcount thinking

The organisation counts people but ignores whether the scarce capabilities required by the model actually exist.

Incentive contradiction

The operating model asks for enterprise behaviour while rewards remain local, or asks for innovation while failure is punished.

Metric fragmentation

Every function reaches its target while the end-to-end outcome declines.

Culture bypass

Formal authority moves but informal status and fear keep real decisions in the old place.

Permanent transition

Temporary duplicate systems, committees and roles survive because no explicit cutover or retirement condition exists.

Reorganisation fatigue

The organisation changes structure so often that teams cannot learn the model, accountability never stabilises and every problem is blamed on the next redesign.

These failure modes share one deeper problem: operating-model elements are changed independently even though they function as a system.

40. What Current Apex Research Adds

Current operating-model research converges on several useful ideas.

McKinsey broadens operating-model design beyond structure. Its current “Organize to Value” framework includes purpose, value agenda, ecosystem, leadership, governance, processes, technology, behaviours, rewards, footprint and talent. This supports the central argument of this guide: an operating model is a multi-element system, not an organisation chart.

Strategy& emphasises alignment between strategy, capabilities and operating model. Its current enterprise-strategy material frames operating-model transformation as the design of connected organisations in which strategy, people, governance and technology reinforce performance. Its strategic operating-model work also stresses iterative review rather than a one-time reorganisation.

Bain contributes the design-principle and accountability perspective. Its operating-model work argues that the model must connect strategy to the detailed organisation by specifying structure, accountabilities, governance, behaviours, processes, information and technology. Its long-standing caution against treating operating model as boxes and lines remains highly relevant.

BCG adds a contemporary AI-transition lens. Its 2026 work on AI-powered transformation offices calls for explicit team structure, governance, decision rights, human-versus-AI roles, ways of working, reporting cadence and escalation paths. Its 2026 work on AI productivity argues that capacity gains do not become value automatically: roles, workflows and structure must be redesigned.

The sources differ in vocabulary, but they converge on the mechanism: strategy becomes performance only when decision architecture, work design, capability, technology and incentives move together.

External Reference Points

The external sources support attributed operating-model concepts. They do not validate the fictional cases, local examples or every design recommendation in this article. Those examples are original applications intended to teach how to reason about the system.

41. The Deep Structure of a Strategic Operating Model

At its deepest level, operating-model design performs eight moves.

Translate: convert strategy into explicit design principles.
Organise: place accountability around value, capabilities and strategic units.
Locate: put decisions where information, risk and authority fit.
Connect: design processes, interfaces, data and technology across boundaries.
Enable: provide the talent, incentives and resources the model assumes.
Govern: route challenge, escalation and high-consequence decisions appropriately.
Learn: use cadence and performance evidence to detect model failure.
Reconfigure: redesign when strategy, technology, scale or constraints change.

The sequence explains why structure alone is insufficient.

Structure without decision rights creates ambiguity. Decision rights without data create guesswork. Processes without incentives create workarounds. Technology without work redesign automates friction. Talent without authority creates frustration. Governance without cadence becomes ceremonial. Adaptation without a stable core creates chaos.

A Compact Formula

Strategic Operating Model = Strategic Design Principles + Value Architecture + Decision Rights + Governance + Processes + Information and Technology + Talent and Incentives + Learning Cadence.

This is a conceptual formula rather than a numerical equation. It is designed to make missing elements visible.

The model works when these elements reinforce one another strongly enough that the strategy becomes normal organisational behaviour.

42. Continue Through the Strategy Series

What Is Strategy? — goals, choices, resources and advantage.
How Strategy Works — diagnosis, choice, execution, feedback and adaptation.
Strategic Positioning — where to compete, whom to serve and what to refuse.
Strategic Capabilities — what the organisation must be able to do repeatedly.
Strategic Resource Allocation — where scarce resources move.
Strategic Coherence — whether choices, capabilities, incentives and actions reinforce one another.
Strategic Trade-Offs — what must be sacrificed when good objectives conflict.
Strategic Constraints — bottlenecks, limits and sequence.
Strategic Priorities — what matters now, what waits and what stops.
Strategic Leverage — where one intervention can change the whole system.
Strategic Execution — coordinated action, accountability and feedback.
Strategic Adaptation — changing route without losing the objective.
Strategy Library — the full Strategy series.

43. Strategy Becomes Real When the Organisation Knows How to Behave

A strategy can be elegant and still remain inert.

It becomes real only when people know what they own, which decisions they can make, what information they can trust, how work crosses boundaries, which capabilities are shared, what behaviour is rewarded and how the organisation responds when reality changes.

That is the job of the operating model.

The best operating models do not attempt to control every action. They create enough structure for coherent action and enough freedom for informed judgement.

They centralise what must remain common and decentralise what benefits from local information. They protect scarce expertise while making ordinary decisions faster. They use technology to remove friction rather than automate bureaucracy. They make accountability visible across the whole value stream. They treat culture, incentives and data as architecture rather than afterthoughts.

They also remain provisional.

Growth changes coordination. Technology changes task economics. AI changes the boundary between preparation and judgement. New strategy changes which capabilities matter. Acquisitions change interfaces. Crises expose fragility.

The operating model must therefore be stable enough to run and adaptable enough to remain fit.

The central discipline is simple to state and difficult to execute:

Design the organisation so the behaviour required by the strategy becomes easier, clearer and more repeatable than the behaviour the strategy is trying to leave behind.

That is how structure, governance, processes, technology, talent and decision rights stop being separate management topics and become one working system.

44. Build a Decision Taxonomy Before You Build More Committees

Operating models become slow when every decision is treated as unique.

A decision taxonomy groups recurring decisions according to the information they require, the consequences they create and the speed with which they must be made.

This allows the organisation to design authority deliberately rather than escalate case by case.

A useful taxonomy can distinguish six categories.

1. Routine operating decisions

These occur frequently, are usually reversible and depend on local information. Examples include daily staffing adjustments, routine customer exceptions inside approved limits and ordinary schedule changes.

These decisions usually belong close to the work.

2. Standard exceptions

These fall outside the normal rule but are familiar enough to have a defined escalation route. The operating model can route them to a specialist or designated approver without involving general management.

3. Cross-functional coordination decisions

These affect several units and require shared information. Examples include launch timing, enterprise customer commitments or trade-offs between product speed and operational readiness.

They often need one accountable owner plus a forum for the relevant functions.

4. Resource allocation decisions

These move scarce capital, talent or capacity and therefore affect opportunities elsewhere.

They need comparison across alternatives rather than approval of one proposal in isolation.

5. Strategic commitment decisions

These alter positioning, business model, major capability or long-horizon investment. They are often difficult to reverse and deserve broader evidence, explicit assumptions and independent challenge.

6. Crisis decisions

These occur when normal governance is too slow relative to the consequence of delay. The organisation needs pre-agreed emergency authority, communication and return-to-normal rules.

The taxonomy creates a decision architecture.

Decision Class	Typical Owner	Evidence Need	Typical Speed
Routine	Frontline or team lead	Current local information	Minutes to hours
Standard exception	Specialist or delegated approver	Exception evidence	Hours to days
Cross-functional	End-to-end owner	Shared operational evidence	Days
Resource allocation	Portfolio or executive owner	Comparative value and opportunity cost	Days to weeks
Strategic commitment	Executive/board as appropriate	Scenarios, assumptions, risk, reversibility	Weeks or longer
Crisis	Pre-authorised crisis owner	Minimum reliable situation picture	Immediate

This does not mean every organisation must use these exact six categories. The point is to reduce ambiguity by classifying recurring decision types.

Once decisions are classified, the operating model can simplify governance dramatically.

Meetings can disappear because routine decisions no longer need collective approval. Senior forums can focus on the decisions that actually require senior judgement.

The taxonomy should also state what happens when evidence is incomplete. A local decision should not automatically escalate simply because uncertainty exists. The relevant question is whether the uncertainty could change a protected boundary or system-wide outcome.

Decision taxonomy is therefore a practical way to align speed, authority and consequence.

45. Design Governance Forums Around Decisions, Not Participants

Many governance forums are inherited rather than designed.

A monthly meeting exists because it has always existed. Everyone attends because nobody wants to be excluded. The agenda combines information sharing, operating issues, strategic discussion and approval requests.

The result is predictable: too much information, too little decision quality and unclear ownership after the meeting ends.

A better design begins from the decision.

For each standing forum, define:

the decisions it exists to make,
the decisions it explicitly does not make,
the accountable chair or owner,
required participants,
required evidence,
decision deadline,
recording and follow-up method.

If a meeting exists only to share information, another communication mechanism may be better.

If a forum cannot name the decisions it owns, it is difficult to justify its recurring cost.

One useful forum architecture contains four distinct spaces.

Operating review

Purpose: detect flow problems, service risks, operational exceptions and near-term capacity issues.

Evidence: live outcome, queue and exception indicators.

Performance review

Purpose: assess whether business or service outcomes and capability measures are moving as intended.

Evidence: trends, root-cause hypotheses and action results.

Resource and portfolio review

Purpose: compare competing claims on capital, talent and capacity; stop or accelerate work.

Evidence: opportunity cost, dependencies, actual utilisation and strategic fit.

Strategy review

Purpose: challenge major assumptions, positioning and capability direction.

Evidence: market change, scenario signals, strategic performance and external developments.

These forums may occur at different cadences. They should also connect.

An operational pattern that persists should move upward into performance review. A performance issue caused by insufficient capability may require resource reallocation. A recurring failure rooted in a changed market may require strategic review.

This creates an escalation pathway based on problem type rather than political visibility.

Governance forums also need expiration rules. A temporary transformation committee should close when the operating model can absorb its decisions. Otherwise transition governance becomes permanent overhead.

The cost of governance should be visible. Ten senior leaders in a two-hour weekly meeting consume twenty senior-leader hours before preparation and follow-up. If the forum makes no decisions worth that cost, the operating model should change.

46. A Management Cadence Should Match the Half-Life of the Decision

Cadence is not simply a calendar preference. It should reflect how quickly the relevant information becomes stale and how quickly action must occur.

Some decisions have a short half-life.

A customer incident, liquidity warning or cyber event can become much worse in hours.

Other decisions have a longer half-life.

Capability strategy, location footprint or organisation design may need months or years to mature. Reviewing them daily creates noise rather than responsiveness.

A good cadence therefore matches:

rate of change,
cost of delay,
reversibility,
measurement reliability,
time needed for the intervention to work.

This prevents overreaction to normal variation.

Suppose a product team reviews daily user behaviour. That may be useful for operational anomalies. It may be too volatile for deciding whether a strategic positioning hypothesis is working.

Conversely, a quarterly review may be too slow for a rapidly degrading service queue.

Cadence design should also prevent duplicate reporting.

The same data should not be rebuilt manually for several meetings. Ideally the operating information system supports different decision views from a common base.

A practical cadence map can show:

Cadence	Decision Focus	Typical Evidence
Daily / real time	Incidents, flow, immediate exceptions	Queues, alerts, service state
Weekly	Operational bottlenecks and near-term commitments	Cycle time, capacity, delivery risk
Monthly	Performance and cross-functional patterns	Outcome trends, rework, customer behaviour
Quarterly	Resource shifts and portfolio balance	Strategic value, capability gaps, opportunity cost
Semiannual / annual	Deep strategic assumptions and operating-model fit	Market structure, scenarios, model health

These periods are illustrative rather than universal. A fast-moving digital business and a regulated infrastructure provider may need very different clocks.

The design principle is that the review frequency should be fast enough to preserve decision value and slow enough for the evidence to become interpretable.

47. Worked Value-Stream Redesign: From Customer Request to Resolved Outcome

Consider a fictional B2B service provider whose customers complain that complex service requests take too long.

The current process is:

account manager receives request,
sales operations clarifies contract,
technical team assesses feasibility,
finance checks pricing,
risk reviews exceptions,
operations schedules work,
account manager communicates answer.

Every function has a reasonable role. The end-to-end outcome is still poor.

A sample of cases shows that actual expert work averages two days, while elapsed time averages fourteen.

The first instinct is to ask each function to respond faster.

The operating-model review asks a different question: why are decisions serial when some could occur in parallel or within predefined guardrails?

The team discovers:

most pricing checks fall within standard bands,
most risk reviews concern only two recurring exception types,
technical feasibility is often waiting for contract information already known to the account manager,
no one owns total cycle time.

The redesigned operating model makes four changes.

First: one case owner is accountable for the end-to-end request.

Second: standard pricing and risk decisions move into guardrails used by the case team.

Third: the request intake captures the information technical staff repeatedly ask for.

Fourth: true exceptions route directly to specialists instead of making every request follow the exception path.

This redesign changes decision rights, process, information and accountability together.

A technology workflow can then support the new design.

If the organisation had automated the old sequence first, it might have digitised fourteen days of waiting.

The example illustrates why operating-model redesign should precede automation when the current process contains structural delay.

The measurement plan should include:

end-to-end cycle time,
exception rate,
rework,
pricing or risk breaches,
customer promise kept,
specialist workload.

Faster completion is not enough if risk or quality deteriorates.

48. Worked Product-and-Platform Design: When Shared Capability Becomes Infrastructure

Consider a fictional digital company with six product teams.

Each team has independently built authentication, notification, analytics and experimentation tooling.

Local autonomy created speed early. Growth now creates duplication.

The company proposes a central platform.

The platform should not exist because centralisation feels mature. It should exist because reuse can create net value.

The operating-model design begins by identifying shared capabilities with three properties:

several product teams need them,
inconsistency creates material cost or risk,
a shared solution can serve different product contexts without excessive customisation.

Authentication qualifies strongly because security and identity consistency matter enterprise-wide.

Experimentation tooling may also qualify if teams need common measurement and statistical standards.

A highly specialised recommendation engine may not qualify because product context differs too much.

The platform operating model then needs:

a platform product owner,
internal user research,
service-level commitments,
adoption metrics,
architecture standards,
a roadmap influenced by consuming teams,
funding that does not depend on one product team.

Product teams retain authority over customer-facing priorities. The platform team owns common capability.

This boundary is crucial.

If the platform dictates product choices outside the shared capability, the centre becomes overreaching. If product teams can bypass critical security standards freely, enterprise risk becomes fragmented.

A strong platform operating model therefore combines common infrastructure with bounded product autonomy.

The success metric is not “number of platforms built”. It is whether product teams can deliver outcomes faster, safer or more reliably because the shared capability exists.

49. Worked Data-and-AI Governance: One Evidence Chain, Several Levels of Authority

Consider a fictional insurer using AI to help triage incoming claims.

The initial technical design classifies claims by complexity and suggests the next action.

The operating-model question is larger: who is allowed to act on the suggestion, under which conditions and with what evidence?

The organisation separates three decision levels.

Level 1: low-consequence routing. The system can automatically route straightforward claims to the correct queue when confidence and data-quality thresholds are met.

Level 2: decision preparation. The system can summarise evidence and recommend additional documents, but a trained claims handler owns the customer-facing decision.

Level 3: consequential exception. Suspected fraud, unusual injury or high-value cases route to specialist review. The model may assist but cannot close the case autonomously.

This creates an authority architecture proportional to consequence.

The data interface records:

source documents,
model output,
confidence or uncertainty where meaningful,
human modification,
final decision,
reason for override,
later outcome if available.

This creates a learning loop.

Human overrides are not automatically treated as errors by the model or errors by the employee. They become evidence for evaluation.

The governance cadence then separates:

operational monitoring for failure and queue load,
monthly review of override patterns and data quality,
periodic model and policy review for changes in risk or regulation.

The operating model also names one accountable executive owner for the end-to-end claims outcome, not merely the AI system.

This prevents the familiar accountability gap where technology owns the model, operations owns the process, risk owns the rules and nobody owns the whole result.

The case demonstrates a general principle: responsible AI governance works best when it is embedded inside the operating model of the decision rather than added as a separate compliance layer after deployment.

50. Operating-Model Archetypes Are Starting Points, Not Templates

Leaders often ask which operating model is best: functional, divisional, matrix, product, platform, networked or some hybrid.

There is no universal winner.

An archetype is useful because it makes a dominant coordination logic visible. It becomes dangerous when copied without regard to strategy.

Functional model

Work is organised primarily by expertise: marketing, finance, operations, technology, teaching, research or similar disciplines.

Strengths include depth of expertise, clear professional development and efficient sharing of specialist resources.

Risks include silos, weak end-to-end ownership and slow cross-functional coordination.

This model is often effective when capability depth matters more than rapid variation by product or market.

Divisional model

Work is organised around products, geographies, customer segments or business lines.

Strengths include clear accountability for a market or P&L and closer alignment with local customer conditions.

Risks include duplicated capabilities, inconsistent standards and competition between divisions.

This model often works when markets or product economics differ substantially.

Matrix model

Responsibility is deliberately shared across two or more dimensions, such as product and geography or function and business unit.

The matrix recognises real interdependence.

Its risk is ambiguity.

A matrix without explicit decision rights can turn every decision into negotiation between two bosses.

The matrix works best when only genuinely interdependent decisions are shared and the rest have clear owners.

Product model

Persistent cross-functional teams own products or customer outcomes.

Strengths include end-to-end ownership, continuous learning and tighter connection between technology and value.

Risks include duplication across products and weakened functional development if specialist communities are neglected.

Platform model

Shared teams provide reusable capabilities to many product or business teams.

Strengths include scale, standardisation and faster reuse.

Risks include central bottlenecks, over-standardisation and internal platforms that exist without genuine user demand.

Network or ecosystem model

Value is created across partners, suppliers, platforms or affiliated organisations rather than inside one hierarchy.

Strengths include access to external capability, flexibility and wider reach.

Risks include unclear authority, data fragmentation, dependence and difficult accountability across legal boundaries.

Most large organisations are hybrids.

A global firm can be divisional by geography, functional for finance and talent, product-based for digital services and platform-based for technology.

The important question is whether the boundaries between archetypes are governed coherently.

A hybrid is not automatically sophisticated. It can simply be accumulated history.

Every layer should have a strategic reason.

51. Layers and Spans of Control Shape Decision Speed and Managerial Quality

Organisation layers influence how far information and authority must travel.

Too many layers can slow decisions, distort messages and create roles whose main purpose is forwarding information upward and instructions downward.

Too few layers can overload managers and leave employees without enough coaching or coordination.

The correct span of control depends on the work.

A manager overseeing highly standardised, independent work may support more direct reports than a manager overseeing complex, interdependent work that requires frequent coaching.

Factors that affect span include:

task complexity,
employee experience,
degree of standardisation,
geographic distribution,
interdependence between roles,
quality of information systems,
amount of coaching expected,
managerial decision load.

This means layer reduction should not be an automatic cost programme.

Removing a layer can improve speed if the layer mainly relays information. It can damage capability if the layer provides essential judgement, coaching or integration.

The role must be examined before the box is removed.

A useful layer test asks:

What decisions does this layer improve?
What information does it integrate?
What coaching or capability does it provide?
What would happen if the layer disappeared?
Could another mechanism provide the same value at lower cost?

Technology and AI can change span because they alter coordination cost.

Better dashboards, automated scheduling or AI-assisted synthesis may reduce routine managerial work.

But they can also create more decisions requiring human review.

Span should therefore be redesigned from observed work rather than theoretical ratios alone.

Layer design is ultimately about the quality and speed of coordination.

52. Role Design Should Start From Decisions, Interfaces and Accountability

A job description lists responsibilities. A strategic role design explains how a role contributes to the operating model.

For each critical role, define:

outcomes owned,
decisions owned,
inputs required,
interfaces with other roles,
escalation boundaries,
capabilities required,
measures that indicate success.

This prevents role design from becoming a list of activities copied from the current organisation.

Consider a product manager.

If the role is expected to own product outcomes but cannot prioritise the roadmap, influence funding, access customers or change the team backlog, the title overstates the authority.

Consider a school leader expected to improve teaching quality.

If the leader cannot observe practice, access relevant learner evidence, adjust professional development or influence timetabling, accountability is disconnected from control.

Role design should also avoid “coordination roles” that exist only because the underlying interface is broken.

Some coordinators are valuable integrators. Others are human APIs translating between systems that should work directly.

The difference can be tested.

If the coordinator left, would the organisation lose judgement and integration—or merely expose a broken handoff?

Roles should also evolve when automation changes task composition.

A role once centred on producing information may shift toward validating, interpreting and acting on information.

This requires new skills and different measures.

The operating model should redesign the role, not simply add AI to the old job description.

53. Shared Services and Global Business Services Need Customer Economics

Shared services centralise activities such as finance, HR, procurement, technology or administration so that multiple business units can reuse capability.

The theory is attractive: less duplication, stronger expertise, standardised processes and lower cost.

The model can fail when the shared service is designed around provider efficiency rather than user outcomes.

Internal customers then experience:

long queues,
rigid processes,
unclear service levels,
little influence over priorities,
high escalation cost,
workarounds outside the official service.

The organisation has centralised cost and decentralised frustration.

A strong shared-service operating model needs four forms of discipline.

Service definition

What exactly is provided? What is standard, configurable or out of scope?

Demand governance

How are competing requests prioritised? Can business units see capacity and queue status?

Service-level evidence

Does the service track cycle time, quality, first-time-right performance and user burden?

Continuous redesign

Does the service remove demand by fixing upstream causes, or merely process the same avoidable requests faster?

Chargeback or allocation mechanisms can also influence behaviour.

A completely free internal service can attract excessive demand. A rigid chargeback can discourage valuable enterprise use.

The financial model should reinforce strategic consumption, not merely recover cost.

Global business services can go further by integrating several support functions around common processes and technology.

This can create leverage when common workflows truly exist. It can create another layer of abstraction when functions are forced together despite different users and decision needs.

Shared services therefore deserve the same operating-model test as external businesses: are users receiving a service worth its total cost and constraints?

54. Exception Architecture Determines Whether Controls Protect or Paralyse

Controls often become expensive because every case is treated as though it were exceptional.

A stronger operating model separates the routine path from the exception path.

Routine cases use standard rules and move quickly.

Exceptions receive deeper judgement because they involve unusual risk, ambiguity or consequence.

This architecture protects both speed and control.

Consider procurement.

Every purchase could require a full tender and executive approval. That would reduce some risk while making ordinary purchasing unusably slow.

A tiered model can use:

approved suppliers and standard terms for routine purchases,
additional review above financial thresholds,
specialist review for sensitive categories,
executive decision for strategic or irreversible commitments.

The same principle applies to AI, pricing, hiring, customer exceptions, curriculum changes and security.

Exception architecture requires good classification.

If thresholds are too loose, high-risk cases stay on the routine path.

If thresholds are too tight, specialists become bottlenecks.

The operating model should therefore measure exception volume and false escalation.

Repeated exception patterns are especially valuable evidence.

If one “exception” occurs every week, it may no longer be exceptional. The rule or process should change.

This is how governance learns rather than merely accumulates controls.

55. Operating-Model Economics Must Include Coordination Cost

Operating-model choices have economic consequences that are often hidden.

A decentralised model can increase duplication. A centralised model can increase coordination delay. A matrix can improve integration while increasing meeting load. A shared platform can reduce repeated engineering while creating migration cost.

These costs should be compared explicitly.

Total operating-model cost includes more than salaries and systems.

decision delay,
rework,
meeting time,
exception handling,
duplicate capability,
customer friction,
transition cost,
technology integration,
talent turnover caused by unclear roles.

These are coordination costs.

A cheaper structural model can therefore be more expensive operationally.

Suppose centralising a service removes ten local roles but adds long delays that force every business unit to create informal workaround capacity.

The headline saving overstates the system saving.

Likewise, decentralisation can appear agile while each unit separately buys technology, develops policy and hires scarce specialists.

The operating-model business case should therefore include:

direct cost,
coordination cost,
transition cost,
capability value,
risk exposure,
speed and option value.

Some elements resist precise monetisation. That does not justify treating them as zero.

A clear qualitative range is better than false precision.

The economics should also be reviewed after implementation because many costs become visible only in use.

56. Measure Operating-Model Health Directly

Business outcomes can deteriorate for many reasons. Operating-model health measures help determine whether organisation design is part of the problem.

Useful measures include:

Decision speed

How long do recurring important decisions take from ready-to-decide to closure?

Measure by decision type rather than one average.

Decision escalation

What proportion of decisions leave the level where they were intended to be made?

High escalation can indicate unclear authority, weak capability or excessive risk sensitivity.

Handoff rework

How often is work returned because the receiving team cannot use it?

Queue age

Where does work wait longest, and which decision or capability controls the queue?

Duplicate capability

How many local teams have built overlapping tools or specialist groups because the shared capability did not meet their needs?

Management load

How much senior time is spent in recurring coordination, approval and reporting?

Role clarity

Can people accurately state who owns important outcomes and decisions?

Resource mobility

How quickly can talent and funding move when priorities change?

Platform adoption

Do internal users voluntarily choose common capabilities because they are useful, or use them only because policy requires it?

Exception burden

How much work falls outside the standard operating path?

No single measure defines operating-model health.

The pattern matters.

For example, slow decisions combined with high escalation and heavy senior meeting load strongly suggest authority is not located well.

High rework combined with incompatible data and duplicate local tools suggests interface and platform problems.

These measures help make organisation design empirical rather than anecdotal.

57. Stress-Test the Operating Model Before the Environment Does It for You

An operating model can look efficient under ordinary conditions and fail quickly when one assumption changes. Stress testing asks how the model behaves when volume, people, technology, suppliers, regulation or information move outside the conditions for which the model was originally designed.

The purpose is not to predict every crisis. It is to reveal structural dependence.

A useful stress test begins with the operating model’s critical functions and then changes one condition at a time.

Demand doubles for four weeks.
A scarce specialist is unavailable.
A major supplier fails.
The primary technology platform is degraded.
Critical data becomes unreliable.
A regulatory rule changes suddenly.
An AI model loses accuracy on a material task.
A large business unit must operate independently for several days.

For each scenario, trace what happens to decision rights, queues, information, workarounds and customer or citizen outcomes.

Suppose demand doubles. The first question is not simply whether the organisation has enough headcount. Which stage becomes binding? Which decisions accumulate? Which exceptions become common? Which shared services are suddenly overloaded?

If a specialist is unavailable, ask whether the system has secondary capability, an escalation substitute or a safe degraded mode. If the answer is “the work stops until the person returns”, the operating model has a visible single point of failure.

Technology failure exposes another layer. Can the organisation identify the minimum viable process that still protects safety, legality and essential service? Can local teams make bounded decisions offline? Is the fallback documented and practised, or does it exist only in a continuity plan nobody has used?

Data corruption creates a different problem. The system may continue operating while making worse decisions. A resilient operating model therefore needs not only system availability but information-quality signals, provenance and correction routes.

AI degradation makes this especially important. A model can remain technically available while the quality of its outputs shifts. If the operating model has delegated work without defining monitoring, exception thresholds and human fallback, the organisation may discover the degradation through downstream harm rather than through controlled detection.

A stress-test matrix can make these dependencies visible.

Stress	Likely Failure Point	Operating-Model Question	Protective Design
Demand surge	Queue or scarce capability	What becomes binding first?	Prioritisation rules, surge capacity, degraded service tiers
Key-person loss	Expert judgement	Which decisions depend on one person?	Succession, cross-training, escalation substitute
Supplier failure	External dependency	What cannot continue without this partner?	Alternative route, buffer, substitution
Technology outage	Workflow execution	What minimum service must continue?	Fallback process, offline authority, recovery order
Data-quality failure	Decision integrity	How is bad information detected?	Validation, lineage, exception flag, correction
AI degradation	Automated preparation or action	When does human review increase?	Monitoring thresholds, fallback, independent checks

Stress tests should also examine recovery. A resilient model is not one that never degrades. It is one that knows what must remain, what can temporarily weaken and how normal operation will be restored.

This creates three operating states:

normal mode — ordinary authority, service levels and controls,
degraded mode — explicit temporary simplification that protects essential outcomes,
recovery mode — sequence for restoring normal capability and retiring emergency workarounds.

The degraded mode matters because organisations often improvise it under pressure. Temporary decisions then persist after the crisis and create operating-model debt.

Stress testing therefore strengthens both resilience and design clarity. It shows where the model truly depends on one person, one dataset, one supplier, one platform or one approval path.

58. Knowledge and Organisational Memory Are Operating Infrastructure

An operating model does not function only through current people and systems. It also depends on memory.

Organisational memory includes documented procedures, decision history, technical knowledge, customer context, learned exceptions, relationships and tacit judgement held by experienced people.

When memory is weak, the organisation repeatedly pays to rediscover what it once knew.

Symptoms include:

the same debate returns because prior decisions are forgotten,
new staff repeat old mistakes,
customers must re-explain history,
one senior employee becomes the only source of context,
post-project lessons are recorded but never used,
AI or search systems retrieve documents without knowing which version is authoritative.

Knowledge management is therefore not merely an archive problem. It is a decision-flow problem.

The operating model should decide which knowledge must be reusable and where it belongs.

Different knowledge requires different treatment.

Rules and standards

These need authoritative versions, owners and change control. People should be able to know which standard is current.

Decision records

These should capture why consequential choices were made, which assumptions mattered and what would trigger review. Their value is not bureaucracy; it is preventing future teams from mistaking an old decision for an unexplained constraint.

Worked cases

These preserve how judgement was applied in representative situations. They are especially useful when simple rules cannot capture all relevant context.

Tacit expertise

This cannot always be reduced to documents. It may need apprenticeship, paired work, review, simulation or observation.

A good operating model therefore uses several memory mechanisms rather than one knowledge repository.

Handover is a particularly revealing test.

If a new person enters a critical role, can they locate the purpose of the role, the key decisions, active commitments, major interfaces, known exceptions and current risks without relying entirely on one predecessor’s memory?

If not, succession risk is partly an operating-model problem.

AI changes organisational memory in two opposite ways.

It can improve retrieval across large stores of information. It can also make weak information architecture more dangerous because an answer can sound coherent even when source documents conflict or are obsolete.

Therefore AI-enabled memory needs provenance, freshness and authority.

A useful knowledge interface answers:

Where did this information come from?
Who owns it?
When was it last validated?
What version supersedes it?
What decision is it safe to support?

Knowledge is high leverage when it changes future decisions. An archive nobody uses is not organisational memory in an operational sense.

This means learning loops should end by changing something durable: a standard, interface, training case, model, workflow or decision principle.

Otherwise the organisation experiences insight without institutional learning.

59. The Customer or User Promise Should Shape the Internal Operating Model

An operating model exists to create value for somebody outside the internal chart.

That makes the customer, learner, citizen or internal user promise an important design input.

Suppose a company promises “fast, expert resolution”. Internally, its model should make fast access to expertise normal. If cases travel through several generic queues before reaching a specialist, the promise and model conflict.

Suppose a tuition centre promises diagnostic small-group teaching. The operating model should provide enough visibility, tutor judgement and response time to make diagnosis meaningful. Small class size alone is not the promise.

Suppose a public service promises one simple citizen journey. If users must understand which internal agency owns each step, the operating architecture is leaking outward.

A user promise can therefore be translated into operating requirements.

User Promise	Possible Operating Requirement
Fast response	Local decision rights, short queues, usable information
Expert quality	Access to scarce specialists, standards, review
Personalisation	Context data, bounded local judgement, flexible workflow
Low cost	Standardisation, automation, scale, limited exceptions
Reliability	Process control, resilience, clear escalation
Seamless journey	End-to-end ownership and strong interfaces

The table illustrates the principle, not a universal mapping.

Promises can also conflict. Fast, highly personalised, low-cost and perfectly controlled service may not all be maximised at once.

The operating model should embody the trade-off chosen by the strategy rather than hide it.

Service levels make some promises operational.

A service level should describe what the user can rely on, not merely what the provider intends.

Useful service evidence can include:

time to first response,
time to resolution,
first-time-right rate,
quality threshold,
availability,
exception route,
communication when the promise cannot be met.

When internal performance measures and external promises diverge, internal measures should be questioned.

A team can hit its departmental target while the customer journey fails.

The operating model should make the end-to-end promise visible enough that local metrics cannot conceal failure.

60. Multi-Business Operating Models Need a Clear Theory of Corporate Parenting

When an organisation contains several businesses, the operating model must define what the corporate parent contributes beyond ownership.

A parent can allocate capital, develop leaders, set risk standards, create shared capabilities, provide brand, enable cross-business customers, manage technology or coordinate strategic learning.

Every central role should have a value logic.

If the parent cannot improve a business through coordination, capability or governance, central intervention can destroy rather than create value.

This makes corporate parenting an operating-model question.

Consider three fictional businesses inside one group:

a mature industrial business,
a fast-growing digital service,
a specialist professional-services unit.

The businesses share ownership but have different economics, customers and operating rhythms.

Forcing them into one detailed operating model would be incoherent.

The group can instead define enterprise layers.

Common layer: ethics, financial control, cyber standards, leadership principles, core data requirements.

Shared capability layer: selected procurement, talent programmes, technology infrastructure or analytics where reuse creates genuine value.

Business-specific layer: customer operations, product model, commercial decisions and local workflows appropriate to each business.

This architecture allows coherence without sameness.

The parent should also define when it will intervene.

capital above delegated thresholds,
systemic risk,
cross-business opportunity,
material underperformance,
leadership succession,
shared capability decisions.

Without explicit triggers, the centre may micromanage successful businesses and ignore failing ones.

Multi-business models also need a rule for synergies.

Synergy should not be assumed because two businesses share a parent.

A cross-business initiative should specify the shared customer, capability, technology, supplier or knowledge mechanism that creates value.

This protects the group from corporate projects whose only rationale is that collaboration sounds desirable.

61. High-Reliability Operating Models Add Independent Challenge and Segregation of Duties

Some operating environments have consequences so high that ordinary speed-versus-control trade-offs change.

Aviation, healthcare, critical infrastructure, financial control, safety engineering and other high-consequence systems often need stronger assurance and independent challenge.

The design principle is not “more approvals everywhere”.

It is to place independent scrutiny where one person’s error, conflict of interest or hidden assumption could create disproportionate harm.

Useful mechanisms include:

segregation of duties,
independent verification,
peer review,
change control,
formal handover,
incident reporting,
root-cause review,
stop-work authority.

Segregation of duties means that one person or team does not control every stage of a high-consequence transaction.

For example, the person creating a payment should not necessarily be the only person approving and reconciling it. The person developing a high-risk model should not be the only person validating its performance.

Independent challenge is useful when incentives or cognitive commitment could bias the primary owner.

However, assurance can become ceremonial.

If reviewers lack expertise, evidence, time or genuine authority to challenge, a second signature adds latency without adding much safety.

High-reliability governance therefore needs quality of challenge, not merely number of reviewers.

Change control is another important operating mechanism.

When a system is safety-critical, changes should have clear ownership, evidence, rollback and communication.

This does not mean all change is slow. It means the level of control is proportional to consequence.

The same principle can be applied to AI systems that influence consequential decisions: stronger validation, monitoring and independent review where potential harm is higher.

A high-reliability operating model therefore embeds challenge inside the workflow instead of relying on goodwill after the decision.

62. Innovation Needs an Operating Model for Exploration and a Route Into Scale

Innovation often fails at the boundary between experiment and operation.

An innovation lab can generate ideas, prototypes and pilots. The core business may have no mechanism to adopt them.

The operating model therefore needs two capabilities:

exploration under uncertainty,
scaling proven changes into ordinary operation.

Exploration benefits from different rules.

Teams need bounded freedom, small experimental budgets, fast feedback and tolerance for unsuccessful hypotheses.

Core operations need reliability, standards, predictable capacity and controlled change.

Trying to run both with one governance model can damage both.

The operating-model solution is not permanent separation. It is a clear interface.

An experiment should have:

a problem or hypothesis,
bounded scope,
learning objective,
protected ethical and safety limits,
evidence for continuation,
a scale owner if the test succeeds.

The last item is often missing.

A pilot succeeds but no business owner owns adoption, no funding route exists and technology cannot support the new process at scale.

The result is pilot theatre.

A stronger model identifies the scaling pathway before the pilot finishes.

This does not mean committing to scale before evidence exists. It means knowing which decisions and capabilities would be required if the evidence becomes strong.

Innovation also needs a stop mechanism.

Experiments should not survive indefinitely because they are labelled innovative.

When evidence weakens, capacity should return to other opportunities.

The operating model therefore turns innovation into a managed flow from question → experiment → evidence → decision → scale or stop.

63. Strategic Learning Requires the Operating Model to Change Its Own Rules

An organisation can learn facts without learning strategically.

Strategic learning occurs when evidence changes not only an action but the assumptions, rules or architecture that produced the action.

Consider a local team that repeatedly escalates pricing exceptions.

A narrow learning loop asks how to process the exceptions faster.

A deeper loop asks whether the pricing bands, customer segmentation or delegation rule is wrong.

This second form is operating-model learning.

Useful learning signals include:

repeated exceptions,
persistent workarounds,
metrics that improve locally while outcomes decline,
decision escalation above expected levels,
duplicate capabilities appearing independently,
high-performing teams bypassing the official process,
customer behaviour inconsistent with the original design assumptions.

These signals should not automatically trigger redesign.

They should trigger investigation.

A strategic learning review can ask:

What operating assumption produced this design?
What new evidence challenges that assumption?
Is the issue local or systemic?
Which element would need to change?
What else depends on that element?
What small reversible test could validate the redesign?

This prevents two extremes.

One extreme is rigidity: “the process is the process”.

The other is instability: every complaint triggers a new process.

Strategic learning needs thresholds for changing the operating model.

It also needs memory so that old failed designs are not rediscovered under new names.

This makes the operating model a learning system rather than a static blueprint.

64. A 90-Day Operating-Model Review: Diagnose Before You Reorganise

An operating-model review does not need to begin with a major transformation programme. A focused ninety-day review can establish whether the organisation has a structural problem, where the strongest contradictions sit and which changes deserve deeper design.

The ninety-day period below is illustrative. It is not a universal implementation schedule. A small organisation may work faster; a regulated or global enterprise may need much longer. The sequence matters more than the exact calendar.

Weeks 1–2: Restate the strategic requirement

Do not start with the organisation chart.

Write the strategic choices the operating model must support.

Which customers or users matter most?
What value proposition must the organisation deliver?
Which capabilities are differentiating?
Which trade-offs have been accepted?
What must become faster, more reliable, more local or more shared?

The output should be a small set of design requirements rather than a long strategy summary.

For example: “The model must support rapid local customer adaptation while preserving enterprise risk, data and brand standards.”

That sentence immediately creates design questions about centralisation, platforms and decision rights.

Weeks 3–4: Map value streams and critical decisions

Select a small number of value streams that matter most to the strategy.

Map where work waits, where information changes hands and which decisions repeatedly control speed or quality.

Do not map every process in the company. Focus on the flows whose performance determines strategic value.

For each flow, capture:

outcome owner,
major stages,
critical decisions,
decision owner,
key information,
queue or handoff,
exceptions,
technology dependency.

This stage often reveals that the apparent structural problem is really a decision or interface problem.

Weeks 5–6: Diagnose authority, governance and interfaces

Examine where decisions are actually made compared with where they are formally assigned.

Look for:

decisions repeatedly escalated beyond their intended level,
decisions with several apparent owners,
forums that report but do not decide,
interfaces producing repeated clarification,
exceptions becoming normal work.

Interview people at the boundary between functions rather than only functional leaders. They often see the actual operating model more clearly because they experience the friction.

Weeks 7–8: Test data and technology against the intended model

Identify where systems preserve old authority, force manual reconciliation or prevent information from reaching the right decision.

Ask which technical dependencies are genuine and which are historical.

If AI or automation is already in use, map where output is created, reviewed, corrected, approved and acted upon.

Look for new queues created by faster machine work.

Weeks 9–10: Test talent, incentives and capacity

Ask whether the proposed authority can be exercised by the people who hold it.

Map scarce roles, succession, learning time and hidden dependence on a few experts.

Compare formal priorities with actual incentives.

Do people gain status, promotion or protection by following the intended model—or by bypassing it?

Weeks 11–12: Choose the smallest coherent redesign

Do not automatically recommend an enterprise reorganisation.

Identify the smallest connected set of changes capable of repairing the strongest operating contradiction.

That set may be:

one decision-right change,
one new end-to-end owner,
retirement of two redundant forums,
a common data definition,
a shared platform capability,
a revised incentive,
a redesigned exception path.

The changes should be evaluated as a system.

For example, moving authority locally without changing incentives or systems may fail. Creating an end-to-end owner without access to performance data may fail. Removing a committee without moving its genuine decision rights may create a vacuum.

The ninety-day review should end with three outputs:

a clear operating-model diagnosis,
a small number of design priorities,
a transition path with evidence for review.

This is enough to begin responsible redesign without pretending that a large transformation can be fully specified before the organisation learns from implementation.

65. Independent Challenge: Design the Operating Model From the Symptoms

Consider a fictional organisation called Meridian Learning Network.

It operates eight education centres. Its strategy is to deliver consistent academic standards while allowing each centre to adapt teaching and family communication to local student needs.

Current symptoms are:

centre leaders escalate many routine pricing and timetable decisions to headquarters,
tutors use five different ways to record diagnostic observations,
headquarters produces detailed monthly reports that centre leaders rarely use,
each centre has built its own spreadsheet for parent communication,
the central curriculum team is overloaded by requests for minor adaptations,
high-performing tutors are repeatedly borrowed between centres informally,
families sometimes receive different explanations of the same assessment category,
the organisation is considering an AI assistant to automate reports.

Do not begin by choosing a new organisation chart.

Start with the strategy.

The model needs two properties at the same time:

common academic meaning and standards,
local adaptation in decisions that depend on student and family context.

This suggests that centralisation and decentralisation should be separated by decision type.

Academic definitions, assessment categories, safeguarding, core data and major brand promises likely need common governance.

Routine timetable changes, bounded teaching adaptation and ordinary family follow-up likely benefit from local authority.

The escalation volume suggests that local authority is either too narrow, too unclear or unsupported by capability.

The five diagnostic formats suggest an interface problem. Before buying more reporting technology, Meridian needs a common evidence structure that preserves professional judgement while making records interoperable.

A candidate interface might contain four fields:

observation,
interpretation,
support conditions,
next teaching action.

Centres can retain local teaching judgement while sharing this evidence language.

The monthly report problem suggests another operating-model mismatch. Headquarters may be optimising information production rather than decision usefulness.

The review should ask what centre leaders actually need to decide monthly and whether the current report supports those decisions.

The local spreadsheets for parent communication are clues that the central service or platform does not meet operational needs.

The answer is not automatically to ban local tools. First identify what capability the spreadsheets provide that the common system lacks.

The overloaded curriculum team may be receiving work that does not require central expertise. Minor adaptations could move to centres inside clear curriculum guardrails, while major changes remain central.

The informal borrowing of high-performing tutors reveals scarce capability with no formal mobility model.

Meridian could create a transparent mechanism for temporary specialist support, workload protection and capability transfer instead of relying on personal relationships.

Only after these operating questions are resolved should the AI assistant be designed.

If AI automates five incompatible diagnostic systems, it will scale inconsistency.

If Meridian first creates a common evidence interface and clear decision rights, AI can help prepare family-facing summaries while tutors remain accountable for the interpretation and next action.

A coherent redesign could therefore include:

enterprise-owned assessment definitions,
local authority for bounded schedule and teaching decisions,
a common diagnostic evidence interface,
retirement or redesign of low-value monthly reporting,
a common communication platform informed by actual centre workflows,
a formal mechanism for sharing scarce tutor capability,
AI used after the data and accountability model is stable.

Notice what the answer does not require: an immediate merger of all centres into one functional hierarchy.

The independent challenge illustrates the central operating-model skill—designing the decision and information architecture before choosing visible structure.

66. Executive and Board Questions for Operating-Model Oversight

Senior governance should not manage the operating model in operational detail. It should test whether the model remains capable of executing the strategy and controlling material risk.

Useful questions include:

What strategic choices does the current operating model make easier?
Which choices does it unintentionally make harder?
Where are important decisions slower than the environment requires?
Which decisions are repeatedly escalated above their intended level?
Which critical capabilities depend on one person or one team?
Where is duplicated capability growing?
What operating-model debt is accumulating?
Which customer or citizen journeys cross the most organisational boundaries?
Where do incentives contradict the strategy?
Which technology constraints preserve obsolete work?
How is AI changing the relative scarcity of tasks and judgement?
What evidence suggests the operating model is becoming unfit?
What would be difficult to reverse if the redesign is wrong?
How will essential service continue during transition?
What temporary governance will be retired after transition?

These questions are useful because they focus oversight on architecture and consequence rather than on approving every design detail.

Boards and senior leaders should be especially attentive when the operating-model redesign changes accountability, control of large resources, critical risk or the integrity of information used for decisions.

They should also distinguish between executive preference and strategic necessity.

A new chief executive may prefer a different structure. Preference alone is not evidence that the current model is unfit.

Governance quality improves when redesign is tied to strategy, observable friction and capability need.

67. The Strategic Operating Model Design Canvas

The following canvas condenses the longform into a reusable design record.

Field	Design Question
Strategic requirement	What must become easier or more repeatable because of the strategy?
Value streams	Which end-to-end outcomes matter most?
Capabilities	Which capabilities differentiate or enable the strategy?
Units	What should be organised by function, product, customer, geography or platform?
Centre	What creates more value when shared or governed centrally?
Decision rights	Who decides recurring important choices?
Guardrails	Which standards, thresholds and boundaries must remain common?
Governance	Which decisions need forums, independent challenge or escalation?
Cadence	At what rhythm should operations, performance, resources and strategy be reviewed?
Processes	Where does work wait, repeat or cross boundaries?
Interfaces	What must each handoff reliably provide?
Data	Which information definitions and ownership must be common?
Technology	Which architecture supports or constrains the intended work?
AI	Which tasks are prepared, recommended, executed or monitored by machines, and who owns outcomes?
Talent	Which scarce skills, roles and succession paths does the model require?
Incentives	What behaviour will the reward system actually encourage?
Performance	How will end-to-end outcomes and operating-model health be measured?
Resilience	What must continue when critical dependencies fail?
Transition	How will current and target models coexist during change?
Learning	What evidence will cause the model itself to be revised?

The canvas is not a substitute for analysis.

Its purpose is to make the system visible enough that contradictions can be found.

For example, if a design says local units own customer outcomes but the centre controls pricing, staffing, technology and exceptions, the claimed accountability may be unreal.

If the design says shared platforms create scale but each product team can create alternative systems without consequence, reuse may never occur.

If AI can execute decisions but no row identifies human outcome ownership, the model contains an accountability gap.

The canvas should therefore be reviewed horizontally, not only row by row.

The strongest insight is often the relationship between fields.

68. When Not to Redesign the Operating Model

Not every performance problem requires an operating-model redesign.

Reorganisation is disruptive. It consumes leadership attention, creates uncertainty, interrupts relationships and can delay execution while new responsibilities settle.

Sometimes the existing model is sound and the organisation simply needs better execution.

Do not redesign merely because:

one quarter disappointed,
one leader dislikes the current reporting line,
a new management idea is fashionable,
a technology vendor promises transformation,
one team has a local performance problem,
the organisation chart looks untidy.

First ask whether the problem is caused by the model or by capability, discipline, temporary conditions or one poorly performing unit.

A useful no-redesign test includes five questions.

Does the current model still fit the strategy?
Are decision rights fundamentally clear?
Are the major value streams structurally workable?
Can the problem be repaired within the current model?
Would redesign create more disruption than the expected benefit?

If the answers are mostly favourable, targeted repair may be better.

Examples include:

training a new manager rather than changing reporting lines,
fixing one interface rather than restructuring two functions,
retiring a redundant committee rather than redesigning governance completely,
improving data quality rather than launching a new platform,
clarifying one decision threshold rather than decentralising an entire function.

Stability has value.

People learn how a model works. Relationships deepen. Informal coordination becomes efficient. Technology and data mature around the architecture.

Constant redesign destroys these accumulated benefits.

The operating model should therefore change when the cost of mismatch exceeds the cost of transition—not merely when a different model can be imagined.

This is another strategic trade-off.

A mature organisation knows how to distinguish a system that needs redesign from a system that needs to be allowed to work.

69. Verify the Operating Model After Redesign: Acceptance Criteria, Not Launch Theatre

An operating-model redesign is not complete when the new organisation chart is announced, the new committees begin or the technology goes live.

It is complete only when the organisation can demonstrate that the intended operating behaviour is actually occurring with acceptable performance and without hidden damage.

This requires acceptance criteria.

Acceptance criteria describe the evidence that would justify saying the model is functioning as designed.

They should be derived from the design principles rather than invented after implementation.

Suppose a redesign intends to move ordinary customer decisions closer to local teams while preserving enterprise risk standards.

Reasonable acceptance criteria might include:

routine decisions are completed within the intended local authority band,
unnecessary escalation falls,
risk-threshold breaches do not rise materially,
local teams can explain their authority accurately,
customers experience faster resolution,
senior forums spend less time approving routine cases.

No single criterion is enough.

Faster decisions with more uncontrolled risk would not demonstrate a successful model. Fewer risk incidents achieved by silently escalating everything would not demonstrate local empowerment.

The evidence has to represent the intended balance.

A strong verification plan separates four layers.

1. Structural acceptance

Have the formal components been put in place?

roles appointed,
decision rights documented,
forums established or retired,
systems configured,
funding mechanisms changed,
service interfaces defined.

This layer proves implementation, not effectiveness.

2. Behavioural acceptance

Are people actually using the new model?

Are decisions made at the intended level?
Do teams use the common interface?
Do leaders stop overriding local authority informally?
Do product teams own end-to-end outcomes in practice?
Are exceptions following the designed route?

This layer matters because formal design can be ignored while old habits continue.

3. Performance acceptance

Are the mechanisms the redesign was intended to improve actually moving?

decision time,
end-to-end cycle time,
rework,
queue age,
customer or user outcome,
resource mobility,
management load.

The measures should be chosen before the redesign whenever possible so baseline comparison remains credible.

4. Boundary acceptance

What must not deteriorate while the model improves?

safety,
legal compliance,
essential service continuity,
data integrity,
quality floors,
employee workload beyond agreed limits,
fair and legitimate access where relevant.

Boundary measures prevent the organisation from declaring success by shifting cost somewhere less visible.

Verification should also distinguish transition noise from model failure.

A new workflow may initially be slower while people learn it. A temporary dip does not prove the design is wrong. But “people are still learning” should not become an indefinite excuse.

The transition plan should therefore define expected settling periods and the evidence that should improve first.

For example, role clarity and routing accuracy may improve before final cost savings appear. If those early indicators fail to move, waiting longer for the financial outcome may not be sensible.

Independent challenge is valuable at this stage.

The team that designed the model has invested time, reputation and political capital in the redesign. It may interpret ambiguous evidence generously.

A credible review can include people who were not responsible for the design but understand the strategy and operating context.

The purpose is not to create a second bureaucracy. It is to challenge whether the acceptance evidence actually supports the claims being made.

The review should ask:

Which claimed improvement is directly observed?
Which is inferred?
Which alternative explanation could produce the same result?
What burden has moved elsewhere?
Which old workaround still survives?
Which new exception pattern has appeared?
What part of the model should now be stabilised rather than changed again?

The last question is important.

Successful redesign requires a point at which the organisation stops designing and learns to operate the model.

Constant adjustment can prevent the system from producing enough stable evidence to evaluate anything.

A useful verification outcome therefore has three possible conclusions:

accept and stabilise — the model is functioning well enough to become the normal system,
accept with targeted repair — the core model works but one interface, capability or rule needs correction,
reopen the design — evidence shows that a major strategic assumption or operating mechanism remains wrong.

This discipline closes the loop from strategy to design to implementation to evidence.

It also preserves a crucial distinction: launching an operating model is an event; proving that it works is a period of observed organisational behaviour.

The organisation should not confuse the ceremony of change with the capability to operate differently.

Strategic Operating Model | How Structure, Governance, Processes, Technology, Talent and Decision Rights Turn Strategy into a Working System