Nearly nine in ten change programmes fall short of what they set out to do. Your AI transformation is being set up to join them, and the reason has almost nothing to do with the technology.
Look squarely at the last big change programme you ran or sat inside. Agile, most likely, or the DevOps push, or the one with the framework and the certified coaches and the reorganised standups. My read, over two decades in and around this work, is that almost all of them fell short of what their framers intended when they wrote the Manifesto, and that most of us who led them know it privately even where we defended them in public. Bain looked at 250 change programmes and found 12% achieved what they set out to do; the rest split between failing outright and settling for a shortfall they learned to call success.
Agile didn’t fail because Agile was wrong. Your AI transformation is being set up to fail for the same reason.
Agile was never a methodology, it was an organisational capability
You don’t get agility by running the ceremonies any more than you get a butterfly by pinning wings to a caterpillar. Jay Galbraith gave us the picture decades ago, and it still holds. He called it the Star Model and laid an organisation’s design out as five points pulling on one another: strategy, structure, rewards, processes and people. An organisation’s behaviour emerges from how all five are arranged together, not from any single one of them. Further, whether that behaviour is worth anything turns on whether it fits the situation the organisation is actually in. An organisation design tuned for a stable world produces orderly behaviour that is exactly wrong for a volatile one.
Software development—especially now that AIs are involved—is volatile, uncertain, complex and ambiguous, which is the VUCA the war colleges coined for exactly this kind of ground. The behaviours that pay there are adaptive. It’s true that some of the work is merely complicated rather than genuinely complex, and there an orderly design still earns its keep; but betting on the organisation staying in calm, predictable water is a bold call. Better to assume complexity and downgrade to orderly than to assume orderly and get thrashed about. The Org Topologies work Craig Larman does with Alexey Krivitsky and Roland Flemm builds straight onto the Star Model, and it treats agility as a property of the whole design, not a set of practices a team can adopt.
The first wall: what you’re allowed to touch
The thing an Agile transformation is trying to move lives in the whole organisation, and the effort is scoped to one corner. The people brought in to run the change, the coaches and the transformation office, generally only touch local processes inside product and engineering. The wall is porous, not solid: a CTO or CPO with real authority inside their own department can move some local structure, some of the people, even some of the local rewards, and a change effort they back reaches that far with them. What none of them reaches is the design of the organisation around the department, the reward system that sits above it, or the behaviour of stakeholders who never report in. For those, the change effort holds neither the remit nor the standing.
And where it does push, the system pushes back. Larman put this in his Laws of Organisational Behaviour years ago: organisations are implicitly optimised to protect the power and positions of middle managers and specialists, so any change initiative gets reduced to redefining the new terminology to mean roughly the old status quo. So the boundary works as a machine as much as a fence. Push a change through it and the change comes back out wearing the new words and the old shape. Nobody built it on purpose. It defends itself anyway, and very well.
Larman and Bas Vodde have a line for what the wall costs you: be agile, not do agile. Doing agile is the local practice a team can run inside its own boundary, the part an outside change effort is allowed to install. Being agile is a property of the whole star, and reaching it means changing the points that effort was never given the authority to touch.
The second wall: how deep you’re allowed to go
Even inside what it can touch, the effort is held at the surface. Peter Block, in Flawless Consulting, separates the content level of a consultant’s work, the frameworks and recommendations a manager can absorb without changing how they see themselves, from the affective level, where trust, power and identity actually live. Real change doesn’t happen unless the affective level shifts as well. Most consultants won’t go there, Block says, because it makes them vulnerable, and they collude with the client in pretending the organisation is a rational machine rather than a political one. Jerry Weinberg drew the same wall as a number in The Secrets of Consulting: never promise more than about 10% improvement, because 10% is the most you can deliver without threatening the client’s paradigm. The ceiling is set exactly where the discomfort would start.
Consultants and coaches get blurred together here, and they are trained for different halves of the problem. Consultants work at the content level. They bring the diagnosis, the framework, the recommendation, and most of them have neither the training nor the invitation to work at the affective level at all. Coaches are built the other way round. They are trained for the affective level, for what a person believes and fears and protects, and most of them don’t carry the technical content of how a software organisation is actually put together. The rare practitioner holds both, and getting there takes two separate educations rather than one. I went and got both, and I still meet very few people who have. But neither trade, on its own or combined, was handed the authority to change the design.
Above that wall sit the leader’s own paradigm, the mostly-unexamined model of what an organisation is and how it should work; their read of the context they are actually in, which may be years out of date; and the goals they are optimising for, which may not be the ones the situation rewards. Those three set the strategy and shape the whole star beneath them, and no content-level intervention reaches any of them. A consultant can redesign a standup. A coach can hold the room while a CEO looks at what they believe an organisation is for. Neither one can do the looking for them.
The two walls together box the effort into the smallest, lowest part of the star: local in scope, shallow in depth. The whole-system property it is chasing is a feature of the entire design and of the identity above it, not of any single point you are allowed to touch. More consulting, better consulting, another framework, and you are still inside the box.
The same trap, one rung up
I’m not the only one saying this. Stefan Wolpers, writing on the Scrum.org blog in January 2026, calls it the Agile-AI isomorphism: organisations that installed Scrum ceremonies without changing structure, culture and governance failed at Agile, and organisations installing AI tools without changing those same conditions risk failing at AI. The predictor of success, he argues, is whether the organisation genuinely changed last time or merely bought the process.
So what has the organisational response to AI been so far? IBM surveyed 2,000 CEOs early in 2026 and reported that 76% of their organisations now have a Chief AI Officer, up from 26% a year earlier. Read quickly, that looks like the authority wall coming down at last. A C-suite owner, finally.
I read it the other way, and I think the number itself gives me the grounds to. A genuine, authority-bearing executive seat doesn’t appear at three-quarters of large organisations in 12 months; that isn’t how structure changes. What can happen that fast is a title. A CTO takes the AI hat, a VP gets re-lettered, a CEO ticks “yes” on a survey run by a vendor that sells AI transformation. The evidence is in the same study. IBM reports 76% with a Chief AI Officer while only about a quarter of their people use AI regularly at work. The title has run a full lap ahead of the work.
And the work, where it runs at all, is mostly not paying its way. MIT’s NANDA initiative reviewed about 300 publicly disclosed enterprise AI initiatives through 2025, interviewed 52 organisations and surveyed 153 leaders, and found 95% showed no measurable impact on profit and loss. Take that number at the weight it can bear: the work is preliminary, it hasn’t been peer-reviewed, the sample isn’t random, and a short measurement window will under-count anything still maturing. The models were rarely the binding constraint. What failed was the integration into how the business actually works.
NANDA didn’t test authority, mandate, or the leader’s paradigm, and I’m not going to borrow certainty from their result. That reading is mine, so I went and checked it. A title or a reporting line isn’t evidence of operating-model authority unless the charter carries the decision rights to change structure, rewards and cross-functional organisation, so that is what I coded. I took 50 AI-transformation roles at 49 organisations from public postings and appointment announcements, and registered the prediction before I looked: at least 70% would be scoped to the AI function alone. That part didn’t hold. It came in at 64%, and a sample this size cannot settle the threshold either way. The other half did hold. Two roles in 50 carried written authority over structure, incentives, cross-functional design or P&L. Of the 13 reporting to a CEO or board, none did. The altitude was real; the remit was not. These are charters as written rather than authority as exercised, and 13 is a thin number, so take that last one as suggestive.
I wanted to run the same coding against the Agile era. If both eras chartered the work below the level where the design gets changed, the parallel stops being an analogy and becomes a measurement. I couldn’t do it. The coding needs the role’s reporting line, and for the Agile years that field has mostly gone from the public record. Titles survive. Remits sometimes survive. Who the job answered to is gone. So the Agile half of this stays an argument rather than a finding.
That is Larman’s Law arriving on schedule, one rung higher than the Agile PMO and wearing a better suit. What the 76% measures is how fast an organisation can announce it is Agile AI-native. Copilot is Jira with a larger budget and the same blind spot.
Worse than Agile in two ways
The 10X Org authors have a name I keep borrowing: the Ferrari Effect. Buy a fleet of Ferraris and put them on a one-lane road behind the trucks, and all you get is faster cars in the same traffic. AI dropped into a misaligned structure does exactly this. It amplifies whatever the organisation was already optimising for, so if the design was tuned for utilisation and local efficiency instead of flow and adaptiveness, AI makes you worse at the wrong thing, faster. Nothing an organisation does converts into performance except through its fit with the situation, and behaviour and culture both pay that same toll. A faster car doesn’t improve the fit. Fix the road first.
The first way is that AI doesn’t stay neutral while you misuse it. Trained on the internet’s management writing, it hands back the fashionable answer more readily than the fitting one. Researchers writing in the Harvard Business Review in early 2026 ran thousands of simulated strategy decisions through leading models and found they reliably reached for whatever matched current management language; they named the output trendslop. Agile at least failed in silence. AI fails while affirming you, in fluent and confident prose, that you are doing the right thing. The one tool you would want to expose your paradigm is the tool most likely to sell it back to you.
The second way is that AI widens the gap between a startup and an incumbent further than Agile ever could. A startup carries none of the incumbent’s inertia. It has no legacy design to defend and no paradigm to revert to, and at that size the founder simply is the structure, so no wall stands between the engineers and the design of the company. Every incumbent was a startup once. The org design grew organically after that, along the old hyper-specialisation lines, optimising for efficiency and utilisation rather than for delivering value, and each layer of that growth is now something with a constituency to defend it. The startup begins in the configuration you keep reverting away from.
In the Agile era that gap had a ceiling. A well-run startup could out-ship an incumbent and still lose, because reaching scale took people and the incumbent had them. Headcount was the incumbent’s answer to speed, and it was a good one. My read is that AI moves that exchange rate. When leverage per person rises far enough, a small organisation whose design fits its situation can reach a size that used to need a large one, and headcount stops being the answer it was. The compensating strength the incumbent was relying on is the one AI erodes first. As I write, ElevenLabs and Anysphere’s Cursor are running on a small fraction of the headcount of the classical software leaders. Some of that edge is genuinely technical: ElevenLabs trains its own speech models, and Cursor’s harness is the product rather than a wrapper on someone else’s. But comparable models reach everyone eventually, and the providers will keep building better harnesses for all of us. What no incumbent can buy from a vendor is an organisation that was never taxed by a design built for a different world.
Where I could be wrong
A good-faith explanation competes with mine. The technology is young, the data plumbing is bad, and most of the 2025 pilots were badly scoped experiments run by people learning on the job. On that reading the numbers improve on their own as the tools mature, and nobody has to touch the org chart.
If immaturity is the cause, results should climb with model capability while the design stays where it is. My prediction is that task-level speed keeps climbing and the business-level numbers stay flat, because the constraint has moved somewhere the tooling cannot reach. I would be wrong if you can show me an organisation that got a durable commercial result from AI while its structure, its rewards and its leader’s assumptions all stayed put, or a workflow redesign inside one department that moved a business number and held for eighteen months. One such case and I have to narrow this. Several and it is wrong.
Before publishing that offer I went looking myself, against four criteria fixed in advance: a realised commercial result on a P&L line rather than an adoption or task-time metric, held across four quarters, no reporting-line or incentive or new-function change in the same period, and no statement from the accountable leader describing a changed view. Eighteen public cases came close enough to code. None met all four. That is weaker evidence than it sounds. Organisations publish what changed and almost never publish that they changed nothing and it worked, so the public record is far better at showing movement than at proving stillness.
The wall you cannot delegate
The change lives at the top of the organisation, in structure and rewards, and at the deepest level of engagement, in trust and identity. Both of those are the leader’s own ground. That ground belongs to the leader, not to the coach, the transformation office, or the Chief AI Officer, whose written charter, in the 50 I coded, almost always stopped short of the operating model around the AI work. The wall you can’t pay someone to cross for you is the one that runs through your own assumptions about how the organisation should be built, and whether the goals you have been optimising for still fit the situation you are actually in.
This is also why sponsor continuity matters, but departure is a warning sign rather than a law of organisational physics. A design is exposed when its decision rights, rewards and governance still depend on the person who sponsored it; some exposed designs revert, some persist, and in many organisations the public record is too thin to tell. The practical test is whether the new design has become how the organisation governs itself before that person goes. Craig Larman has said, in the LeSS courses I have sat in, that he has never seen an Agile transformation outlast a change of leadership. I take that as a severe practitioner warning and no more, because I tried to test it and couldn’t. A first pass found reversion signals far more often after a sponsor left than when one stayed, but a properly matched replication failed its own coverage rules, and the difference it produced could have been zero. So the honest status is a risk worth auditing, not a mechanism I can show you.
Deming is supposed to have answered executives who asked him to train their people: come yourself, or send no one. Robert Kegan and Lisa Lahey give the mechanism in Immunity to Change. A paradigm becomes available to change only when it moves from something you are to something you have. Turning that on your own paradigm is the hard part, because the thing doing the looking is the thing you are trying to look at, which is why it so often takes someone outside the pattern to help you see it.
This is the argument underneath a book I have been serialising, Come Prepared to Die. I won’t rehearse it here. The short version is that the structural case and the inner one are the same case seen from two sides. The person who owns the design can’t delegate the work of examining the assumptions behind it, and no title, and certainly no model, can do that work on their behalf. For the change to outlive them, its decision rights, rewards and governance also have to become properties of the organisation rather than permissions rented from one sponsor.
The uncomfortable question
If you are standing up an AI transformation right now, ask a narrower and more uncomfortable question than which tools to buy. What is your organisation actually optimised for? Who holds the authority to change that? And does the person holding it know what you know? If the effort is once again boxed into the delivery corner and handed to someone without the remit, then you already know how it ends. You have seen this film.
Most of the people reading this are the CTO, not the CEO, and that last question is the job. You can’t redesign the company. You can do something narrower and more useful. Pick one value stream where AI is meant to pay. Baseline the commercial number it is meant to move. Then map every approval and decision right sitting between an engineer’s idea and that number changing, and notice how much of the map lies outside your department. Take it to the person who owns the design, along with one 30-day experiment that needs exactly one decision from them. Either they make it, and you have found out the design can move; or they don’t, and you have learned more about your ceiling than another quarter of pilots would have told you.
I work with engineering leaders on exactly this kind of paradigm work, the deeper the better. If it’s live for you, I’m happy to talk: schedule a 30-minute virtual coffee at hi.chrisgagne.com.
Some book links here are Amazon affiliate links; if you buy through them I may earn a small commission, at no cost to you.
Leave A Comment