Part One: The problem we keep not solving

Chapter 1: The operating model that disappoints

"Every system is perfectly designed to get the results it gets." Paul Batalden.

The story in the opening chapter is not unusual. Change the institution, sector, and decade, and the pattern repeats. A new operating model is commissioned. Significant effort goes into the design. The announcement is made. And within a year, sometimes less, the gap between the model on paper and the organisation in motion is visible to almost everyone inside it.

The pattern appears across public services and financial institutions, technology companies and healthcare systems, global enterprises and mid-sized organisations trying to grow. The specifics differ, but the arc is the same: design, announce, drift.

The scale of the problem is not disputed. Two thirds of large organisations have redesigned their operating models in the past two years, and by McKinsey's own measure, more than one in three of those redesigns still fail to meet most of their objectives, a figure that has barely shifted despite significant investment in understanding what good redesign looks like. Deloitte's research on digital transformation finds similar patterns: the choices that most reliably predict success are not structural. They are about team composition, relationship quality, and internal capability: the human conditions that formal design consistently underestimates.

The people involved are rarely the problem. The leaders who commission operating model work are not, in general, naive or incompetent. The practitioners who design it are not careless. The people asked to work within it are not resistant for the sake of it and yet the outcome keeps disappointing in ways that are hard to explain and harder to fix.

The standard explanations are familiar. Poor change management. Lack of leadership sponsorship. Culture that resists change. Insufficient communication. These explanations are not entirely wrong; any of them can accelerate a failure that was already underway. But they are not the root cause and treating them as such produces the next round of the same disappointment.

The cost accumulates, and not just in money; though the financial cost of repeated transformation cycles is significant, it is also in the erosion of trust. Organisations that have been through multiple redesigns develop a particular kind of cynicism. People learn to wait it out, the practitioners who do this work start to lose faith in their own arguments, and the leaders who commission it commission it again anyway, because the alternative, doing nothing, feels worse than the prospect of another disappointing result.

Something more fundamental is going wrong.

Before identifying what it is, it is worth being precise about what keeps going wrong, because there are three distinct failure modes, and they are not the same thing.

The first is the most visible. The operating model gets built, the change is implemented, and the outcomes disappoint. The new structure produces the same dynamics in new boxes. The capability framework sits in a document nobody references. The value streams are drawn, but the value does not flow. This is the failure most organisations recognise, and most research tries to explain.

The second happens earlier, and is less often recognised. Even when the design intent is right, the execution gets captured. Capability build rapidly becomes a technology programme. Value delivery gets lost in an industry of process redesign. Design principles are forgotten under delivery pressure. The link to strategy dissolves. The organisation's existing logic reasserts itself and absorbs the change programme into whatever it was already doing. By the time anyone notices, the programme has become something different from what it set out to be, and the people running it often know it, without quite being able to say so.

The third happens earlier still. The design itself is aimed at the wrong thing. The operating model specifies the formal layer (structure, process, governance, accountability) and leaves out the conditions that determine whether the formal layer functions. Not through oversight or incompetence, but because the formal layer is what architecture has always designed, and the conditions underneath it have never quite been treated as a design object.

These three failure modes are connected. The third produces the second. The second produces the first. The disappointment that is most visible, the operating model that drifts, is the downstream consequence of a design problem that was present from the start.

This book is focused on the third failure mode.

Not because the other two don't matter, they do, but because fixing the third changes the other two. An operating model aimed at the right design object is one that can be executed with a different logic, and that produces outcomes the formal model alone never could.

The operating model, as it is typically drawn, is a representation of how an organisation intends to work. It captures capabilities: what the organisation needs to be able to do. Value streams: how work flows from intention to outcome. Structure: who is accountable for what. Governance: how decisions are made and how performance is measured.

These are real and necessary things. An organisation without clarity on any of them will struggle, and the operating model is not wrong to include them.

What it does not include, what it has almost never included, is an account of the conditions that determine whether any of it works once it meets people.

People do not read operating models and change their behaviour accordingly. They read the signals around them: what their manager pays attention to, what gets rewarded, what gets ignored, what happens to people who raise uncomfortable truths, and they adapt to those signals. The operating model tells them what the organisation says it values. The signals around them tell them what the organisation values. When those two things diverge, the signals win.

The NHS National Programme for IT is one of the clearest examples available. Launched in 2003, it was technically ambitious and, in its own terms, coherent: common platforms, shared standards, integrated patient records across the whole of England. The architecture made sense. The investment was substantial. The intent was to improve care.

What it did not account for was the clinical and organisational ecosystem into which it was being released. Clinicians had not been involved in shaping it. Local teams, who understood their workflows and their patients, felt that something was being done to them rather than with them. The signals the programme sent were about compliance and standardisation, not about improving the work people were already trying to do. The informal networks through which clinical communities would have needed to adopt and adapt the technology were not engaged. And so, the technology met the organisation's existing adaptive logic, which treated it as an imposition, and the adoption failed in ways that the formal project plan had not anticipated and could not explain.

The programme was not brought down by bad architecture. It was brought down by conditions beneath the architecture that the architecture had never addressed.

This is not a new observation. People who study organisations have been making versions of it for decades. Less developed is the practical implication: if the signals determine behaviour, and they are not produced by the formal model, but by something beneath it, then …

… the formal model is not the right design object.

We have been designing the wrong thing.

You can stop reading here if you want; that’s it.

We’ve not been designing it badly or carelessly. We have employed significant effort and intent, but all aimed at a layer that adapts around whatever is placed on top of it, while the layer that determines behaviour remains undesigned and untended.

The rest of this part of the book explains what that layer is, why it keeps getting left out, and what it would mean to design it instead.

A moment to pause

For the rest of this book, each chapter will end with thoughts for those in the system, leaders, and those working to change. Here's the first batch.

If you are living inside this system, the pattern described in this chapter is probably familiar. You have seen the operating model drift, the transformation becomes something else, and the outcomes fall short of what was promised. You may have concluded that this is just how it is. This book argues that it doesn't have to be, and that the reason it keeps happening is specific and addressable.

If you are leading, the cost described here is not just financial. It is the erosion of trust: in the work, in the people who do it, and in the leaders who commission it. The leaders who break that cycle are not the ones who design better models. They are the ones who ask a different question before the model is commissioned. That question is what the rest of this book is about.

If you are working to change this, the cynicism that builds in organisations that have been through multiple redesigns is not irrational. It is a rational response to a pattern that keeps repeating. Describing the pattern clearly, and explaining why it repeats, is the first step toward changing it.