Every failed transformation programme I have encountered had the same narrative arc. Leadership commissioned a bold vision. Vendors were selected. Budgets were approved. The technology was implemented, sometimes well, sometimes not. And then — nothing changed. The organisation continued operating as it had before, layered over a new system it did not understand and could not maintain.

The technology was not the problem. The operating model was.

An operating model is the system of roles, processes, governance mechanisms, and accountabilities that defines how an organisation creates value. When you introduce a significant new technology capability — a cloud platform, a data product, a new CRM — you are not just adding a tool. You are changing the conditions under which work gets done. If the operating model does not change with it, the technology atrophies.

The Transformation Fallacy

The dominant theory of digital transformation — still alive in many boardrooms — is that technology adoption causes operational change. Buy the platform, train the people, and the organisation will adapt. This is the transformation fallacy, and it is responsible for an extraordinary amount of wasted investment.

Operating models change through deliberate redesign, not through osmosis. If you want teams to move faster, you need to change how they are funded, how their work is prioritised, and who has decision authority over their architectural choices. If you want a data-driven culture, you need to change how decisions are made and what accountability structures exist around data quality. No technology platform delivers those changes. They require intentional organisational design.

A new cloud platform deployed into an organisation with a project-based funding model, centralised architecture governance, and ITIL-era change management will not move faster. It will move the same speed, at greater complexity and cost.

What Operating Model Redesign Actually Involves

Redesigning an operating model for a transformed technology capability involves at least four dimensions:

Funding model. Project-based funding creates incentives to deliver a defined scope and then move on. Product-based funding creates incentives to improve continuously. If your transformation is building persistent digital capabilities — platforms, APIs, data products — the funding model must support ongoing investment, not one-time delivery. This requires a conversation with finance, not just with IT.

Decision rights. Who has the authority to make architecture decisions? Who can approve a new cloud service? Who defines the standards a team must comply with? Centralised decision authority slows down autonomous teams. Fully devolved decision authority creates fragmentation and security risk. The transformation operating model needs to define where decisions are made — and it needs to be different from the pre-transformation model.

Skills and capability. A cloud-native operating model requires people who can operate in it. This is not just about training on specific tools. It requires a different engineering culture — one that assumes failure, automates everything, and uses observability to understand system behaviour rather than to audit it retrospectively. Hiring and development strategies must be aligned to the target operating model.

Governance and control. Governance does not disappear in an agile operating model — it moves from approval gates to continuous guardrails. Policy-as-code, automated compliance checking, and architectural fitness functions replace manual review boards. The governance model must be redesigned for the pace at which the new operating model moves.

Architecture's Role in Transformation

Enterprise architects often see themselves as outside the transformation programme — providing standards and direction, but not responsible for outcomes. This is wrong. Architecture and operating model are inseparable in a technology transformation.

The architecture decisions made during a transformation encode operating model assumptions. A monolithic application architecture assumes a specific team structure and deployment cadence. A microservices architecture assumes autonomous teams with end-to-end ownership. A centralised data platform assumes a specific data governance model. Every architectural choice is also an organisational choice, and architects need to be explicit about those choices and their implications.

  • Define the target operating model before selecting the technology stack, not after
  • Sequence transformation to build operating model capability before adding technical complexity
  • Treat governance as a first-class architectural concern, not a compliance afterthought
  • Measure transformation success by operating model outcomes, not technology deployment milestones

Starting in the Right Place

The most effective transformation programmes start small, deliberately. They choose a bounded domain with a willing team, design the target operating model explicitly, implement the technology to support it, and measure the outcomes — not just the delivery milestones. They treat the first implementation as a learning exercise, not a production rollout. And they use what they learn to refine the operating model design before scaling.

This is slow by the standards of big-bang transformation programmes. It is also the only approach with a meaningful success rate.

Ergotech helps organisations design transformation architectures that are honest about operating model change. Get in touch to talk about your programme.