The Strategy Changed. The Operating Model Did Not.

TL;DR

A strategy becomes real only when it changes the operating instructions of the business. If decisions, handoffs, judgment boundaries, and measures stay the same, the organization will keep producing the old model under a new set of priorities.

The announcement changed. Monday did not.

On Friday, the leadership team approved a new strategy.

On Monday, the same people opened the same reports, followed the same approval paths, protected the same functional targets, and escalated the same exceptions.

Nothing failed. Nothing changed.

That pattern is more common than most executive teams want to admit. PwC’s 2026 Digital Trends in Operations Survey found that 85% of 767 U.S. operations and supply chain leaders believed their organizations were ahead of most competitors in digital transformation. Yet 89% said their technology investments had not fully delivered the expected results.

The structural finding is even more revealing. Among companies with siloed or partially integrated operations, 94% expect to move toward a more horizontal, networked model. Only 41% operate that way today.

I am less interested in the technology finding than the operating contradiction underneath it.

Leaders are funding connected outcomes while the organization still runs through functional instructions. The strategy calls for speed, integration, and a better client experience. The operating model continues to reward local completion, vertical control, and escalation.

The strategy may be clear. The business has not been told how to run differently.

An operating model is a set of choices

When leaders tell me they need a new operating model, my first response is simple: classify that.

Do they mean a new org chart? A technology platform? Fewer approval layers? A shared-services structure? New performance measures? Better handoffs?

Those are related choices. They are not interchangeable.

An org chart tells people where formal authority sits. An operating model explains how a customer promise becomes coordinated work. It determines where decisions are made, what information travels with a handoff, what remains standard, where judgment is expected, and how leaders will know whether the model is producing the intended result.

The HEIMDALL operating model guide usefully describes six connected components: governance, organizational structure, ways of working, technology and data, people and culture, and performance management. The value of the framework is in the interaction among those components.

Changing one component while preserving the others can make the organization look different without changing how it performs.

A new platform operating inside the old approval process will move the same bottleneck to a different screen. A reorganization without redesigned decision rights will give the same confusion new reporting lines. A new metric without a clear owner will create another dashboard people explain after the outcome has already failed.

Automation just changes where the roadblock will be. Operating model design decides whether that roadblock should exist at all.

Every function can succeed while the client still loses

I have watched this happen inside complex enterprise delivery.

The work crossed eight functions and teams in the United States and India. Product protected platform integrity. Engineering protected technical feasibility. Compliance protected regulatory requirements. Operations protected what could be delivered reliably. Quality teams protected acceptance criteria. Relationship leaders protected the client commitment.

Each function had a reasonable definition of success.

The client experienced one outcome.

That is the part the internal scorecards can miss. A requirement can be complete inside one function, technically supported inside another, and operationally unclear at the point of delivery. Every team can report progress while the same defect reaches the client again.

We did not solve that pattern by asking people to collaborate harder. We classified the failures.

Which issues were actual platform constraints? Which came from an ambiguous requirement? Which were created by a handoff with no acceptance standard? Which exceptions represented a real business need, and which existed because the organization had become accustomed to doing the work differently?

Once those categories were visible, we could redesign the operating logic around them. We established a shared delivery language, clearer decision thresholds, evidence requirements for exceptions, and portfolio-level visibility into defects that had previously looked like isolated client incidents.

In the roles where I applied that discipline, recurring operational defects fell by 95%. Clients accepted 92% of proposed platform standards because the conversation stopped being a contest between customization and control. We could separate the requirement from the assumption and offer a clearer yes: yes, we can support the business outcome, and here is the path that will work reliably.

The improvement did not come from a cleaner box-and-line diagram. It came from changing how the system handled recurring decisions.

The strategy-to-work test

Before I call a strategy executable, I want four questions answered. Each one should produce a specific operating decision, not another paragraph of strategic language.

Which recurring decision will change?

A strategic priority should alter a decision the organization makes repeatedly.

If the strategy calls for faster enterprise delivery, which approval moves closer to the work? If it calls for greater standardization, what evidence is now required before an exception is approved? If it calls for a better client experience, who can resolve a conflict between the stated policy and the intended customer outcome?

Decision rights help only when the decision sits where the knowledge and risk meet. Moving a box on the org chart does not answer that question.

Which cross-functional handoff will change?

Most clients do not experience a function. They experience what happens between functions.

A handoff needs more than an owner on each side. It needs a defined input, acceptance criteria, a response window, and a route for the work when the standard condition is not met.

Without those elements, one team can call the work complete while the next team receives something it cannot use. The delay appears downstream, but the failure began at the interface.

Where will judgment live?

An operating model cannot document every future condition. Trying to do so creates another kind of bottleneck: people wait for a rule that was never written for the situation in front of them.

Judgment work should be systematized at the principle level:

• What must we stay true to?
• What is open for team deliberation?
• What is a red-line no?

That structure gives people room to think without asking the business to absorb unmanaged risk. Someone’s yes might still be a business no. The model should help the team see the difference before the decision becomes an escalation.

What evidence will tell us earlier?

Revenue, retention, client escalations, and major defects matter. They also arrive late.

An operating model needs leading signals that expose friction while leaders can still intervene. Depending on the work, those may include first-pass acceptance, reopened decisions, aging dependencies, exception volume, manual workarounds, or repeat defects by category.

Measurement should do more than prove activity. It should tell leaders where the operating model is asking capable people to compensate for weak design.

Do not design the future state from the slide deck

There is a temptation to move directly from strategic ambition to future-state design. The executive team sees the destination clearly, so a workshop produces the new structure, process, and governance model.

I want the data for planning, not dreams.

Before redesigning anything, I want to see how the current work behaves. Show me the decisions that reopened. Show me the issues that escalated twice. Show me the spreadsheet someone built because the official system could not answer the question. Show me where an employee waits for a leader who is supposed to be focused on something else.

Ask twelve people how a process works and you may hear twelve versions. Watch the work and the variation usually becomes smaller. Three versions may be real. The other nine are policy language, preferences, and memory.

That distinction matters. Designing around perceived variation creates unnecessary complexity. Designing from observed work lets leaders identify the few changes that will alter the outcome.

Start with one strategic priority. Follow it through the actual decisions, handoffs, exceptions, and measures required to deliver it. Test the new operating chain with the people doing the work. Trust but verify the result. Then expand it.

Restraint protects the ambition. It gives leaders enough evidence to know what deserves to scale.

The executive should not become the operating model

A capable executive can hide an incomplete operating model for a long time.

They chase dependencies across functions. They translate the strategy for each audience. They broker exceptions, reconcile competing measures, and reassure the client when the internal system does not connect cleanly.

The result may improve. The organization may even praise the leader for being indispensable.

That dependency is operating risk.

At the VP level, the work is to create enough clarity, governance, and feedback that the system can produce the outcome without borrowing the executive’s presence every time conditions become ambiguous.

Strategy becomes real when the organization can make a better decision without the executive in the room.

Take one priority from the current strategy and ask the team:

What will we decide differently, hand off differently, or know sooner this Monday because this is our strategy?

If five people give five different answers, the execution problem has not started yet.

The strategy still needs an operating model.