Most operating models fail because they are designed as a picture instead of as a set of decisions. The org chart gets redrawn, but decision rights, funding, and standards stay as they were, so people drift back to old habits within months. Models that last write down who decides what, fund persistent teams, and treat the model as a running record rather than a slide.
If you have lived through a reorganization, you have probably seen this: a big launch, new names on boxes, a town hall, and then, six months later, the same escalations going to the same people. Nothing was exactly wrong. The model just never became how work actually happens.
This post explains why that happens, in five causes you can check for in your own company, and what to do about each. It uses the Leader Flow order of work: principles first (Compass), then boundaries (Atlas), then action (Arcade). Most failed models skipped the middle step.
How often do operating models and transformations actually fail?
Credible research suggests that most large transformations fall short of their goals, but the popular “70% fail” figure is not well supported. It helps to be honest about this, because a made-up number weakens an otherwise solid argument.
The “70 percent of change initiatives fail” claim is repeated constantly. Mark Hughes examined its origins in “Do 70 per cent of all organizational change initiatives really fail?” (Journal of Change Management, 2011) and found no solid empirical basis for it. It is a folk statistic.
Better-sourced evidence points the same direction, with more modest numbers:
- McKinsey (2018), surveying executives on digital transformations, found that only about 16 percent said their organization’s transformation had improved performance and equipped it to sustain changes over time.
- BCG (2020), in “Flipping the Odds of Digital Transformation Success,” reported that about 30 percent of transformations met their target value and sustained it.
- Mankins and Steele (2005), in Harvard Business Review, studied execution gaps and found companies delivered on average about 63 percent of the financial performance their strategies promised.
The pattern is consistent: most efforts underdeliver, a minority succeed durably, and the gap between plan and result is large. The next five sections cover why.
For the definition of an operating model itself, see the complete guide to operating models and what a target operating model is.
Cause 1: Why does unclear decision-making sink an operating model?
Because an operating model is, at its core, a system for deciding who decides, and when that system is vague, decisions flow back to a few senior people. Redrawn boxes do not change that.
Paul Rogers and Marcia Blenko made this point in “Who Has the D?” (Harvard Business Review, 2006), a Bain study of decision effectiveness: organizations stall not for lack of ideas but because nobody is clear who holds the decision. Roles blur, meetings multiply, and decisions get remade.
My version of the rule is blunt: an undocumented boundary is a centralized boundary. If the limits of someone’s authority are not written down, they will check with their boss, and the boss becomes the bottleneck again. The new model has been installed on paper and removed in practice.
The fix is decision rights by class, with one owner per line. Group decisions into classes, such as pricing, hiring, spending, and roadmap changes, and for each one state who decides, who must be consulted, and when it escalates. A useful test is reversibility: the easier a decision is to undo, the lower it should be decided. Write the answers down.
Hypothetical example (illustrative only): A company moves to autonomous product teams. Six months later, every pricing change still requires VP sign-off because nobody documented that product leads may change prices within a stated band. The team structure changed. The decision structure did not.
Cause 2: Why does designing the structure first backfire?
Because structure is the most visible lever and the least powerful one, and starting there skips the work that makes a structure function. Redrawing the chart feels like progress, so teams do it first and often only.
Michael Beer, Russell Eisenstat, and Bert Spector argued this in “Why Change Programs Don’t Produce Change” (Harvard Business Review, 1990). They found that the programs that worked did not start from a top-down structural announcement. They started by changing how people did their work in specific units, and formal structure came last, to lock in what already worked.
A related idea is Conway’s Law, from Melvin Conway (1968): organizations tend to produce systems that mirror their communication structures. If you reorganize the boxes without changing who actually talks to whom and who owns what outcome, the output keeps its old shape.
My shorthand: move the boxes last. First decide what you believe and what you are trying to achieve. Then set boundaries. Then arrange people. The post on functional vs. product operating models and the one on centralized vs. decentralized operating models are useful once the principles are clear, not before.
This is also the logic of Leader Flow’s order: Compass, then Atlas, then Arcade. Structure appears in the middle, as a consequence of the first layer and a container for the third.
Cause 3: Why does project funding undermine a new model?
Because projects end and teams disband, while operating models need persistent teams that own outcomes over time. If money is allocated per project, the structure you designed gets dismantled at each funding cycle.
Mik Kersten’s Project to Product (2018) makes this case for software: organizations that fund temporary projects optimize for delivering scope on schedule, not for the long-term health of the product. Teams assemble, ship, and disperse, and nobody owns what comes after.
I put it this way: the reorg is not the decision; the funding model is. If a team’s budget is renewed every quarter against a list of deliverables, the team will behave like a project crew no matter what its name says. If a team has a stable mandate, a defined set of outcomes, and a funding line that follows the mandate, it behaves like an owner.
A warning sign here is what I call a fake product or fake functional setup: teams are labeled “product” but are still funded, staffed, and measured like a service desk. The label changed. The mechanics did not. The post on the six operating models shows how real versions differ from the relabeled ones.
Hypothetical example (illustrative only): A retailer creates a “customer app” product team, but the team’s budget is approved per release and its engineers are borrowed from a shared pool each quarter. Within a year the team has no stable members, no backlog it controls, and no one accountable for app retention.
Cause 4: Why do models drift back when nobody writes them down?
Because a model that lives in slides lives in people’s memories, and memories fade, people leave, and new hires copy what they see. A model has to exist somewhere other than a launch deck.
A framework is a snapshot. An operating model needs a running record: the written decision rights, KPI definitions, OKRs, roadmaps, service levels, workflows, and onboarding materials that describe how the company works today. That record is what Atlas is for. When someone asks “who owns this?” or “what does this metric mean?”, the answer should be a document, not a hallway search.
Two quick tests show whether your model is real or only announced:
- The onboarding audit. Give a new hire your onboarding materials and ask them, after two weeks, to explain who decides what. If the answers come from colleagues instead of documents, the model is oral tradition.
- The loop-ratio test. Count how many decisions in a week required a back-and-forth with someone outside the team that owns the outcome. A high ratio means authority is not where the model says it is.
Documentation sounds dull, and it is. It is also what turns a good idea into a durable one. See the KPI and OKR pages for how these look when written down, and workflow management fundamentals for the process side.
Cause 5: Why does a model fail when strategy never reaches execution?
Because strategy is stated at the top and execution happens at the edges, and without a defined path between them the two never meet. Mankins and Steele’s 63 percent finding is largely a story of this gap: plans are sound, but they are diluted as they pass through budgeting, resourcing, and day-to-day prioritization.
Common symptoms include teams that cannot name the top three company priorities, KPIs that exist but are not tied to the strategy, and reviews that report activity instead of results. The post on how information flows in organizations explains why: information moving up and down a hierarchy gets filtered, reinterpreted, or simply lost.
The remedy is a short, explicit chain from principles to numbers to weekly work. In Leader Flow, that chain is the sequence of Compass, Atlas, and Arcade. The Arcade layer holds the rhythm that keeps the model alive: daily huddles, a regular ops review, and a roadmap. It also includes the RED loop (Research, Experimentation, Development), which gives teams a safe way to change the model as they learn.
Constraints help here. The idea in the Oulipo lesson on constraints is that clear limits create capacity instead of removing it. A team that knows its boundaries can act without asking permission.
What do failing models have in common?
They treat the model as an event and not as a system. The five causes above look different, but they share one root: someone decided that announcing a change was the same as making it.
Notice that none of the five is a design flaw in the usual sense. A model with a sensible structure, a clear vision, and capable leaders can still fail on every one of them, because the failure lives in the plumbing: who can say yes, who pays for what, and where the answer is written. That is good news. Plumbing can be fixed without a new strategy, a new CEO, or a new org chart, and the fixes are cheap compared with the cost of repeating a reorganization that did not stick.
It is also why I distrust “maturity models” that rate a company on a five-point scale. A company can score high on paper and still send every pricing question to the same executive. Test the behavior, not the self-assessment.
| Failure cause | What it looks like | What to do instead | Leader Flow layer |
|---|---|---|---|
| Unclear decision rights | Everything escalates to a few people | Write decision rights by class, one owner per line | Atlas |
| Structure first | New boxes, old behavior | Set principles and boundaries, then arrange people | Compass, then Atlas |
| Project funding | Teams form and disband per initiative | Fund persistent teams against outcomes | Atlas |
| No written record | Model lives in slides and memory | Keep a running record; run the onboarding audit | Atlas |
| Strategy-execution gap | Teams can’t name priorities | Tie KPIs and OKRs to weekly rhythm | Arcade |
How do you build an operating model that lasts?
Work in the order principles, boundaries, action, and treat the model as something you maintain rather than something you launch. A practical sequence looks like this.
- Name the binding constraint. What single thing limits your results right now: speed of decisions, quality, capacity, or alignment? Design the model around that.
- State the principles (Compass). What do you optimize for, and what will you trade away? Write it in a few sentences. When people disagree later, this is what they will argue from.
- Write the boundaries (Atlas). Decision rights, KPI definitions, OKRs, service levels, workflows, and standards. Start with the ten decisions that most often get escalated.
- Fund for ownership. Align budgets to persistent teams and outcomes, not to a list of projects.
- Run the rhythm (Arcade). Huddles, an ops review, and a roadmap. Use the RED loop to test changes before rolling them out.
- Audit regularly. Run the onboarding audit and the loop-ratio test each quarter. If the answers differ from the written model, update one or the other.
- Move the boxes last. Once the above is in place, reorganize teams to fit what is already working.
The digital operating model post and operating model frameworks explained are good companions if you want to compare approaches. The key is not which framework you pick but whether you keep it alive.
Where does Leader Atlas fit?
Atlas is the part most failing models are missing: the written, maintained record of how the company actually runs. Compass tells people why. Arcade tells them what to do this week. Atlas tells them what is allowed, who decides, and what “good” means, so that Compass and Arcade connect.
| What failed | The Atlas element that prevents it |
|---|---|
| Authority was unclear | Expectations: decision rights by class |
| Metrics meant different things | KPI definitions with one owner each |
| Goals did not connect to work | OKRs tied to roadmaps |
| New hires learned from rumor | Onboarding and fundamentals |
| Handoffs broke down | Workflows, systems, and SLAs |
Explore the full set at Atlas and the overall structure at Leader Flow.
Frequently Asked Questions
Is “70% of change fails” true? No evidence supports that exact figure. Better-sourced studies report success rates between roughly 16 and 30 percent for digital transformations, and about 63 percent value delivery for strategies, so the broad point stands without the myth.
How long does it take to know if a new operating model is working? You can test early signals in weeks: whether decisions are made at the documented level and whether new hires can answer “who decides?” from documents. Outcome measures, such as cycle time or delivery predictability, take a few quarters to show a trend.
Should we hire consultants to design the model? Outside help can speed analysis, but ownership must stay internal. If the people who run the model did not write its decision rights, they will not defend them.
What if the company is too small for documentation? Smaller companies need less documentation, not none. Even a one-page list of who decides what removes most early confusion and scales as you grow.
Where should I start tomorrow? List the ten decisions that were escalated most often last month and write down who should own each. That single page is the start of your Atlas.
TL;DR
- Most operating models fail because they change the picture, not the decisions, funding, or record.
- “70% of change fails” is unsupported; credible studies still show most transformations underdeliver.
- Five causes: unclear decision rights, structure-first design, project funding, no written record, and a strategy-execution gap.
- Fix them in order: principles (Compass), boundaries (Atlas), action (Arcade), and move the boxes last.
- Audit with the onboarding test and the loop-ratio test.
Take the Next Step
If your last reorg did not stick, do not start another one. Start with the ten most-escalated decisions and write the answers down. If you want a second set of eyes, get in touch.
About the author: Milen Vasilev builds operating models: the unglamorous machinery that makes ambitious things actually ship. He created Leader Flow, a framework that moves from principles (Compass) to boundaries (Atlas) to action (Arcade). Learn more about Milen.
Sources
- Hughes, M. (2011). “Do 70 per cent of all organizational change initiatives really fail?” Journal of Change Management, 11(4).
- McKinsey & Company (2018). “Unlocking success in digital transformations.”
- Boston Consulting Group (2020). “Flipping the Odds of Digital Transformation Success.”
- Mankins, M. & Steele, R. (2005). “Turning Great Strategy into Great Performance.” Harvard Business Review, July-August 2005.
- Rogers, P. & Blenko, M. (2006). “Who Has the D? How Clear Decision Roles Enhance Organizational Performance.” Harvard Business Review, January 2006.
- Beer, M., Eisenstat, R. & Spector, B. (1990). “Why Change Programs Don’t Produce Change.” Harvard Business Review, November-December 1990.
- Conway, M. (1968). “How Do Committees Invent?” Datamation, April 1968.
- Kersten, M. (2018). Project to Product. IT Revolution.
