A transformation has a strange shape: it is decided in a boardroom by a handful of people in an afternoon, and then delivered over two years by thousands of people who were not in the room. The gap between those two facts is where most of the value leaks away. Leading transformation at scale is the discipline of closing that gap, turning a strategy a few people believe in into a way of working everyone else actually adopts.

The quick version

  • Transformation at scale is leading a large organisation through deep change, a new strategy, operating model, technology or culture, across many teams at once, not a single project in one corner.
  • The odds are bad: research consistently finds that around 70% of transformations fall short of their goals. The usual cause is not a flawed plan but weak leadership of the change itself.
  • The key distinction is technical vs adaptive change. Technical change has a known fix you can install; adaptive change asks people to think, behave and value things differently, and that is the part that gets skipped.
  • The moves that work are unglamorous: a real reason to change now, a guiding coalition rather than a lone champion, visible early wins, and the discipline to keep going long after the launch buzz fades.

The idea in depth: why scale is the hard part

The headline number is sobering and worth stating plainly. Academic research that McKinsey draws on finds that when organisations launch a transformation to improve performance, roughly 70% fall short of their goals (see McKinsey's "Why do most transformations fail? A conversation with Harry Robinson"). The 70% figure is widely repeated and the precise number shifts with how you define "failure," so treat it as a direction of travel rather than a measured constant, but the direction is unambiguous. Most large change efforts disappoint.

Why? Robinson's account is refreshingly free of mystique. The recurring causes are leadership ones: the person at the top doesn't set a high enough aspiration or build genuine conviction in the team; the capabilities to actually deliver the change sit with people who still have "day jobs" and never get freed up; and the dull machinery of change, an owner, a cadence of oversight, a way to track whether anything is moving, is never put in place. None of these is a strategy error. They are all failures to lead the change as a distinct task.

So the move is to treat "what should change" and "getting people to change" as two separate jobs, and to staff the second one properly. The strategy deck is the easy half. Before launch, answer three blunt questions: who personally owns this transformation as their primary job, not a side-of-desk add-on; who needs to be freed from their day role to deliver it; and what regular meeting will surface the truth about whether it is working. If you cannot answer all three, you have a plan, not a transformation.

Technical change you can install; adaptive change you have to lead

The most useful lens for why scale defeats leaders comes from Ronald Heifetz and Marty Linsky's work on adaptive leadership (set out in Leadership on the Line, 2002, and The Practice of Adaptive Leadership, 2009). They split problems into two kinds. Technical problems have a known solution that existing expertise can apply, a new payroll system, a reorganised reporting line, a migrated database. Adaptive challenges have no agreed answer; they require people to change beliefs, habits and ways of working, often surrendering something they value. Heifetz's sharpest claim is that the most common leadership failure is treating an adaptive challenge as if it were a technical one.

This is exactly the trap at scale. A transformation is sold as technical, buy the platform, redraw the org chart, publish the new operating model, when the value actually depends on adaptive change: salespeople trusting a new process, managers giving up control they enjoyed, teams learning to collaborate across lines that used to be walls. The technical parts get delivered on time and the transformation still fails, because nobody led the harder, slower work of shifting how people actually behave.

flowchart TD
  A(["A change effort"]) --> B{"Known solution
existing experts can apply?"}
  B -->|"Yes"| C(["Technical work
install it, manage the project"])
  B -->|"No, people must
think & behave differently"| D(["Adaptive work
lead it: surface loss, build new habits"])
  C --> E(["Quick to deliver,
easy to underestimate the rest"])
  D --> F(["Slow, uncomfortable,
and where transformations stick or fail"])
Heifetz & Linsky's distinction: most transformations are sold as technical but stand or fall on the adaptive work. Leaders Loop

So the move is to sort your transformation's components into the two piles before you start, and resource them differently. The technical pile gets a project plan and a delivery date. The adaptive pile gets something the project plan can't supply: time, repeated conversation, leaders who model the new behaviour first, and honesty about what people are being asked to give up. If your whole programme plan is technical milestones, you have quietly bet that the adaptive change will happen by itself. It won't.

An honest limitation. The technical/adaptive split is a lens, not a measurement, real changes are usually a blend, and people will argue about which pile a given component belongs in. The framework also tells you that adaptive work is hard, not exactly how to do it in your context. Use it to interrogate your plan ("where have we assumed people will just adapt?"), not as a recipe that does the leading for you.

The sequence: urgency, coalition, and wins you can see

If the adaptive insight tells you what is hard, John Kotter's work tells you in what order to attack it. His "Leading Change: Why Transformation Efforts Fail" (Harvard Business Review, 1995), drawn from a decade studying more than 100 companies attempting transformation, distilled the wreckage into eight common errors, and the order matters. The first three are the ones leaders most often skip at scale: failing to establish real urgency, failing to build a powerful enough guiding coalition, and failing to create and communicate a clear vision. His most quoted warning is that skipping steps "creates only an illusion of speed and never produces a satisfying result."

Skipping steps creates only the illusion of speed, and never a satisfying result. John Kotter, HBR (1995)

Two of Kotter's points carry most of the weight at scale. The first is the guiding coalition: change of this size cannot ride on one charismatic leader, because no single person has the reach, credibility or stamina to move a whole organisation. The second is short-term wins, visible, unambiguous results within the first six to twelve months, because a transformation that shows nothing for two years loses its believers before it can deliver. So the move is concrete: assemble a coalition that crosses functions and levels and includes people the rank-and-file actually trust, then deliberately engineer one or two early, real wins and publicise them loudly. Not fake wins, those poison credibility, but genuine ones you planned for precisely because momentum is a resource you have to manufacture.

flowchart LR
  A(["Establish
real urgency"]) --> B(["Build a guiding
coalition (not one hero)"])
  B --> C(["Set & communicate
a clear vision"])
  C --> D(["Engineer visible
short-term wins"])
  D --> E(["Consolidate gains,
keep going"])
  E --> F(["Anchor it in
the culture"])
The early steps Kotter found leaders most often skip, and skipping them is what stalls change at scale. Leaders Loop, after Kotter (1995)

A worked example

Take a mid-sized insurer, call it Meridian, moving from regional branches to a single national operating model. (Illustrative figures throughout; this is a teaching example, not a real company.) The board signs off a two-year programme: one shared claims platform, consolidated back offices, an expected saving of, say, an illustrative £18m a year. On paper it is a technology-and-org project, so it is run as one, a programme office, a Gantt chart, a platform go-live date.

Twelve months in, the platform is live and on budget, and the transformation is failing anyway. Branch managers, who used to own their numbers, are quietly routing work the old way; claims handlers don't trust the national queue; nobody believes the regions are really going. Meridian fell into Heifetz's trap: it delivered the technical change flawlessly and never led the adaptive one. Worse, in Kotter's terms it had no real coalition, just a programme director with no standing among branch managers, and no visible win, only a platform most staff experienced as extra work.

flowchart TD
  A(["Board signs national model
~£18m/yr target (illustrative)"]) --> B(["Run as a tech & org project:
platform, Gantt, go-live"])
  B --> C{"Platform live on time,
but is anyone working differently?"}
  C -->|"No, branches route
work the old way"| D(["Adaptive work was never led:
no coalition, no visible win"])
  D --> E(["Reset: branch-manager coalition,
one region proven, results published"])
  E --> F(["Adoption follows proof,
savings start to land"])
Meridian delivered the technical change and stalled on the adaptive one, until it led the change as a separate job. Leaders Loop

The reset is unglamorous and it works. The CEO recruits three respected branch managers into a guiding coalition and gives them real say in how the national model runs. Rather than switch every region at once, Meridian proves it in one region first, fixes what breaks, and publishes the result: claims settled faster, managers' workloads lighter, not heavier. That visible win, one region demonstrably better off, does what no platform go-live could: it gives the other branches a reason to adopt rather than resist. The savings start landing in year two not because the technology improved, but because someone finally led the part of the change that lived in people's habits.

Frequently asked questions

What actually counts as a "transformation," versus just a big project?

A project delivers a defined output, a system, a building, a reorganised team, and then ends. A transformation changes how the organisation operates across many teams at once, and isn't done until people work differently and stay that way. The tell is adaptive content: if success depends on lots of people changing beliefs and habits, not just on something being installed, you are leading a transformation, and it needs more than a project plan.

Is the 70% failure rate real, or just a scary statistic people repeat?

It is genuinely well-worn, McKinsey and others cite figures around 70%, but the exact number depends entirely on how you define failure, over what time, and for which kind of change. Treat it as a well-evidenced direction (most large change disappoints) rather than a precise law. The useful takeaway isn't the digit; it's why, the failures cluster around weak leadership of the change, not bad strategy.

Do I need a charismatic leader at the top to pull this off?

No, and relying on one is a known failure mode. Kotter's research is explicit that change at scale needs a guiding coalition: a group with enough power, credibility and reach across the organisation that the effort doesn't collapse when one person is busy, doubted or gone. A single champion can start a transformation; only a coalition sustains one through the long, unglamorous middle.

How do I keep momentum when results take two years?

By manufacturing earlier proof. Kotter calls these short-term wins: real, visible results within the first six to twelve months that show the change is working. Plan them deliberately, pick a slice of the transformation that can demonstrably pay off early, deliver it, and publicise it honestly. Momentum at scale is not a mood you hope for; it is an output you engineer, win by win.

What's the single most common mistake?

Treating an adaptive challenge as a technical one, installing the system, redrawing the org chart, declaring victory, and never leading the slower work of getting people to behave differently. The technical parts get delivered on time, everyone feels productive, and the transformation quietly fails because the human change it depended on was nobody's job.

Related in the Toolkit

Leading transformation at scale sits on top of almost everything else in change work, the structured methods that give it a backbone (change models) and the day-to-day craft of managing resistance and driving adoption are where the abstract idea becomes the daily job.

Where to go next