Most businesses cannot afford their operating model. They just do not know it yet.
That is not a provocation for its own sake. It is the conclusion I keep arriving at after years inside complex global organisations and now working with the leaders trying to scale them. The patterns that cause operating models to fail are not rare or hard to find. They are common, recognisable, and in most organisations, unaddressed. The question is not whether they exist. It is whether the business can afford to carry them.
Thanks for reading The Operating Model Dispatch! Subscribe for free to receive new posts and support my work.
Here is the uncomfortable truth about the organisations that never fix these problems: they do not fix them because they do not have to. A multinational, multibillion dollar, high margin business does not feel the cost of operating model failure the way a scaling organisation does. The waste is real. The inefficiency is genuine. But at that level of commercial insulation, it disappears into the margin before anyone has to account for it. No single line on the P&L. No clear owner. No burning reason to act.
If that is not you, and it is not most of us, then what follows is not a cautionary tale about someone else. It is a mirror.
I spent years inside organisations at that scale. What I observed there was not the result of poor leadership or lack of investment. It was the accumulated consequence of never having had to get it right. These are the patterns I saw. They will be familiar. The difference between that organisation and yours is not the patterns themselves. It is what those patterns cost.
Fragility dressed as flexibility
The most dangerous operating model failure is the one that does not look like a failure at all.
When critical tasks have no formal process, the work still gets done. People find a way. They rely on relationships, institutional memory, and informal networks built over years. It looks, from the outside, like a culture of adaptability. It functions, day to day, like a reasonably well-run operation. What it actually is, is a system held together by individuals rather than infrastructure.
The risk is not immediately visible because the individuals are good at what they do. They know who to call, what is expected, and how to navigate the organisation. But that knowledge is not documented, not transferable, and not resilient. When the people who hold it leave, the knowledge leaves with them. When the organisation scales, the informal networks cannot stretch to cover the new complexity. When things go wrong at pace, there is no process to fall back on because there never was one.
At a business with margins thick enough to absorb the cost of rework, delays, and post-launch corrections, this is a persistent inefficiency. At a scaling organisation, it is a structural fragility that will surface at exactly the wrong moment, typically when you are under the most pressure and can least afford it.
Process absence is not flexibility. It is risk that has not yet been called.
The invisible cost of disconnected systems
The second pattern is harder to see from inside and almost impossible to cost accurately, which is precisely why it persists.
When systems are not integrated, the work does not stop. It continues, but it duplicates. Someone navigating a full value stream enters the same information in different forms across multiple systems because nothing talks to anything else. The cost of any single duplication is small. The cost across the full journey, multiplied by every person doing it, every day, is significant. It is also invisible on any individual system’s reporting, so it is invisible to the people making decisions about whether to fix it.
This is not a technology problem. It is an operating model problem that technology could solve, if the organisation had decided what it was trying to achieve and designed accordingly. Instead, systems accumulated over time, each solving a local problem, none designed with the full value stream in mind. The result is an organisation paying, in time and effort and data quality, for the absence of a design decision that was never made.
At a business of that commercial scale, the cost sits somewhere in the overhead. At a scaling organisation, it comes directly off the capacity of your best people. Every hour spent on duplication is an hour not spent on the work that actually moves the business forward.
No one can see the full picture
The third pattern is the one that makes the first two harder to fix.
When there is nowhere to see the status of work in flight across all workstreams, functions, and requirements, the organisation cannot manage what it cannot see. Portfolio decisions get made on incomplete information. Priorities are set without visibility of dependencies. Bottlenecks are discovered late, when the cost of addressing them is highest. Teams work in parallel on things that conflict without knowing they conflict.
This is described, in most organisations, as a tooling problem. It is not. It is a decision rights and coordination failure. The absence of end-to-end visibility is a symptom of an operating model that was never designed to surface it. No one was accountable for the full picture, so no one built the infrastructure to produce it. The tools came later, or did not come at all, because the organisational design did not require them.
At a business operating at that margin, this means slower decisions, higher coordination cost, and a persistent drag on execution quality. At a scaling organisation, it means you are navigating without instruments. Things do not go wrong because people are not trying. They go wrong because the information required to course-correct does not exist in a form anyone can act on.
Rigour spent in the wrong places
The fourth pattern is perhaps the most instructive because it shows that the problem is not a lack of discipline. It is discipline applied without a coherent design logic.
In the organisation I am describing, technology capacity was allocated at such a granular level that reallocating it when priorities shifted was functionally impossible. The planning rigour was real, the governance was thorough, and the result was an operating model too rigid to respond to the conditions it was supposed to serve. At the same time, requirements documentation was either non-existent or scattered across systems that could not be effectively searched. The people doing the work often did not know what “done” actually required. Gaps were caught at the end, requiring rework, or missed entirely and discovered after launch, by the commercial teams, the onboarding function, or the clients themselves.
The organisation had spent its rigour budget in the wrong place. It had over-engineered the parts that needed flexibility and under-engineered the parts that needed precision.
This is not uncommon. It is the natural result of operating model design that happens by accumulation rather than by intention. Each part of the organisation solved its own problem. No one asked how the parts fit together, where rigour was most needed, and where it was creating cost without creating value.
For an organisation that can absorb the waste, the result is missed opportunity and unnecessary overhead. For one that cannot, the rigour mismatch shows up as launches that are not ready, programmes that cannot flex, and teams that are simultaneously overloaded and underpowered.
The accountability trap
This is the most important pattern of the five, because it is the one that explains why the others persist even when the organisation knows they exist.
At some point, the organisation I am describing recognised that its processes were not working well enough. It took action. It gave a senior executive the mandate to fix cross-functional process problems across all functions. The intent was right. The design was not.
The executive tasked with fixing cross-functional problems had no cross-functional operating model, no seam-level view, and no mechanism for understanding how failures in one function were producing consequences in another. What he and his team did, reasonably and logically given the mandate they had been given, was work through each function separately: identifying problems, engaging process owners, making improvements within each boundary.
It could not fix the problem, because the problem was not inside any single function. The problems that mattered most were at the seams between functions. A functional process that was generating failures because something upstream in a different function was not providing what it needed. A definition of done that could not be enforced because accountability for it was distributed across three functions with no shared governance. These were cross-functional failures, and a single-function approach, however well-resourced and well-intentioned, cannot see them.
The organisation had created the appearance of accountability without the substance of it. It had taken action, expended resource, and reported progress, while the underlying structural failures remained intact.
This is the accountability trap: when the response to a systemic problem is assigned to a part of the system, the response is structurally limited to that part. No one is looking across the seams. No one has the mandate, the visibility, or the design authority to fix what actually needs fixing. The activity is real. The change is not.
At a business with the commercial buffer to absorb this, the result is a persistent inefficiency and a gradually eroding confidence in transformation programmes. At a scaling organisation, it is how well-intentioned change efforts fail without anyone being clearly responsible for the failure.
What this actually costs
The patterns above are not unusual. They exist, in some combination, in most complex organisations. The question is never whether they are present. It is what they cost and whether the business can afford to carry them.
A multibillion dollar business with high margins can carry them indefinitely. The cost is real: slower execution, higher overhead, post-launch failures, coordination drag, and change programmes that produce activity but not structural improvement. At that scale and that margin, none of it is existential. It is expensive and inefficient and, in most cases, tolerated.
For most organisations, the calculation is different. When margins are thinner, when capacity is tighter, when every quarter matters more than the last, the same patterns show up not as persistent inefficiency but as execution failure. Missed launches. Stalled growth. AI programmes that cannot deliver because the operating model they are being layered onto cannot support them. Teams that are working harder than they should have to and producing less than they are capable of, not because of talent or effort, but because the infrastructure they are working within was never designed to enable them.
The cost of a broken operating model is not always visible until the conditions that were absorbing it change. When margins compress, when growth plateaus, when a strategic programme demands execution quality the operating model cannot provide, the accumulated cost surfaces all at once.
The time to understand your operating model is before that moment. Not to fix everything. Not to redesign from scratch. But to know what you are carrying, what it is costing, and where the risks sit, so that you are making deliberate choices rather than discovering structural fragility at the point of maximum pressure.
You cannot redesign a foundation you have never seen.