Every few months I sit across from a senior leader who tells me their cloud transformation has stalled. The infrastructure is sound. The vendor selection was rigorous. The business case was approved at the right level, with the right numbers. And yet somewhere between the architecture sign-off and actual organisational change, the whole thing has quietly lost momentum, and everyone is being professionally careful about whose fault that is.

The conversation usually surfaces the same thing: the organisation built a cloud strategy before it resolved how it would need to work.

This is more common than it should be, and the consequences are not minor. Cloud migration is typically framed as a technology decision, progressed through a technology governance process, and measured on technology outcomes. Cost efficiency. Security posture. Uptime. Scalability. These are legitimate outputs and worth pursuing. They are also incomplete as a frame, because not one of them is delivered by technology alone. Each requires the organisation to make decisions differently, allocate authority differently, and resolve conflict across boundaries that may not have previously been required to interact with any regularity. The cloud infrastructure can support all of that. It cannot substitute for it.

Operating model clarity is not a prerequisite that gets addressed after the strategy is set. It is part of the strategy. Treating it otherwise is how organisations end up with sophisticated architecture sitting on top of unresolved organisational ambiguity, and then spending considerable energy wondering why adoption is slow.

What operating model clarity actually means

It is worth being precise here, because the phrase gets used loosely and tends to make people think of org charts and restructures. Operating model clarity is neither of those things. It is a set of resolved questions about how authority, accountability, and prioritisation work in the environment you are building.

Specifically: who has decision rights when the business wants one thing and the platform team wants another? How does funding move when a workload or service crosses traditional ownership lines? What does the accountability structure look like when something goes wrong in an environment where multiple teams share infrastructure? How does a decision get made when the pace of the platform has outrun the pace of the governance process designed for a different era?

These are not hypothetical edge cases. They are the ordinary texture of operating on cloud infrastructure, and they surface very quickly once migration is underway. The organisations that have not resolved them in advance tend to resolve them under pressure, which is an expensive and uncomfortable way to do governance design.

Why it keeps getting deferred

The pattern is consistent enough to be predictable. A cloud strategy is developed by a team with genuine technical expertise and real organisational goodwill. The strategy is thorough. It is approved. Implementation begins. And then the first cross-functional decision lands — one that requires clarity on ownership or prioritisation across teams that have not historically needed to coordinate at that level or that pace. The technical architecture has an answer. The organisation does not. The cloud waits, and the people responsible for delivery start having meetings that should have happened eighteen months earlier.

This is not a failure of technical capability. It is a failure of scope. The leaders who sponsored the cloud strategy did not include the operating model questions in what they were solving for, because those questions are politically inconvenient and do not fit neatly into a technology business case.

There is also a reasonable logic to the deferral. The argument — sometimes made explicitly, more often held as a quiet assumption — is that the organisational questions will resolve themselves once the benefits of the new environment become visible. People will see what is possible and adapt. Competing priorities will sort themselves out. The platform will create the conditions for a different way of working.

This does not happen. What actually happens is that the ambiguity that was manageable when infrastructure moved slowly becomes an active liability when deployment cycles compress from months to days. The dysfunction does not disappear. It accelerates, and it now costs more per iteration.

The government context

There is a version of this problem that is particularly sharp in government and large institutional environments. Operating models in these settings have frequently evolved over decades, shaped by legislative frameworks, audit requirements, ministerial accountability structures, and funding mechanisms that have their own internal logic. That logic was not designed for the pace or the interdependency that cloud infrastructure introduces.

The cloud is not just a different place to run the same workloads. It is a different risk surface, a different set of dependencies, and a materially different pace of change. Placing it on top of an operating model designed for a slower, more siloed way of working does not modernise the organisation. It creates a modern platform and a legacy operating model sitting in the same environment, generating friction at every seam.

The senior leaders in these environments who execute well are not the ones who solved this by restructuring first. Most of them did not restructure at all. What they did was make a small number of deliberate, explicit decisions before migration began: who has authority over which choices, what the escalation path looks like when business and technology priorities conflict, and how accountability would be held as the environment shifted. These decisions were documented, communicated, and treated as design choices rather than administrative details.

That sounds straightforward. In practice it requires someone in the room to name the questions that are being avoided, and to have both the authority and the appetite to insist they get answered before the program moves forward. That is a leadership act, not a technical one.

The leadership question worth asking

Before any cloud strategy is approved, the leadership question is not whether the architecture is right. The architecture can be refined. The question is whether the organisation has made the decisions that allow people to work within it. If that conversation has not happened, the strategy is structurally incomplete, regardless of what the technical documentation says.

Cloud transformation is not a technology program with change management attached as a workstream. It is an operating model transformation that involves significant technology investment. The distinction matters because it determines who is in the room when the consequential calls are made, and whether those people have the mandate to make them rather than escalate them.

The organisations that move well are not necessarily the ones with the most sophisticated architecture. They are the ones whose leaders treated the operating model as within scope, even when doing so was inconvenient, even when it meant having conversations that slowed the program down before it sped up. They understood that the cloud does not resolve organisational ambiguity. It just makes it more expensive to leave unresolved.

The technology is genuinely the easy part. The hard part is having the right people in the room, with the right questions on the table, before the first workload moves.

— Cindy Schwartz

Founder, Executive Excellence Group | Rewriting Leadership Norms