What holds when the framework doesn’t

Most organizational transformations don’t end with a dramatic collapse. They end quietly: a project that slowly loses steam, a rollout that technically completes but never takes hold, a technology deployment that works as designed and changes nothing.

The failure rate for large-scale organizational change has hovered around 70 percent for decades. That number has survived Six Sigma, agile, lean, every iteration of change management certification and an entire industry of consulting frameworks built to fix it. The number hasn’t moved, and that persistence is worth taking seriously.

The Problem Isn’t Knowledge

Leaders who run failing transformations can usually name the failure patterns. Ask them in private, after the fact, and they’ll tell you: the strategy was too vague, the incentives were misaligned, the technology was deployed before the organization was ready, the early momentum didn’t hold.

They knew. The failure happened anyway.

This is the question this body of work is built to answer: If leaders can diagnose the problem, why does the problem keep happening?

The answer isn’t incompetence or bad intentions. It’s structure. The conditions that produce transformation failure are baked into how large organizations work: how accountability is assigned, how careers are built, how short-term signals crowd out long-term design. Leaders operating inside those conditions make individually rational choices that produce collectively predictable failure.

Understanding that mechanism, not just the symptoms, is what changes the outcome.

What You’ll Find Here

This site publishes a series of practitioner frameworks on organizational transformation: why it fails, what holds underneath the failure and what to do structurally before a major change launches.

The work is grounded in two things that most transformation literature skips.

The first is survivorship bias. Most frameworks study winners. They reverse-engineer what successful transformations had in common. That’s useful, but it misses the planes that didn’t come back. This series is built on the structural conditions that cause the crash before anyone calls it a crash.

The second is mechanism-level analysis. Naming what went wrong is useful. Understanding why the mechanism that produced it exists, and why smart experienced leaders reproduce it, is what lets you actually change the outcome. Symptom-level diagnosis produces symptom-level intervention. That’s why the 70 percent number doesn’t move.

The Framework

The core intellectual framework here has two layers.

The Five Breakpoints are five predictable failure patterns that appear in large-scale organizational transformations, regardless of industry or change type. Not every transformation hits all five, but most hit at least three. They are:

1. Strategic Disconnection. Vague purpose producing the illusion of alignment. Teams diverge without knowing they’ve diverged.

2. Incentive Fragmentation. Misaligned incentives surface when tradeoffs appear. What looked like support becomes latent opposition.

3. Process Friction. Structural friction blocks execution. Skilled people inside broken handoffs produce slow, fragmented results.

4. The Technology Illusion. Deploying technology on broken organizational conditions. The tool works; the system around it doesn’t.

5. The Momentum Mirage. Activity continues; movement toward outcome does not. The organization keeps reporting progress while momentum bleeds out.

The Four Forces are the underlying conditions that must be actively sustained for transformation to hold: Purpose, Commitment, Capability and Momentum. Each breakpoint is a symptom. Each force is what’s actually eroding underneath it.

The critical insight is that these forces don’t sustain themselves. Each requires an active stewardship function, someone whose explicit job is to maintain the condition, not just launch the initiative. Most organizations launch well and steward poorly. That’s where the 70 percent lives.

The Series

The work publishes as a six-paper series. Each paper holds a different lens on the same underlying problem.

Paper 1: The Five Breakpoints The diagnostic map. Five failure patterns, what they look like in practice and why they’re predictable rather than exceptional.

Paper 2: The Stewardship Gap Why each force requires an active owner, and what happens when stewardship is assumed rather than assigned. The structural gap between launching a transformation and sustaining one.

Paper 3: Designed to Stall Why the 70 percent failure rate is a structural feature, not a knowledge gap. The three forces that rationally push design work off the plate, and six mechanisms that can shift leader behavior at scale.

Paper 4: The AI Mirror The AI dimension. AI doesn’t change the core dynamic; it compresses the timeline. Organizations with unstewarded forces fail faster and more visibly when AI is in the system.

Paper 5: Before It Breaks The prescriptive layer. Seven disciplines organized across three phases, Anchor, Build, Sustain, for leaders who want to design for success rather than diagnose failure after the fact.

Paper 6: The Leader the Work Requires The question the rest of the series couldn’t reach: what the leader actually believes about the people they lead, and whether they will act on it when it costs something.

Who This Is For

If you’re leading a large-scale organizational change, managing through one, or trying to survive one, this work is for you. That covers technology deployments, restructurings, strategic pivots and cultural shifts.

That includes:

• Leaders and executives who are accountable for transformation outcomes and want to understand the structural conditions behind success and failure, not just the tactical checklist

• Change practitioners and consultants who work inside these systems and want a more rigorous diagnostic lens than most frameworks provide

• Managers and team leaders who are on the receiving end of transformation and want to understand why it so often feels broken, and what the people above them should be doing differently

• Anyone who has watched a well-intentioned initiative slowly run out of steam and wondered whether there was something structural behind it

The frameworks here are practitioner-grade. They’re designed to be used in real organizations, not just read about.

A Note on Perspective

This work is grounded in lived experience across multiple large-scale transformations in manufacturing, enterprise technology, cloud infrastructure and healthcare, combined with a rigorous synthesis of what the research actually shows rather than the conference-circuit version of it.

Where the data is verified, it’s cited specifically. Where a claim is a judgment call, it’s labeled as such. That’s a commitment, not just a disclaimer.

Start Here

New to the site? The best entry point is Paper 1: The Five Breakpoints, the diagnostic foundation everything else builds on.

If you’re already past diagnosis and looking for the prescriptive answer, go directly to Paper 5: Before It Breaks.

If you’re specifically grappling with the AI dimension, how agentic AI interacts with organizational conditions, Paper 4 is your starting point.

Everything connects. Every paper also stands alone.

Start with Paper 1 →

Work That Holds publishes practitioner frameworks on organizational transformation: why it fails, what holds underneath the failure and what leaders can do structurally before it breaks.

Most leaders approach a job search as a sales process. They prepare their answers. They anticipate the tough questions. They make the best case for themselves.

What they skip is running the same rigor on the other side of the table. That gap costs most of them the next two to three years.

The pattern is consistent enough to name. A senior leader gets hired into a role with a clear mandate: modernize the function, build the capability, change how the team operates. The title is right. The compensation is right. The leadership team is articulate about what they want. Six months in, the leader starts feeling the familiar friction. Processes that were supposed to change haven’t. Peers who said they were aligned behave as though they weren’t. The mandate that seemed supported at the offer stage is, in practice, optional. By month eighteen, the leader is either pushing against organizational antibodies every day or has quietly adapted to the structure they were hired to change.

A diagnostic that was never run. The signals were present in the interview, and most leaders are not taught to look for them.

Why the Standard Interview Misses the Real Question

A standard job interview answers two questions: does this person have the skills the role requires, and do they fit the culture of this organization?

Neither question is the one that determines whether a senior leader succeeds.

The question that determines success is structural: does this organization have the conditions required for the work to hold? Not the stated appetite for change, the actual conditions. Leadership alignment on what success looks like. Incentive structures that reward the motion being built. Processes capable of absorbing a new way of operating. Accountability structures with enough authority to act.

When those conditions are present, a good leader in the right role produces durable results. When they are absent, the most skilled leader in the world will produce visible activity and structural stagnation, and eventually leave, or be managed out, or adapt into the organization they were hired to change.

The interview is your only opportunity to audit those conditions before you accept. Most leaders don’t use it that way.

What You Are Actually Screening For

You are not looking for a perfect organization. Perfect organizations do not need senior leaders with change mandates.

You are screening for structural openness: whether this organization has the conditions that give the experiment a genuine chance. Three characteristics are observable before you accept.

They have a real inflection point. Something happened: new ownership, a competitive threat they cannot ignore, a founding leader who has seen the failure mode firsthand. Real inflection has a specific forcing function. Performed change has a transformation narrative and no named event that made this the right time.

Leadership can name what they got wrong. Not their team. Not market conditions. Theirs. Leaders who can describe a decision they made that didn’t work, explain why they made it, and name what changed in their thinking are capable of updating. Leaders who describe every prior failure as an external event are telling you their model is fixed.

The incentive structure and the stated vision point in the same direction. Not approximately. Actually. Before you accept any offer, you need to know what the measurement apparatus actually rewards, not what the values statement says. The gap between them is the single most reliable predictor of where your mandate will erode.

The Five Questions That Reveal Structural Openness

The Five Breakpoints framework maps to the questions you need answered before accepting an offer. You are not doing a theoretical exercise. You are running your own framework on the organization that wants to hire you.

1. Strategic Disconnection: Does leadership actually agree on what this role is for?

The most common hiring failure in senior roles is fragmentation, not misrepresentation. The CEO says one thing. The CRO says another. The CPO has a third interpretation. The leader who accepts an offer without surfacing that fragmentation will spend the first year discovering it through execution.

Ask directly: “What does success in this role look like at eighteen months, not the activity metrics, the actual organizational outcome?” Then ask the same question to different people in the process. If the answers don’t match, the fragmentation is real.

2. Incentive Fragmentation: Do the incentive structures support the motion you would be building?

The most sophisticated interviewers in the world can describe a vision they do not actually fund, staff or measure. Commitment shows up in what the organization measures, what it rewards, and what it tolerates when priorities collide, not in a kickoff speech.

Ask directly: “How are people in this function currently measured? What behavior does that produce?” Then: “If I redesigned how this team operates, what would need to change about how they are evaluated?” A leadership team that can describe the gap between their current incentive structure and the behavior they want, and that has thought about how to close it, is operationally serious about the change. A leadership team that defends the current measurement apparatus without examining it has already told you the transformation is optional.

3. Process Friction: Is the organizational machinery capable of operating differently?

The most common capability gap in senior change roles is not skill but organizational machinery. The workflows, approval chains, handoff structures and operating rhythms that surround your function were built for the motion that exists, not the motion you are being hired to build.

Ask directly: “Tell me about the last time this team changed how it operates. What happened?” A leadership team that can name a specific process they changed, describe what it took, and be honest about what was hard to move is organizationally capable of change. A leadership team that describes everything as working, or says “we move fast” without being able to name a single thing they sped up, is describing an organization whose processes are defended rather than managed.

4. The Technology Illusion: Is this a structural change, or a personnel change?

One of the most common mistakes in senior hiring is treating a new leader as the solution to a problem that is actually organizational. This is the same mistake organizations make with technology: they buy a tool as a substitute for the structural work that determines whether the tool produces value. The same logic applies here. The organization is making a personnel investment and hoping the investment performs around the problem. The work of auditing structural readiness still has to happen, and if the organization hasn’t done it, you are inheriting it.

That pattern shows up in a specific way. The organization has tried to build a capability before, it didn’t hold, and the diagnosis in the room is that the right person wasn’t in the role. Your diagnosis, before you accept, is whether the root cause of prior failure is structural and unaddressed, or whether it was genuinely execution.

Ask directly: “What has the organization tried before to address what this role is meant to solve? What happened?” A leadership team that can name prior attempts, describe why they didn’t hold, and show a clear read on whether the failure was execution, model or structural has done the diagnostic work. A leadership team that describes this role as the solution to a problem that has existed for years, with no theory of why prior approaches failed, is about to hand you a structural problem and evaluate you on whether you can solve it with superior effort.

5. Accountability Structures: Does the person above you have the authority to protect the motion?

The most underrated question in a senior hire. Your mandate is only as real as the authority of the person who owns it. If your hiring manager cannot shield the work from organizational antibodies, if the function above them does not believe in what you are building, or if cross-functional conflicts get resolved by whoever has the most organizational power at a given moment, your execution will be consumed by internal navigation rather than the work.

Ask directly: “If I identified a structural problem in how we engage customers, something that required changing how another function operates, who has the authority to act on that?” The answer reveals whether accountability is real or distributed into nobody’s ownership. “We work collaboratively” tells you accountability is shared, which means it belongs to no one.

The Walk-Away Conditions

These are not yellow flags. These are the conditions under which you do not accept an offer, regardless of compensation, title or the quality of the vision being described.

The stated mandate and the actual incentive structure point in different directions. The incentive structure wins every time a priority conflict arrives. You will not change it from inside the role you are being hired for.

Leadership narrates only wins. An organization that cannot talk honestly about its own failures does not have the psychological safety transformation work requires. Your job will be to deliver inside the approved narrative rather than to change what it describes.

No one can describe what would need to be true for you to succeed. The conditions either exist, or they don’t, or leadership has a plan to build them. Vagueness on this question means the thinking hasn’t been done. You are not a mystery hire who will figure it out.

The hiring manager does not have the authority to protect the motion. Confirm the authority structure before accepting. A title does not confer authority. The org chart reveals it.

The organization has tried this before and the root cause of failure is still present. Prior failure is not disqualifying; it is often evidence of genuine learning. The condition to screen against is an unaddressed structural cause, the wrong incentive structure, the unaligned executive, the process that was never redesigned, that leadership does not know is still active. You will encounter it approximately six months after you accept.

Running the Audit

The goal of this framework is not to disqualify organizations on first contact. Most organizations worth joining have some version of every one of these gaps. The question is whether leadership is aware of them, honest about them, and willing to work on them alongside you.

A leadership team that says “our incentive structure doesn’t fully support what we’re describing yet, here is our thinking on how to close that gap” is telling you something far more useful than a leadership team that says everything is aligned. The first team has done the diagnostic work. The second has not, or is not being honest about what it found.

Use the first substantive conversation to start the audit. The goal is not to interrogate, but to listen for what the answers reveal. The behavioral signals, how leaders talk about their own failures, what their measurement apparatus actually rewards, whether there is a real forcing function or a performed one, are observable in normal conversation once you know what you are listening for.

The leaders who run this audit before they accept spend their energy on the work rather than on discovering, six months in, that the conditions for the work were never actually in place. That is the difference between a transformation that holds and one that merely looks like it does.

Between 65% and 75% of new products or services miss their revenue or profit goals.[1] In consumer packaged goods alone, roughly 40% of new SKUs have disappeared from shelves within two years of launch.[2] The product team shipped. The launch event happened. The press release went out. The dashboard showed green. The outcome didn’t follow.

The same pattern shows up in large-scale organizational change. McKinsey’s research found that 80% of executives described their transformation investments as successful, while only 38% reported meaningful ROI from the same investments.[3] The Standish Group has tracked project failure rates for thirty years.[4] The number hasn’t moved. Organizations announce transformations, stand up steering committees, publish progress updates, and close initiatives as complete. The outcome often doesn’t follow there either.

And in technology: Gartner’s 2024 survey of more than 3,100 CIOs found that fewer than half of all digital initiatives meet or exceed their intended business outcome targets, after all the planning, the investment, the rollout and the go-live celebration.[5]

Three different domains. Three different sets of researchers. Three different definitions of success. And in each one, the same structural gap: the moment of completion is rewarded as the goal, while the intended outcome remains largely unmeasured, or measured too late to act on.

This paper is about why that gap exists and what it actually costs.

The strategy no one names

Every organization running a structural gap between activity and outcome is making a choice, even when it doesn’t feel like one. The choice: launch more initiatives to cover the gap, rather than ask what’s creating the gap. Add more resources to cover an adoption rate that hasn’t moved. Run more programs to maintain the appearance of transformation momentum.

That is “good enough” as a strategy. It optimizes for short-term measurable output at the cost of long-term structural performance. And the moment it becomes visible as a choice is always the same: it’s the planning conversation where someone asks whether to add more activity or investigate why the activity isn’t producing results, and the room decides, usually without saying so out loud, that more activity is safer than the question.

It succeeds at the wrong thing while accumulating a cost those metrics were never designed to find.

This isn’t an irrational choice. It’s the rational output of a system designed to reward it.

Wald’s problem

In 1943, Abraham Wald was asked by the U.S. military to analyze bullet hole patterns on aircraft returning from combat. The military’s instinct was to reinforce the areas showing the most damage. Wald’s contribution was pointing out the error: the planes they were analyzing had returned. The holes showed where a plane could be hit and survive. The signal they needed was in the planes that never came back. Those planes weren’t in the sample.

This is the precise structure of the “good enough” problem.

Organizations that accept a structural gap between activity and outcome analyze individual failures. They have retrospectives, they identify why specific efforts fell short and they adjust the next one accordingly. What they often don’t do, and what Wald’s insight names precisely, is ask what structural conditions are generating most of their efforts as failures in the first place. The military wasn’t ignoring the bullet holes. They were studying the wrong planes. The roughly 80% of AI and machine learning projects that never reach meaningful production are not generating post-mortems on the structural decisions made at launch.[6] The transformation initiatives that stalled quietly are recorded as “execution challenges,” not as evidence that the conditions were wrong from the start.

The losses carry the signal. The returning planes confirm what already works. The planes that didn’t come back are telling you where the system is actually broken. And they are the one data source the organization was built to not require.

Where the cost accumulates

The costs don’t appear in the dashboard showing green because of a structural timing problem: the feedback gap between the decision that causes failure and the moment that failure becomes visible often can run for years.

The people on the receiving end of initiatives that didn’t deliver remember. Employees who were asked to change how they work, given inadequate support, and then watched the initiative quietly dissolve remember. Partners, customers and stakeholders who were promised outcomes that didn’t materialize remember. That memory doesn’t show up in the program dashboard. It shows up eighteen months later as a change initiative that can’t get traction because trust was spent on the last one, or a talented person who stops raising their hand because nothing came of it the last time they did.

More activity layered on top of structural conditions that haven’t changed is not a growth strategy. It is a treadmill. And the pace accelerates as the organization’s capacity for genuine change erodes under the weight of everything that looked like change but wasn’t.

The organizations that figure this out do not do it by finding more efficient ways to run the same motion. They do it by asking a different question: what are the losses telling us that the wins cannot?

Four questions

Before reading the next section, answer these honestly:

1. What is your current success rate, and when did you last ask why it is that number instead of higher?

2. Of your last ten major deployments or initiatives, how many produced measurable outcomes twelve months after launch?

3. When your team says “we’re being practical,” what specifically are they protecting themselves from having to change?

4. Can you name what your failures are telling you about the conditions generating them, or have you built a system that doesn’t require you to know?

An organization running a genuine “good enough” strategy will feel the absence of an answer to that fourth question more than any of the others.

The compounding alternative

This is not an argument about individual capability. It is an argument about what the system asks of the people inside it. The same person performs differently depending on what the structure around them is designed to reward and designed to ignore.

In 2005, Salesforce was growing and losing customers. Not dramatically, but at a rate quietly undermining the economics of a subscription business still proving out its model. The leadership team asked a question most software companies weren’t asking: what happens after a customer commits, and who in the organization owns what they actually experience? The answer was to create the customer success function: a named, staffed, measured capability dedicated to ensuring customers achieved the outcomes they purchased. The measure of success shifted from transactions completed to results delivered.

That structural decision compounded over years. Retention rates climbed well above industry averages. Existing customers expanded faster than others churned. The organization’s relationship with its customers changed because the structure changed, not because the people improved, but because what the system asked of them did. By 2010, the model had become a design standard the rest of the industry was trying to replicate.

Salesforce did not hire better people than its competitors. It built a different structure, anchored to a different definition of success, and had the discipline to ask what the organizations that weren’t coming back were trying to tell them.

The question is not whether your team is working hard. The question is whether the system they’re working inside is designed to learn from what isn’t working, or only from what is.

“Good enough” isn’t the floor of acceptable performance. It’s a ceiling. The organizations that sustain change, develop talent and build real capability at scale are not the ones that ran more volume. They are the ones that treated their loss rate as a diagnostic signal rather than a fixed cost, built the structural capability to address what that signal said and redesigned the conditions generating losses rather than covering them.

Notes

[1] Madhavan Ramanujam and Georg Tacke. “Your New Hit Product Might Be Underpriced.” Harvard Business Review, May 2016. Between 65% and 75% of new products or services miss revenue or profit goals.

[2] Kupor, D., Tormala, Z. L., and Norton, M. I. “How Common Is New Product Failure and When Does It Vary?” Marketing Letters, 2021. Analysis of 83,719 SKUs across 31 U.S. consumer packaged goods categories.

[3] McKinsey Global Survey on organizational transformations. 1,546 executives surveyed; 38% reported transformations completely or mostly successful in delivering ROI; 80% described same investments as successful. McKinsey & Company, 2008.

[4] Standish Group. CHAOS Report series, 1994-present. Project success, challenge, and failure rates tracked annually across thousands of software and technology projects.

[5] Gartner. “Gartner Survey Reveals That Only 48% of Digital Initiatives Meet or Exceed Their Business Outcome Targets.” Press release, October 22, 2024. Survey of more than 3,100 CIOs and technology executives and more than 1,100 executive leaders outside IT.

[6] RAND Corporation. AI project failure rate research, 2024. Consistent with Gartner data showing fewer than half of AI projects advance from prototype to production.

The conversation happening in boardrooms, at conferences and across the leadership press right now is worth taking seriously. Executives need better judgment infrastructure for AI decisions. Boards need to ask harder questions about how AI-assisted decisions are made and who is accountable for them. Organizations need governance frameworks that account for autonomous action in ways they never had to before. These are real observations. The people making them are noticing something true.

What is being diagnosed as a governance gap is better understood as a symptom of something upstream, and governance frameworks, however well-designed, cannot reach it on their own. The sequence matters as much as the structure.

Governance, in this context, means two things: who in the organization is authorized to deploy AI agents and what those agents can access, and what categories of decisions agents are permitted to make on their own. Most of the current conversation addresses the first. Almost none of it addresses the second. That distinction matters more than the governance conversation has acknowledged.

The diagnosis being made

The pattern in recent executive-facing AI coverage has converged on the same argument: AI is moving faster than executive understanding. Leaders are deploying without comprehending the downstream implications. The fix is fluency: get executives up to speed on how AI works, what it can and cannot do, and how to govern its outputs. Layer on governance frameworks: decision rights, accountability structures, oversight protocols. Build the infrastructure for better judgment.

This framing is not wrong, but it is incomplete in a way that matters.

What the governance conversation has not adequately addressed is that organizations publicly reporting AI implementation friction are not uniformly ungoverned. Many have invested in exactly the frameworks being prescribed. The problem showing up in their results is not the absence of structure. It is that the structure is sitting on top of something that was already broken before AI arrived.

What was already broken

The Why Change Fails series mapped five breakpoints where organizational transformations collapse: Strategic Disconnection, Incentive Fragmentation, Process Friction, Technology Illusion and Momentum Mirage. Each one represents a failure mode that does not originate with AI. AI accelerates them.

Strategic Disconnection is the one the governance conversation consistently underestimates. Most AI adoption right now is not driven by a coherent vision of what the organization is trying to become. It is driven by fear of being left behind, or by a belief that AI is a substitution technology: that you can swap AI for people and process, reduce costs and preserve outputs. Neither of those is a strategy. Neither of them answers the question that transformation requires an answer to: what are we building toward and why does it matter?

When that question has no answer, employees notice. They experience AI deployment not as progress toward something but as threat confirmation. The organization is figuring out how to need fewer of them, and leadership either will not say it plainly or does not see it. That experience does not stay private. It becomes the operating context in which every subsequent AI initiative lands. Governance frameworks cannot fix a trust deficit. Fluency training cannot fill a vision void.

This is the failure that predates the governance conversation and that governance frameworks, on their own, will not reach.

Why AI makes it worse

Paper 4 of the Why Change Fails series, The AI Mirror, made the argument directly: AI does not create organizational dysfunction, but amplifies whatever is already there. Deploy AI into an organization with clear purpose, coherent incentives and well-designed workflows, and AI accelerates progress. Deploy it into an organization where strategic direction is absent, incentives are misaligned and workflows were built for a different era, and AI makes those problems move faster and at greater scale.

There is a second problem the amplification framing does not fully capture. With software, a bad decision was at least traceable. Someone designed it in, or someone failed to catch a flaw. The cause had a name. AI agents operate differently. They do not execute what they were told. They infer what to do from the context they are given. That means an agent can do exactly what it was authorized to do, touch only the data it was permitted to touch, and still produce an outcome nobody intended, because it concluded something nobody anticipated. The organization can have complete audit logs of what the agent did and still have no clear answer for why it decided to do it. Governance frameworks installed on top of strategic disconnection do not just codify bad decisions more efficiently. They authorize a system to make decisions nobody designed and nobody approved, in service of a direction nobody agreed on.

The governance conversation is trying to solve an output problem. The output problem is a strategy problem. And strategy, as Paper 3 of the series argued, takes on the shape of what the system actually rewards, independent of what is stated in values documents or town halls.

This is where the design problem becomes visible. Cost reduction is a legitimate and often necessary outcome. The issue is when cost reduction becomes the ceiling rather than a floor. An executive whose incentive structure is built around cost reduction will build, consciously or not, an organization optimized for that purpose. AI deployed in that context will reduce costs efficiently. It will not answer the question the organization never asked: what is the freed capacity for? Governance frameworks installed on top of that answer will govern the outputs of a narrow purpose well. They will not expand the purpose.

Organizations that have done the upstream work, that have a genuine answer to what they are building and why, will find that governance frameworks become exactly as powerful as advertised. The sequence determines the outcome.

The sequencing problem

There is a pattern in organizational change that the series has documented across multiple contexts. An organization experiences a visible failure. Consultants and advisors identify a proximate cause, the thing that failed most recently and most visibly. A prescription is built around that proximate cause. The prescription is implemented with genuine effort. The same failure recurs, in a slightly different form, because the root cause was never addressed.

This is a sequencing problem, not a competence problem. The organizations investing in governance frameworks are often doing exactly what the situation calls for. The question is whether the foundation those frameworks are meant to govern is ready to support them. Governance installed on top of strategic clarity is a multiplier. Governance installed on top of strategic disconnection codifies the disconnection more efficiently.

The AI governance conversation is following this pattern. Organizations deployed AI without clear purpose, without dealing honestly with the substitution question, without the leadership foundation that genuine transformation requires. They are now experiencing the downstream effects: eroded trust, misaligned outputs, accountability gaps. The prescription being offered is governance frameworks and executive fluency. Those are real interventions. They are interventions that will reach their full potential only when the foundation beneath them is sound.

The question worth asking is whether the organization has the governance infrastructure its AI decisions require, and whether it has the organizational conditions that make any governance infrastructure work. The governance conversation has a framework answer for the first. The Why Change Fails series was written to address the second.

GitLab’s 2026 restructuring illustrates the sequence. They did not begin with governance, but with ten core beliefs about what the agentic era requires. Governance came fifth, only after the strategic foundation was named. They also removed up to three layers of management because every layer is a place where vision and priorities get filtered. The shorter the stack, the closer governance gets to the work it is meant to shape. (GitLab Act 2, 2026)

Where the work actually starts

Paper 1 of the series identified Strategic Disconnection as the first breakpoint: the failure to connect transformation effort to a clear, owned, communicated purpose. That breakpoint applies to AI adoption directly. Before governance, before fluency, before workflow redesign, the organizational question is: what is AI for here, specifically, in terms of what we are building and who we serve?

That question is not technical. It is not answered by a governance committee. It is answered by leadership that has done the harder work of clarifying what the organization actually is, what it is trying to become and what it is willing to trade to get there. Without that clarity, AI deployment, however well-governed, is acceleration without direction.

The governance conversation is worth having, and organizations that invest in it seriously are further along than most. The question worth adding to that conversation is: what are we governing toward? Governance that works starts with a named purpose, distributes accountability to the teams actually deploying agents, and defines what agents are permitted to decide on their own. That sequence is available to any organization willing to do the upstream work first.

Enterprise AI deployments follow a pattern that has become predictable enough to examine as a system problem rather than a series of individual failures.

A vendor builds a proof of concept. The technology performs. The engagement is logged as a success. Three to six months later, the system has degraded, drifted or stopped being used. The customer calls with a complaint that sounds like a technology failure. It is usually not.

The technology worked. The organizational conditions required to sustain it were never established. Published data on this pattern is consistent: IDC’s CIO Playbook 2025 found 88% of AI proofs of concept fail to reach production deployment, and RAND Corporation’s 2024 study found AI projects fail at roughly double the rate of non-AI IT projects.[1][2] In both cases the failure point is reliably the organizational transition rather than the technology itself.

The major AI vendors have recognized that a gap exists between what agentic AI can do in a controlled demonstration and what enterprise organizations can absorb in production. Their institutional response, the Forward Deployed Engineer, is a reasonable answer to a real problem. The purpose of this piece is to examine what that answer gets right, what it misses and what a more complete model would require.

The Three Problems the FDE Model Addresses

The Forward Deployed Engineer (FDE) is not a new concept. Embedding technically skilled practitioners with customers to accelerate deployment has been a feature of enterprise technology sales for years. What is new is the scale at which the leading AI vendors are deploying the model and the convergence with which they are doing it.[3][4][5][6] When the major players move in the same direction at roughly the same time, the shared problem they are solving is worth examining.

Three problems drive the model. They are related but distinct, and the FDE addresses them unevenly.

Speed. The traditional enterprise deployment model requires agreement on scope, team assembly and a signed statement of work before any technical work begins. A competitor who can start building on day one has a significant advantage in a market where customers are still evaluating options. The FDE is, at its core, a competitive response to the sales cycle problem.

Skill. Most enterprises do not have the internal capability to stand up a production-grade GenAI deployment. They have teams who understand the vocabulary, have run pilots and experimented with consumer tools. Most do not have teams who can architect multi-agent systems, design evaluation frameworks, manage model behavior in production or build the feedback loops that keep outputs aligned to intent over time. The FDE imports that capability.

Value fit. Inside most enterprises, the people closest to AI tools gravitate toward problems that are technically interesting rather than problems that are strategically important. The result is a proliferation of pilots that address edge cases, internal tooling and experimental applications that will never justify the investment required to scale. The FDE, at best, helps redirect effort toward use cases that align to real business priorities and are worth building toward production.

The FDE model addresses the first two problems reliably. The third receives more uneven treatment. Identifying a use case that genuinely matters to the customer’s business requires a different kind of conversation than the one that moves a deployment forward, and it is structurally in tension with the speed problem the FDE also exists to solve.

All three share a common assumption: the job is done when the proof of concept works. None of them address what happens after the FDE leaves.

What the Job Descriptions Reveal

The published job postings from the major AI vendors offer a window into what each believes the FDE role is actually for. Read across vendors, the signal is consistent.

The shared profile: production experience with large language models, advanced prompt engineering, agent development and evaluation frameworks. The most sophisticated postings add language about scoping work, sequencing delivery and measuring success through production adoption and measurable workflow impact. That framing is closer to what actually determines whether a deployment produces durable value. But it is still a delivery capability. The FDE is expected to measure workflow impact, not to assess whether the organization has the conditions to sustain that impact.

The hiring criteria is the most direct evidence of the diagnosis. When the screening requirements center on code, LLM architecture and prompt engineering, the model has already decided what the problem is: a technical build gap. That diagnosis is partially correct, but for most enterprises struggling with AI adoption, the build constraint isn’t what’s holding them back.

Across all of them, the requirement to assess organizational readiness before building begins is absent. None ask whether the intended outcome is defined specifically enough to govern the system over time. None address who owns the result after the FDE departs. None require evaluation of whether the workflows being augmented have been redesigned to absorb a new capability, or whether the organization has the practices to maintain what it has been handed.

The FDE is hired to win the engagement. Getting to a working proof of concept and securing adoption is the job. Whether that proof of concept becomes a production system that holds is someone else’s problem. That boundary is not incidental. It reflects a theory of the problem that stops at the close.

Where AI Deployment Differs from Software Deployment

Before examining what the FDE model misses, it is worth acknowledging what it reflects accurately: the current deployment complexity is partly a function of where AI sits on the technology adoption curve.

New, disruptive technologies that do not fit cleanly into existing paradigms have always required more intensive engagement at the proof of concept stage. Early ERP deployments, the first wave of cloud migrations, the initial rollout of service-oriented architectures: all required embedded practitioners, extended scoping and significant organizational work before value could be demonstrated. As those technologies matured and deployment patterns became repeatable, the model shifted: RFI and RFP processes replaced custom engagements, implementation templates replaced bespoke builds, and in some cases the proof of concept was skipped entirely because the deployment risk had become well understood. The FDE model, in this reading, is a maturity response. It will evolve as AI deployment becomes more templated.

That reading is partially right.

The proof of concept model works well for traditional enterprise software because the deployment question and the value question are largely the same: does the technology work in this environment? If yes, adoption follows a predictable path. The product has documented behavior, known integration requirements and repeatable deployment patterns. Once it is working, it keeps working. Maturity reduces the cost of answering that question. It does not change the nature of the question.

GenAI presents a different question, one that does not get easier to answer as the technology matures.

A proof of concept demonstrates that the model can produce an output. It does not establish whether the organization can define what “good output” looks like consistently enough to govern it over time. It does not determine whether the workflows the output is meant to improve are ready to absorb a new capability. It does not assign ownership of the ongoing tuning, monitoring and correction the system requires. It does not create the feedback loop that catches drift before it compounds.

The maturity path is real for narrow AI tools that return a result and stay in place. Those do follow the pattern of earlier enterprise technologies. Deployment complexity decreases as patterns become repeatable and implementation becomes templated. Agentic AI follows a different path. A mature, widely deployed agentic system still requires someone to own the outcome, still requires the workflow to have been redesigned around the new capability, still requires active monitoring to catch drift. Those conditions do not become easier to ignore as the technology matures. In some respects they become harder, because the scale of agentic deployment grows while the organizational attention given to any single system shrinks.

The organizational conditions problem has been present in enterprise technology adoption for decades. It has largely been absorbed by the friction of slow deployment cycles, long implementation timelines and the tolerance organizations have had for mediocre technology outcomes. AI removes much of that friction. Deployment is faster, outputs are immediate and the gap between a working proof of concept and a drifting production system is measured in weeks rather than years. The organizational problem that could be ignored in previous technology cycles can no longer be deferred.

This is what the FDE model has not yet fully reckoned with. Some of what FDEs do today will be templated away as AI matures. The organizational readiness work will not.

What Successful FDE Engagements Have in Common

Not every FDE engagement follows the failure pattern. The engagements that produce durable value share a set of characteristics that are organizational rather than technical.

In the engagements that hold, someone established four things before any technical scoping began: the specific business outcome the deployment was meant to produce, the person accountable for that outcome after the FDE’s departure, the workflow changes required for the output to produce value and the mechanism by which the organization would detect drift from the original intent.

The FDEs who ask these questions are not doing so because their job description specifies it. They are asking because experience has taught them that a technically successful deployment landing in an organizationally unprepared environment will not hold. These are organizational design questions. The job description treats them as someone else’s problem.

The vendors winning sustained customer relationships beyond the proof of concept are the ones where the embedded practitioner has come to understand that standing up the system is not the end of the job. Making sure the organization can own what it has been handed is.

Four Prerequisites Before the First Line of Code

A model designed for the actual problem would treat organizational readiness as a prerequisite for technical scoping, not an afterthought following deployment. That prerequisite assessment centers on four questions.

What is the outcome? The business result the deployment is meant to produce, stated specifically enough that someone could evaluate, six months from the launch date, whether it was achieved. A use case is not an outcome. If the customer cannot answer this question before scoping begins, the proof of concept will demonstrate that the technology works and establish nothing else. The FDE should not build until there is a clear answer.

Who is accountable after the engagement ends? The person responsible for whether the deployment produces the stated outcome: not the project manager, not the executive sponsor, but the individual whose job it is to ensure the system continues working and producing value once the vendor has left. If no one holds that accountability at the start, the system will be maintained by whoever is available. That is how working systems become broken ones.

What changes in how work gets done? AI either augments existing workflows or replaces them. Either way, something about how people work must change for the output to produce value. If that change has not been designed before building begins, the new capability will be used around the edges of the existing process and produce marginal results regardless of how well it was built.

How will drift be detected? AI systems require active monitoring. The relevant questions: who is responsible for comparing what the system is producing against what was intended, at what frequency and with what authority to intervene when drift is detected. If no one owns this function before the FDE leaves, the system works at launch and fails quietly over time.

These questions do not require an organizational consultant to ask. A technically skilled practitioner can ask and help answer them. The prerequisite is treating them as conditions for starting, not issues to address if problems emerge later.

The Structural Problem the FDE Model Has Not Resolved

The FDE model exists because the gap between what AI can do in a controlled environment and what an enterprise organization can absorb in production is real and large. Embedding technically capable practitioners with customers is a legitimate response to that gap.

The gap the FDE model has not resolved is primarily organizational. The technology works. The proof of concept succeeds. What fails is the organizational side: definition of purpose, ownership structure, workflow redesign and monitoring discipline. These are the conditions that determine whether a working proof of concept becomes a production system that holds.

The structural reason is straightforward. The proof of concept is where the sale closes. Organizational readiness work, the work that actually determines whether the deployment holds, happens after the contract has been signed. There is no incentive to make it part of the FDE’s scope. There are real incentives to keep it out: it slows deployment, introduces friction into the customer relationship and surfaces organizational problems the customer may not want named.

The vendors who change this will not do so primarily because it serves their customers, though it does. They will do so because the failure pattern ultimately damages the relationship and the renewal. The vendors who treat customer success as the measure of done will build something that compounds over time. The ones who continue measuring success at proof of concept delivery will keep winning the deployment and losing the account.

The FDE role is the right instinct. What it defines as success is the wrong question.

Notes

[1] IDC Research in partnership with Lenovo. Lenovo CIO Playbook 2025. Finding: “88% of observed POCs don’t make the cut to widescale deployment. For every 33 AI POCs a company launched, only four graduated to production.” Cited in CIO Magazine, March 25, 2025.

[2] RAND Corporation. “Why AI Projects Fail” (RRA2680-1), 2024. Based on interviews with 65 data scientists and engineers. Finding: more than 80% of AI projects fail, roughly double the failure rate of non-AI IT projects. Note: broader scope than POC-to-production specifically.

[3] Palantir Technologies. “Beyond Founder Mode: Mission Mode.” Palantir Blog, November 12, 2025. https://blog.palantir.com/beyond-founder-mode-mission-mode-b81bfa5a8d82. Describes Forward Deployed Engineering as a novel approach generated from Palantir’s need to work inside complex mission-driven organizations.

[4] FDE Academy. “How Palantir Invented the Forward Deployed Engineer Model.” April 13, 2026. https://fde.academy/blog/how-palantir-invented-the-forward-deployed-engineer-model

[5] Pragmatic Engineer. “What are Forward Deployed Engineers, and why are they so in demand?” November 3, 2025. https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers

[6] Netguru. “What Is a Forward Deployed Engineer? The Complete Guide.” June 4, 2026. https://www.netguru.com/blog/forward-deployed-engineer-role-guide

The standard prescription for enterprise sales is to maintain three to five times your quota in pipeline. For complex deals with long cycles, multiple stakeholders and large contracts, five times is not unusual. The logic is simple: if your win rate is around 20 to 33 percent, you need enough pipeline to absorb the losses and still hit your number.

Notice what that prescription does not include: any examination of why the win rate is what it is, whether it could be different, or what it would take to change it. The coverage model treats a 20 to 33 percent win rate as a fixed operating condition, something to plan around rather than something to fix. Build enough pipeline and the math works out. Do not ask why four out of five deals are being lost.

This is an institutional design choice, repeated across the profession and rarely named as such. Coverage ratios, quota design, territory structure: an entire operating model built around a failure rate no one questioned. That acceptance is its own illusion.

It is not the only one.

Of the deals that do close, many fail to deliver the outcome the customer purchased. The product gets deployed. Adoption stalls. The ROI case that justified the purchase is never tracked against actual results. Years later, when the renewal conversation finally arrives, the original champion has often moved on and no one can reconstruct whether the investment was worth it.

Some of what gets counted as success is not success. A transformation is declared successful when the system goes live, on time, on budget, full scope delivered. Whether the business actually changed, whether the promised productivity gains materialized, whether anyone is still using the system a year later: those are measured later, if at all. A sale is declared successful when the contract is signed. Whether the customer achieved the ROI they bought it for is someone else’s problem by then. Standish Group has documented this gap in software implementations for three decades. The Iron Triangle, on-time, on-budget, on-scope, is consistently measured; business value delivered is consistently not.[3] McKinsey's transformation data shows the same gap: only about a third of executives called their transformation successful, and among transformations meant to change the whole organization, only 54% said the daily work of most of the workforce actually changed.[3] Success gets declared long before anyone checks whether the work is different, which is the point.

Two illusions compound each other. The profession accepts failure at the front end and does not measure it at the back end. The win rate measures whether the deal closed. It says nothing about what happened next. That gap, between closing the deal and delivering the outcome, is where most of the real failure in enterprise sales lives, and it is almost never measured.

That same gap appears in organizational transformation, and the structural reasons are identical. The Why Change Fails series maps five breakpoints where transformations collapse: Strategic Disconnection, Incentive Fragmentation, Process Friction, Technology Illusion and Momentum Mirage. The argument is that those same five breakpoints explain why enterprise sales fails to deliver, with regularity and at scale, in ways sales leadership has not been willing to look at directly. The parallel is mechanistic, and understanding it changes what you look for, what you build and what you measure.

The win rate leadership has accepted

Win rates are not uniform across deal types. They vary by the nature of the opportunity being pursued.

Competitive displacement attempts close at very low rates because when a customer signals interest in replacing an incumbent. The signal is often not genuine intent to switch, but a request for pricing leverage. RFPs that arrive without prior relationship development are frequently already written toward a predetermined selection. Pursuing them consumes time and resources at a win rate that rarely justifies the investment. Complex deals where the business problem and desired outcome are established before pursuit begins close at a materially higher rate.

Most organizations do not distinguish between these. They all count toward pipeline coverage. A low-probability displacement attempt and a high-probability outcome-anchored deal look identical in the coverage ratio, and the three-times-quota requirement absorbs both without flagging the difference.

A sales representative or solutions engineer with three to five assigned accounts and an annual quota does not have the luxury of selectivity. They pursue what is available. When accounts are early in relationship development, the available opportunities will skew toward lower-probability pursuits, not because the seller lacks judgment, but because the territory does not yet offer better options. The system produces the win rate it was built around, and the operating model absorbs it rather than examining it.

The organizations that consistently outperform on win rates are not generating more pipeline. They are better at identifying which deals are actually winnable and why, and running differentiated approaches for different opportunity types. That is a diagnostic and design discipline, and it is exactly what the system’s current design does not incentivize or develop.

A 20 to 33 percent win rate does not have to be accepted as a fixed condition of doing business. It is the output of a system that was never designed to ask why it is what it is. A different design, one that distinguishes pursuit types, builds relationship depth as a strategic priority and measures outcomes rather than activity, would produce a different result.

Where transformations and sales fail

Taking the five breakpoints from the Why Change Fails series and mapping them against enterprise sales failure is not a forced analogy. The mechanisms are the same even though the stakeholder configurations differ. The root causes are identical.

Strategic Disconnection is the failure to establish a shared, specific definition of what success looks like before the work begins. In transformation, this shows up as a compelling case for change that leaders can recite but can’t operationalize, which is direction without definition. Stakeholders are aligned on the narrative and misaligned on what changes, who owns it and how you know it’s working.

In sales, Strategic Disconnection happens before the contract is signed. The disconnection often precedes the deal itself. When a pursuit begins without a shared definition of what success requires, the pipeline fills with opportunities that can close but cannot deliver. The win rate problem and the outcome problem share the same root.

The buyer champion has a definition of success. The economic buyer has a different one. The implementation team, who will inherit the commitment, was not in the room for either conversation. The deal closes with multiple stakeholders aligned on purchasing a solution and misaligned on what solving the problem actually requires. Gartner buying committee data shows enterprise deals typically involve 11-20 active stakeholders at enterprise scope.[1] Multiple stakeholders with different definitions of success is not a negotiating complexity but a delivery risk that the sales process treats as a closing challenge.

Incentive Fragmentation is the misalignment between what the organization measures and rewards and what the transformation requires. Leaders whose power depends on the current structure have no incentive to redesign it. The fastest path is marginal adoption around the edges, which looks like progress and produces none.

In sales, the incentive fragmentation is structural and explicit. The quota system measures deal closure, not outcome delivery. The seller is rewarded at signature. Whether the customer achieves the promised ROI is a customer success problem, a services problem, a product problem, almost any problem except a sales problem. The seller who closes a deal the customer can’t absorb has hit their number. The seller who slows a deal down to validate that the customer is ready has missed quota. The incentive structure does not reward the wrong behavior because sellers lack judgment, but because the measurement system stops at the wrong moment.

Process Friction is what happens when the workflows and handoffs required to deliver the outcome are broken, undefined or running on informal workarounds. Transformation initiatives that don’t redesign the underlying process are improving the wrapper on a broken package.

In sales, the broken handoff between pre-sale and post-sale is the process friction that makes failures predictable. The seller who built the business case is rarely the person who executes the implementation. The champion who sponsored the purchase is rarely the person whose daily work changes when the product goes live. The information that determines whether deployment succeeds, what the customer actually needs, what they said yes to and what problems they’re trying to solve, lives in the seller’s head and the pre-sale documents, not in the system the implementation team works from. Every enterprise software failure story that traces to “the customer bought something they couldn’t operationalize” is a process friction story. The handoff was broken before the project began.

Technology Illusion is the pattern of investing in a tool as a substitute for doing the organizational work that determines whether the tool produces value. The proof of concept is impressive. The deployment goes into conditions the organization hasn’t prepared. The gap between demonstration performance and production performance is attributed to the technology. The root cause is structural.

In sales, the Technology Illusion runs in both directions. The vendor believes that a technically capable product, correctly deployed, will produce the outcomes in the sales deck. The buyer believes that purchasing the right solution will solve the problem, bypassing the organizational change required to absorb it. Both are wrong for the same reason: they are treating an adaptive challenge as a technical one.[2] The outcome requires people to work differently, systems to be redesigned and decision authority to shift. None of those are features of the product, but, instead, are conditions the product requires.

Momentum Mirage is the confusion of activity for progress. Logs are filling. Tasks are completing. Deployment dashboards are green. The meaningful signal, whether the initiative is producing the outcome it was launched to produce, has no one watching it, because success was declared at go-live and the work of measuring actual value was not assigned to anyone with authority to act on what they find.

In sales, the Momentum Mirage emerges at renewal. Usage metrics look acceptable. Support tickets are within range. The customer hasn’t complained loudly enough to escalate. When the renewal conversation finally arrives, the account team discovers that the economic buyer who signed the original deal has a different read on the value delivered than the usage data suggests. The ROI case that justified the purchase was never tracked against actual outcomes. No one was assigned to do that. The momentum was visible in the activity data; the mirage was that activity meant the outcome was being achieved.

What it looks like when it works

The sales engagements that produce durable value, where the customer achieves the ROI they bought, renews without being pushed and calls back when a new problem emerges, share a set of organizational conditions that are rarely part of the sales process by design.

Before the deal closes, someone established a precise definition of success: not “improve customer response times” or “increase team productivity”, but a specific business outcome, measurable at a defined point in time, with explicit criteria for what achieving it requires beyond the product itself. The organizational changes, the process redesigns and the decision authority shifts are named and owned before the contract is signed.

Someone established clear accountability for the outcome after the handoff: a specific person whose job it is to ensure the deployment produces the stated result, with the authority to intervene when it doesn’t. The project manager who runs the implementation fills a different role. If no one holds outcome accountability from the start, the system works at launch and fails quietly over time.

The workflows were redesigned around what the product actually requires, not wrapped around the existing process with the product installed on top. These two approaches look similar at deployment and diverge within months. The first treats the product as a participant in how work gets done. The second treats it as a layer added to how work already gets done.

The seller stayed engaged past close with the goal of ensuring the outcome, not managing the renewal. This is the distinction that separates sellers whose customers call them back from sellers who are always starting over. The engagement that produces trust is not the pitch but the period after the signature, when most sellers have moved on and the problems that determine whether the investment was worth it are being encountered for the first time.

These are organizational conditions, not technical requirements. The product cannot supply them. The contract cannot mandate them. They have to be established by someone, the seller, the executive sponsor or the implementation leader, who understands that the deal closing is not the outcome.

What this means for leaders building something different

The Why Change Fails series makes the case that transformation leaders are often focused on the wrong problems. The technology typically works. The frameworks are sufficient. The gap is in the organizational conditions that determine whether the tool, the method or the initiative can produce what it was designed to produce. The same case applies here. The sales methodologies are sufficient. The gap is in the organizational conditions that determine whether the customer achieves the outcome they purchased.

The cost of the current design accumulates in the places the measurement system isn’t looking. Customers who don’t achieve their expected ROI don’t renew, or renew at reduced scope, or require expensive intervention to salvage the relationship. Winning a replacement customer costs far more than keeping the original, a gap the customer-loyalty research commonly puts at five to twenty-five times the cost of retention.[4] Win rates accepted as fixed drive pipeline coverage requirements that consume resources pursuing low-probability opportunities, resources that could instead build the account depth and relationship quality that generate higher-probability ones over time. The system is not failing randomly. It is producing predictable, measurable costs that standard sales metrics are not designed to surface.

A different design is available. Examine the win rate as a system output, not an operating condition. Distinguish between opportunity types and invest in the conditions that generate high-probability pursuits rather than building coverage to absorb low-probability ones. Redefine success at the point of outcome, not the point of close. Build accountability for delivery into the sales role, not just the implementation role. Redesign the handoff so the information that determines whether a deployment succeeds actually transfers. Measure whether the customer achieved the ROI they purchased and tie something real to the answer.

None of that requires a new methodology. It requires a different definition of what the sales function is for. The current definition, close the deal, is precise, measurable and produces exactly what it is designed to produce. A different definition, ensure the customer achieves the outcome, produces something different. Some organizations are already redefining the finish line. Most haven’t made that choice explicitly, and the current win rate is what that choice looks like.

Notes

[1] Gartner. B2B buying committee research (enterprise-scope deals): 11-20 active stakeholders. Gartner, 2023.

[2] Ronald A. Heifetz. Leadership Without Easy Answers. Harvard University Press, 1994.

[3] Standish Group. CHAOS Report series (1995-2020). McKinsey, 'Creating Organizational Transformations: McKinsey Global Survey Results' (July 2008; 3,199 executives): about a third rated their transformation very or extremely successful, and among those whose transformation was meant to affect the whole organization, only 54% said the daily work of a majority of the workforce actually changed.

[4] On the cost asymmetry between acquiring and retaining customers, commonly cited as roughly five to twenty-five times: Bain & Company and Harvard Business Review customer-loyalty research (Reichheld and colleagues).

Every technology cycle produces the same moment.

A capability arrives that is genuinely impressive, and the organizational response is to treat it as the solution to problems that were never primarily technical. The capability solves a real problem, but not the one the organization actually has.

The first wave of ERP deployments promised integrated operations and a single source of truth. What failed, reliably, was not the software. It was the organizational conditions the software assumed: clear process ownership, consistent data definitions and the discipline to maintain both over time. The technology worked. The organizations that deployed it into broken conditions got broken operations, faster and at greater scale.

The cloud migration moment had the same pattern. The infrastructure worked. The costs didn’t improve as promised, not because the infrastructure was wrong, but because the organizational incentives, the governance architecture and the operating model that controlled cloud spend were not redesigned alongside the migration. The technology moved forward. The organization stayed put.

For AI it is the agent moment.

The pattern is repeating, this time with agents.

The promise is not wrong about what the technology can do. Where it goes wrong is what the technology can fix. Agents don’t resolve the organizational conditions that cause transformations to fail. They amplify whichever ones already exist, faster, at greater scale, with less visibility into the drift.

The question isn’t whether to deploy an agent. The question is whether the organizational conditions are in place that allow an agent to produce what you need.

What an agent actually requires

For the executive reader who hasn’t built one: an agent is not a smarter chatbot.

A chatbot waits for a question and returns an answer. An agent takes sequences of actions toward a goal, autonomously, observing its environment, deciding what to do next, acting on that decision and adjusting based on what it learns. The human approves the goal. The agent executes. That autonomy is the value proposition, and exactly where the organizational requirement lives.

Three things the technology cannot supply.

A goal defined precisely enough for the system to make tradeoffs without human intervention. An agent given a vague goal doesn’t fail to act. It acts confidently in a direction the organization didn’t intend. “Improve customer response times” is not a goal precise enough for an autonomous system. At what cost? By what means? What tradeoffs between speed and accuracy are acceptable? What decisions require human review before action? Every one of those unanswered questions is a decision the agent will make on its own.

A process clear enough to hand off. The process needs every step mapped, every handoff owned and every exception anticipated. The agent will encounter the same edge cases, ambiguous ownership and broken handoffs that humans encounter, and will handle them without the contextual judgment that lets humans work around dysfunction they’ve learned to absorb. An agent deployed into a process that runs on informal workarounds will expose every one of them.

A monitoring function with authority to correct drift. The agent’s outputs will drift from intent over time. This is a property of any system that adapts, not a defect to be fixed at launch. What determines whether drift compounds or gets corrected is whether someone owns the monitoring function: watching the gap between what the agent is doing and what was intended, at a defined cadence, with the authority and the knowledge to intervene. If no one is assigned to that function before deployment, the system works at launch. Three months later, no one can explain what it’s actually doing.

These are organizational design requirements. The agent won’t generate them.

Where it actually works, and why

There is one domain where AI agents are delivering on their promise at scale, reliably, across organizations of different sizes and maturity levels: software development. AI coding assistants and agents are producing measurable productivity gains, reducing defect rates, accelerating code review and shortening the cycle from idea to deployed capability. The results are real and documented.

The reason they work is not the technology. The reason they work is that software development is the rare organizational domain where every condition the technology requires was already in place before the agent arrived.

Software has a formal language with explicit rules. The agent knows what valid output looks like. Code either compiles or it doesn’t. Version control systems like Git provide a structured, documented record of every change: who made it, what it changed, when and why. Merge and review processes define exactly how changes get proposed, reviewed and integrated. Testing frameworks provide an objective, automated standard for what “good” looks like: tests pass or they fail. And the definition of success, what the software is supposed to do, is typically specified in requirements, acceptance criteria and user stories that can be evaluated directly against the output.

The agent isn’t producing the goal, the proof of correctness or the process. It’s operating inside a system that humans built over decades of hard-won software engineering discipline. Remove any of those conditions (vague requirements, no automated tests, no version control, no review process) and the AI agent’s output degrades or becomes uncontrollable in exactly the same ways agents fail in other domains.

Software development is not the exception that disproves the organizational readiness argument. It is the clearest demonstration of what the argument predicts: when the conditions are right, agents deliver on the promise. When they’re not, they don’t. The difference between software and the average enterprise deployment isn’t the technology. It’s the infrastructure of specificity and accountability that software engineering built before the agents arrived.

Most organizations have not built that infrastructure for the business processes they now want to automate.

The amplification problem

Organizations failing to get value from AI are not failing because the technology is weak.

McKinsey’s State of AI 2025 found 88% of organizations now deploy AI in at least one business function, yet only 39% report any measurable effect on enterprise EBIT. Deployment is outpacing business value realization by more than two to one. The technology that is failing to produce bottom-line impact is the same technology that demonstrably transforms the operations of organizations that have gotten the organizational conditions right. The variable is not the tool. The variable is the context the tool is operating inside.

Agents don’t change that failure condition. They accelerate it.

The Why Change Fails series describes five breakpoints: the specific organizational failure modes that determine whether a transformation produces durable value or visible activity. Each one maps directly to a failure mode in agent deployment.

Strategic Disconnection. The agent is given a goal that was never pressure-tested against what the business actually needs to achieve. A vague directive doesn’t produce vague results from an agent. It produces confident, efficient execution in the wrong direction, at machine speed. The months of slow drift that human execution produces compresses to days. By the time the gap between activity and outcome becomes visible, it has been running at scale.

Incentive Fragmentation. Leaders whose work is being transformed have no incentive to redesign the workflows the agent depends on. The fastest path is deployment around the edges of the existing process. The result is marginal improvement on a process that was already underperforming. The agent does its part; the surrounding structure ensures the output doesn’t compound into anything significant.

Process Friction. The agent doesn’t route around the broken steps in the process the way people who built workarounds over years know how to. It executes the broken process efficiently, at scale, automatically. The friction that was invisible because humans absorbed it becomes visible in the output data, at volume, on a timeline the organization didn’t plan for.

Technology Illusion. The demo is impressive. The proof of concept succeeds. The agent gets deployed into conditions the organization hasn’t prepared: undefined outcome criteria, unclear ownership, workflows that haven’t been redesigned to absorb what the agent produces. The gap between demonstration performance and production performance is attributed to the technology. The root cause is structural.

Momentum Mirage. The agent is running. Logs are filling. Tasks are completing. Every operational dashboard says deployment is succeeding. Drift is invisible without a monitoring function designed specifically to watch for it. The organization is watching the wrong signal. Activity is filling the dashboards while the meaningful signal, alignment between output and intent, has no one watching it.

The pattern is consistent across all five: the agent amplifies whichever breakpoints already exist. It does not resolve them.

Three questions before the first line of code

The GPS check (Goal, Proof, Steps) is a diagnostic from agent design that maps exactly to the organizational requirements that determine whether a deployment produces durable value. Any executive can answer these questions. The ones who can’t have identified the work that has to happen before deployment begins.

Goal. Can you define the outcome specifically enough that the agent would consistently produce the right result, not a defensible interpretation of it? Not “improve customer service.” What specific decision does the agent make? What tradeoff is it authorized to make on its own? What outcome, measured how, six months from launch, would tell you whether the deployment succeeded or failed?

If the answer is a direction rather than a definition, the organization hasn’t done the outcome precision work. The agent will run in the direction. Whether that direction leads anywhere useful won’t be visible until it’s too late to course-correct cheaply.

Proof. Can you describe what good output looks like specifically enough to catch bad output? Who reviews the agent’s outputs, at what cadence, against what standard? When the agent makes a decision you wouldn’t have made, how does that surface? The monitoring function has to be designed before deployment. Designing it after is like building the instrument panel after the plane is airborne.

Steps. Can you map every step the agent will run, including the handoffs, the exception cases and the points that require human judgment? The organization that can do this has redesigned the workflow around how the agent actually works, not wrapped the agent around the existing workflow. These are different architectures and they produce different results. The second one is almost always what gets built, because it’s faster to stand up. It’s also the one that quietly fails.

Three questions. The gap between “yes” and “not really” on any of them is the organizational work that has to happen before deployment starts.

What organizational readiness for agents actually looks like

Four conditions distinguish agent deployments that produce durable value from those that produce impressive demonstrations followed by quiet underperformance.

The outcome is defined at system level, not tool level. Not “deploy an agent to improve customer service resolution.” Reduce resolution time for tier-one issues by 40% within 90 days of deployment, measured by average handle time for tickets the agent closes without escalation, and here is the agent’s specific role alongside the process changes and the people changes that go with it. The system definition forces the organizational design work. The tool-level definition allows the organization to skip it.

Workflows are redesigned around how the agent actually works. Not the existing workflow with an agent inserted into it. What does the ideal process look like if the agent is a full participant from the beginning? Organizations that redesign workflows for agent-native execution consistently outperform those that retrofit an agent into an existing human-native process. The latter gets a proof of concept that degrades.

The monitoring function is named and owned before launch. A specific person, not a team, not the project manager, whose job includes watching the gap between what the agent is doing and what was intended, at a specific cadence, with the authority to flag drift and the knowledge to distinguish signal from noise. This function does not emerge naturally after deployment. It has to be designed and assigned before launch, because after launch there is always something more urgent than watching logs for drift that hasn’t caused a visible problem yet.

The incentive structure supports the change. The leaders and managers whose work is being transformed have a metric that rewards the new behavior, not just the metric that rewards the old behavior with a new tool added on top. Incentive Fragmentation is the most reliable predictor of which deployments stay marginal. It is also the condition that gets addressed last, because it requires the most organizational will to change and produces the least visible short-term friction when ignored.

These are not technical requirements. No engineer can design them into the system. They are organizational conditions, and the work of establishing them belongs to the leader who owns the outcome.

The right question before deployment

Most organizations ask: how do we deploy an agent?

That is the wrong starting question. It assumes the organizational conditions are in place and the only variable is the deployment approach. For most organizations in most deployments, that assumption is wrong, and the deployment will surface exactly which conditions are missing, at the speed and scale agents operate at.

The right question is: are the organizational conditions in place that allow an agent to produce what we need?

That question has a diagnostic. A pre-launch assessment of Goal, Proof and Steps, run honestly, without the pressure to reach “yes” before the board presentation. A named owner for the outcome and the monitoring function before the first line of code. A workflow designed for how the agent actually works, not a workaround designed to deploy faster. An incentive structure that rewards the change, not just the deployment.

None of those are technical tools. All of them are organizational design tools, the same ones that determine whether any transformation holds or quietly stops being fed.

The agent won’t save an organization that hasn’t done this work. It will make the gap between where the organization is and where it needs to be visible faster, and at greater scale, than any previous technology cycle has managed.

The organizations that do the organizational work first will build something that compounds. The ones that don’t will have very impressive demonstrations and very stable underperformance.

Notes

McKinsey QuantumBlack. “The State of AI in 2025: Agents, Innovation, and Transformation.” McKinsey & Company, November 2025. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai. Figures cited: 88% of organizations deploy AI in at least one business function; 39% report measurable enterprise EBIT impact.

The company had built something real: a leadership team that said what it believed, an organization where people surfaced problems early because they had learned it was safe to do so, a north star that went beyond revenue and had been tested enough times in hard moments to be believed. It had taken years. You cannot build that kind of culture by announcing it. You build it in hundreds of small decisions: who gets promoted, what gets funded, what failure gets treated as information rather than evidence, what the leader says when the truth is uncomfortable.

When the new CEO came in, he looked at what had been built and said: the culture here needs to be different.

He was not wrong that things needed to change. He meant that the culture needed to become more like the one he knew. Tighter controls. Harder accountability. Metrics that left less room for interpretation. He held a specific and coherent set of beliefs about what makes organizations perform. He had the power to act on those beliefs. And over the years that followed, he did.

Several years later, the culture is different. Not because he was malicious. Because culture follows the leader’s actual beliefs, and the lever is always the same: who gets promoted, what gets funded, what failure gets treated as, and what the leader says when the truth is uncomfortable.

What was built is gone. What replaced it is familiar to anyone who has worked inside a large organization long enough. Tighter controls. Harder accountability. Less room for the kind of honest conversation that used to happen before the meeting.

Two leaders. The same levers. Different beliefs underneath. Different cultures produced.

The operating system

Five papers in the Why Change Fails series have described, in structural terms, why transformation fails. The five breakpoints that are present before the launch. The four forces that determine whether an initiative gains energy or loses it. The stewardship gap that opens when no one owns the ongoing work of keeping those forces aligned. The organizational design decisions that leaders rationally skip and predictably regret. The disciplines that make the difference between a transformation that holds and one that quietly stops being fed.

The analysis is real. The structural explanation is accurate. And none of it is sufficient on its own.

Because everything this series describes depends on a set of beliefs the leader holds, or is in the process of developing the honesty to examine. That set of beliefs is the operating system underneath everything else in this series. When it is present, the work holds. When it is absent, the structures get redesigned to serve whatever is actually there.

Leaders with misaligned foundations do achieve results. Restructurings succeed. Milestones get hit. Performance improves. None of that is in dispute. What they cannot achieve is transformation that holds once the pressure shifts, the spotlight moves, or the hard call arrives. The foundation is not what determines whether something changes. It is what determines whether the change survives.

This paper is about the operating system. Not about what organizations need to do. About what leaders need to be.

What you actually believe about people

There is a question underneath every leadership analysis. It never appears on a slide. It is almost never asked in executive selection. But it determines more about what an organization becomes than any strategy, any model, any set of competencies.

Do you believe that people fundamentally want to contribute, and that they underperform primarily when the system fails them? Or do you believe that people need to be managed into performance through accountability, measurement, and consequences that make the cost of not contributing higher than the cost of contributing?

Douglas McGregor named these positions in 1960. Theory X and Theory Y. The labels have become shorthand, which has made them easier to dismiss. The underlying distinction has not become less important.

Theory X: people are fundamentally resistant to work. They will do less than is required unless compelled. The leader’s job is to manage that tendency through monitoring, accountability, and the credible threat of consequence. Control is not a failure of leadership. It is its instrument.

Theory Y: people want to do good work. They take ownership when genuinely empowered and underperform primarily when the system fails to support them: the incentives, the process, the design, the culture. The leader’s job is to build the conditions in which contribution is possible, and then get out of the way.

These two positions produce different organizations. They use the same levers to entirely different effect: incentives, metrics, promotions, communication.

The CRO who watches fifty percent of the sales organization miss quota and responds with more sales plans, more measurement, more reporting does not believe the problem is structural. He believes the problem is insufficient accountability pressure. The lever is fear, applied more precisely.

The structural explanation says something different: fifty percent quota attainment is not an accountability failure. It is a signal that the quota, or the territory, or the product-market fit, or the support architecture, or some combination of those, is broken. You cannot apply your way out of a structural problem. You can only generate more activity, more fear, and eventually, more turnover.

Everything this series has described depends on a leader who believes that the people doing the work are the asset: the conditions that allow problems to surface before they become expensive, the stewardship that keeps momentum from bleeding after the launch, the design work that builds an organization capable of sustaining change. Not the problem. When that belief is absent, the same structures get built differently. The same levers get used differently. The design is there on paper. What it produces is not.

This analysis only holds in Theory Y hands. Not because Theory Y is always correct about every individual. It is not. It is a claim about what leadership posture produces better outcomes at scale, across the range of people any real organization actually contains. But because the organizational conditions the previous papers describe are only available to leaders who hold it. A leader who believes people need to be controlled into performance will read every tool in this series and use it for that purpose. The structure will look the same. The culture it produces will not be.

The prior question is what the leader actually believes about people. It comes before strategy, before any of the analysis in this series. It is almost never asked in executive selection. It is the most important one.

What the leader has to be willing to do

Beliefs are necessary. They are not sufficient.

The test is not what happens when honoring those beliefs is easy. The test is what happens when it is expensive. When the truth costs a deal. When the values-consistent decision produces a worse quarterly number. When the right call is also the harder one.

Three behaviors distinguish leaders who build culture from leaders who perform it.

The first is absorbing the cost of the values under pressure. Culture is not built in normal conditions. It is built in the moments when a value is tested by something real. The leader who finds a reasonable exception for why this case is different does not build culture. They reveal the actual terms of the value. The organization was watching. They now know what the value means: it applies when it is convenient.

The leader who absorbs the cost, who takes the hit publicly and without editorializing, demonstrates that the value is not contingent. Every decision is a data point. The accumulation of those data points over time is the actual culture, regardless of what the values document says.

The second is saying the uncomfortable thing first. The leader who waits for the team to surface the uncomfortable truth, and then responds well to it, has the architecture inverted. The signal runs from the top down. The leader who names the problem in the room before anyone else does, who says plainly “I was wrong about that,” gives explicit permission for the people below them to do the same thing.

Leaders who manage perception upward while expecting transparency downward do not get transparency. They get very polished reporting. The actual problems travel sideways, or do not travel at all.

The third is promoting the people who tell you what you need to hear. Every promotion tells the organization exactly what kind of behavior leads forward. More powerfully than any stated value or leadership principle, because it is the decision that determines people’s futures. Leaders who promote the political operator are teaching the organization to produce political operators. Leaders who promote the person who surfaced the problem no one wanted to name are teaching the organization to surface problems.

Doing this requires the willingness to promote someone who made you uncomfortable, because what they did was right, over someone who made you feel confident, because what they did was convenient. Those two people are rarely the same person.

Why good leaders still fail

Leaders who hold these beliefs and practice these behaviors still fail to sustain culture at a meaningful rate. Not because their beliefs were wrong. Because the structural environment they operate inside is designed, whether intentionally or not, to reward something else.

Jack Welch did not simply happen to one company. He happened to a generation.

His model produced visible results during his tenure at GE: forced ranking, relentless performance pressure, cutting the bottom ten percent regardless of absolute performance. It was subsequently adopted by leaders across industries who drew a straightforward lesson: this is what effective leadership looks like. The model spread because it was legible, attributable, and produced results that could be pointed to in a quarter.

The consequences came later. GE’s long decline is the deferred bill of the model he built: the financial engineering, the leadership attrition, the institutional brittleness. But the bill arrived quietly, diffusely, decades later, after Welch was celebrated and the model had already been embedded in the culture of a thousand organizations. The feedback never reached the source. The lesson the system taught was: this works.

Four structural forces shape leader behavior regardless of intent.

Quarterly pressure. A CEO who wants to invest in the kind of culture this paper describes must defend that investment to a board watching quarterly results. Repeatedly. Under pressure. When the numbers are soft. The cost is visible immediately. The return is not. Most leaders eventually stop defending it at that cost. Not because they stopped believing. Because the structural environment makes the defense unsustainable.

PE muscle memory. Leaders who build their careers inside PE-backed companies develop specific habits: cut costs, hit EBITDA, exit in three to five years. The problem is that those leaders get hired into other environments and the muscle memory runs. The playbook does not fit the context. The behavior is already habituated.

Fear as a tool that looks like leadership. Fear produces compliance and visible activity quickly. The leader who applied it registers the correlation. What does not register is the trust that eroded, the problems that stopped being surfaced, the people who started looking for other options. The damage accrues slowly and is almost impossible to attribute directly. The feedback loop does not close. The behavior is reinforced.

No counter-model from lived experience. Most leaders have never worked inside a high-trust, well-designed culture that also performed. They have read about it. They have not lived it. The leaders who believe most deeply in this kind of culture are almost always the ones who worked inside one once. Who experienced what it produces. Who spent the rest of their careers trying to recreate something they could not quite name.

The architecture that protects culture

Culture programs do not hold. Not because they are poorly designed, but because a culture program is an intervention at the level of behavior, inserted into a system whose structural incentives continue rewarding something else. Behavior that is not reinforced by the structure reverts.

The companies that sustain culture over time have structural protection for it. Governance architecture designed to make the culture survivable when external pressure creates incentive to compromise it.

Costco has maintained capped margins, above-market wages, and employee stability since its founding. This is a governance outcome. The board composition, the ownership structure, and the founder-influenced operating philosophy were established in ways that made the culture structurally durable.

Patagonia transferred to a trust structure in 2022 that made shareholder return pressure structurally impossible. Not a culture initiative. A governance decision that removed the structural force that would eventually have compromised the mission regardless of the personal convictions of anyone in the leadership chain.

These are not replicable models. But they describe the same principle: culture left unprotected by governance will eventually be reshaped by whoever holds power and whatever the incentives reward.

Three interventions actually work.

Selection. The board that puts the right CEO in place does more for culture in a single decision than any program the organization will run in the next five years. The reference call that matters is not the one that confirms competence. It is the one that asks: tell me about a time this person told a truth that cost them something.

Governance architecture. Does the structure actually protect the CEO when doing the right thing is expensive? Board composition matters. Ownership structure matters. Whether the incentive structure runs on three-year or one-quarter cycles matters. Leaders who want to build differently should understand the structural constraints they are operating inside before they commit to something the structure will eventually make unsustainable.

The belief audit before the hire. The most consequential question in executive selection is almost never asked. It can be surfaced through reference conversations designed to find the moments when belief was tested by cost, and behavioral interviews that go past how candidates describe their philosophy to what they actually did when it was inconvenient. The belief is not a secret. It reveals itself in the decisions a leader has made over time.

The question the analysis cannot answer

Every paper in this series ends with a set of diagnostic questions. This one ends differently.

Five papers have named every structural failure mode that derails transformation: the design decisions that get skipped, the stewardship gaps that open when launch energy fades, the readiness work displaced by urgency, the momentum systems never built. That work is complete.

What the analysis cannot reach is the question that sits underneath all of it.

Organizations do not have beliefs. Leaders do. And the organization that gets built, the culture that forms, the transformation that holds or collapses: all of it is downstream of what the person with power actually believes about the people they lead, and what they are willing to do when acting on that belief costs them something.

Every lever available to a leader is a daily answer to that question: who gets promoted, what gets funded, what failure is treated as, what gets said when the truth is uncomfortable. The accumulation of those answers over time is the culture. Not the values document. Not the leadership principles. Not the training program. The decisions, under pressure, when the outcome was real.

There is no structure for that. There is only the question.

What do you actually believe about the people you lead, and are you willing to act on it when it costs you something?

That is the foundation beneath everything in this series. And it was never something the analysis could give you.

This is Paper 6 in the Why Change Fails series. Start with Paper 1: The Five Breakpoints Leaders Miss

She had been through two of them.

The first was a cloud modernization at a financial services firm. Excellent kickoff. Clear executive sponsorship. A program team that knew what it was doing. Eighteen months in, the program had produced documentation, governance structure, a set of pilots that had technically succeeded, and almost no change to how the organization actually operated. The post-mortem named execution as the problem. She had been close enough to know that was not it.

The second was an operating model redesign at a healthcare system. Similar story. The diagnosis was right. The intent was real. The initiative stalled anyway, quietly, without anyone formally declaring it over. Teams continued reporting progress. The steering committee continued meeting. The breakpoints the previous papers in this series describe had been present from the beginning. Nobody had named them before the launch. By the time they were visible, the political cost of addressing them was higher than the cost of continuing to manage around them.

When she took her next role, she did something different.

Before the launch announcement, she spent six weeks doing work that never appeared on a project plan. She wrote one outcome statement and did not proceed until her CFO, her VP of Operations, and three frontline managers described it the same way. She mapped every leader with meaningful veto power over the initiative and had a direct conversation with each one about their incentives before the kickoff meeting. She redesigned three handoffs in the delivery system that she recognized from experience as the ones that would slow everything down. She named a momentum owner, distinct from herself, and wrote a one-page document defining what a stall looked like before anyone needed to interpret that question under pressure. And she did two more things most leaders do not do. She designed the sequence of the work so that the organization would see real, visible results within the first ninety days. Not a proof of concept, not a pilot. Actual value that changed someone’s number. And she did not launch to the full organization. She identified the fifteen leaders and teams most ready to move, designed the first phase entirely around them, and let what they accomplished make the case to everyone else. By the time the skeptics were watching, there was already something real to watch.

The initiative took twenty-two months. It delivered what it was supposed to deliver. It also retained the organizational support to do so, because the people funding it had seen enough along the way to keep believing in it, and because adoption had spread through demonstration rather than mandate.

Nobody outside the organization would describe what she did as remarkable. She would describe it as the only logical approach given what she had seen before.

The first four papers in this series are diagnostic. They name the five failure patterns that derail large-scale change before anyone formally declares a program off track. They describe the four forces that determine whether a transformation gains energy or loses it, and the stewardship gap that opens when no one owns the ongoing work of keeping those forces aligned. They explain why leaders rationally skip the organizational design decisions that would prevent failure. And they map what AI changes about the stakes when the same failure patterns operate at machine speed.

What they have not done is answer the question every reader eventually asks: so what do I actually do?

This paper answers that question.

Not as a methodology. The series has been explicit about the limits of methodologies. Thirty years of change approaches have not moved the failure rate. The problem is not a shortage of tools.

The difference between initiatives that hold and those that collapse is rarely what happens during execution. It is what happens in the six to twelve weeks before the launch. The leaders who get it right make seven specific choices in that window. Most leaders skip all of them.

These are not complicated choices. They are consistently not made because each one requires something the system does not reward: political confrontation before the problem is visible, specific commitment before the outcome is certain, structural investment before the pressure to act arrives. Each choice is uncomfortable. Each one is far less expensive than the retrofit that becomes necessary when it is skipped.

The Condition Everything Else Depends On

Everything that follows assumes one condition has already been met: this initiative is anchored to a business outcome that someone at the top of this organization is accountable for delivering.

Not a strategic theme. Not a planning cycle priority that made it onto a slide. A named outcome (revenue, cost, risk, agility, or competitive position) owned by a leader whose performance is measured against it, who would describe this initiative unprompted as one of the things they cannot afford to fail.

If that condition is not met, the seven disciplines in this paper do not apply. A well-designed initiative on an unanchored foundation will be deprioritized the moment something more urgent appears. And something more urgent always appears. The organization does not formally cancel it. It simply stops feeding it, and the initiative starves quietly while everyone continues filing status reports.

The test is direct. Ask the executive sponsor, without preparation: what specific business metric does this initiative move, by how much, and by when? Is that metric one you are personally accountable for? If they cannot answer all three parts without hedging, the initiative is not ready to be designed. It is ready to be questioned.

Before the Launch: Seven Disciplines

The Foundation Comes First

The seven disciplines that follow are not seven equals. Two of them carry structural weight the others cannot. Get these wrong and the rest of the work collapses. Not at the end, but mid-execution, when you have already invested the time and credibility to get started.

One is Outcome Precision. Every other discipline depends on clarity about what the initiative will actually decide, measure and deliver. Incentive conflicts cannot be resolved until there is something specific enough to create them. Delivery systems cannot be redesigned until you know what output they will need to absorb. Readiness cannot be tested until there is a clear definition of ready. The seven disciplines have a logical order, and this one sits at the top of it.

The other is Delivery Redesign. Once the outcome is defined, the organization has to be able to act on it. Most cannot. Not because intent is absent — because the workflows were designed for different work, handoffs break at the new cadence, and nobody owns the gap between what the initiative produces and what the organization can absorb. Delivery Redesign depends on Outcome Precision because you cannot redesign a delivery system until you know what it is delivering.

Leaders who treat all seven as parallel tracks will run them that way. They will hit conflicts mid-execution, discover that adoption design depends on governance that was never defined, or find that the momentum system is measuring activity in a workflow that was never redesigned. The rework is more expensive than the sequencing would have been.

The seven disciplines are not a checklist. Two of them carry the structure. Without them, the others are motion without foundation.

1. Define the outcome as if you will be held to it

The most common form of strategic disconnection does not look like disagreement. It looks like alignment.

Leaders leave the kickoff meeting nodding. The deck was clear. The goals were stated. Everyone was in the room. Six months later, the teams have diverged in ways that would have been visible from the beginning if anyone had looked carefully at what “aligned” actually meant.

McKinsey’s State of Organizations 2026 surveyed more than ten thousand senior leaders and found that 56 percent of C-suite executives reported clarity on strategic priorities. At middle management, that number was 27 percent. A 29-point collapse across a single organizational layer. That is not a communication failure. It is what happens when a direction is announced as if it were an outcome. Each layer makes its own translation. By the time the strategy reaches execution, it has been retold three times and is no longer the same strategy.

Write one outcome statement that is specific enough to be wrong. If you cannot be wrong about it, it is not yet a goal. It is a direction. Directions produce agreement in meetings and divergence in execution.

What this requires is political exposure most leaders prefer to avoid. A specific outcome can fail. A vague one cannot. Writing “improve the customer experience” protects the leader. Writing “reduce customer resolution time by 40 percent in two quarters” creates a commitment that can be proven wrong. That discomfort is the point. An outcome that cannot fail cannot succeed.

The outcome statement is ready when the CFO would recognize it as a financial event, not a program milestone. When every leader who will be asked to sacrifice something for this initiative can describe what success looks like without a follow-up question. When you would be comfortable presenting it to the board as a commitment, not a direction.

Until then, the initiative has not started. It has only been announced.

2. Resolve the incentive conflicts before the announcement

The most dangerous form of resistance is the kind that looks like support.

In the Four Forces paper, a CISO at a financial institution attended every planning meeting for a datacenter migration. He asked good questions. He raised no objections. Months into the program, he announced he had engaged a separate consulting partner, designed his own security requirements, and that nothing would leave the datacenters until his scorecard was satisfied.

The incentive conflict was visible before the first meeting. His metrics were tied to security posture. A successful migration would require accepting transition risk. Those two things were not compatible, and nobody had a conversation about it before the kickoff.

What looked like support was the absence of declared opposition. Those are not the same thing.

Before the initiative is announced, map every leader with meaningful power to accelerate or veto the work. For each one, ask a single question: if this initiative succeeds but their metrics stay flat, will they prioritize it? If the answer is no, that conflict must be resolved before the announcement, not managed afterward.

This is the most politically difficult of the seven disciplines because it requires telling powerful people that their current metrics are misaligned with what the organization needs to accomplish. That conversation is uncomfortable. It is far less expensive than the alternative: discovering the conflict six months into the program when the cost of surfacing it has grown to match the cost of continuing to work around it.

The resolution does not always require changing compensation structures. Sometimes it requires a direct conversation in which a potential resistor understands that the conflict has been seen and will be escalated if not addressed. In every case, it requires that the conversation happen before the announcement, not after.

Silence before a kickoff is not alignment. It is latency.

3. Redesign the delivery system before you ask it to carry new work

Process failure is rarely a people problem or a tools problem. Skilled people working inside broken handoffs produce broken outcomes. The strategy is not executed; it is negotiated, one handoff at a time.

Enterprise sales organizations provide a visible case. When deal cycles stretch well past what the market would otherwise require, the instinctive diagnosis is a sales problem. The accurate diagnosis is almost always a process problem. The friction is built into the handoffs between legal, security, procurement, and technical review. Each function designed its handoffs for a different context. Nobody redesigned them when the context changed. The revenue consequence is visible. The design failure that produced it is not.

Before the new initiative depends on existing processes, map how work actually flows from input to outcome. Not how it is supposed to flow. How it actually flows. Find every handoff that adds time without adding value. Redesign or eliminate it before the new work lands on top of the old machinery.

What this requires is process authority: the ability to change handoffs that cross functional boundaries. That authority often does not exist at the program level. It requires escalation, and the willingness to create conflict with functional leaders who built their processes legitimately and see no reason to change them for a program they are not fully convinced will succeed.

That conflict belongs before the launch, not after. After the launch, the program depends on those processes. Before the launch, the processes are still negotiable.

4. Test organizational readiness before you deploy the technology

There is a moment in every technology cycle when external pressure to deploy outpaces organizational capacity to use what is being deployed. The urgency is real. The readiness question gets framed as resistance to it. That framing is the problem.

Deloitte’s State of AI in the Enterprise 2026, surveying 3,235 senior leaders across 24 countries, found that only one percent of organizations describe themselves as AI-mature, while 88 percent are actively deploying. The gap is not a technology gap. The technology works. The organizations deploying it are not yet organized to use it well.

The cost of that gap is measurable. Research published in HR Executive drawing on a Forrester survey of 600 HR professionals found that 90 percent of organizations that conducted AI-driven layoffs to create capacity for AI work did not have AI systems ready to fill the gaps. Sixty-six percent have since rehired some of those employees. The urgency created the decision. The organizations absorbed the cost.

The readiness test runs across three dimensions. Strategic readiness: does every team that will use this technology understand what it is supposed to produce and how they will know if it is working? Process readiness: have the workflows been redesigned to take advantage of what the technology actually does, rather than wrapping the technology around existing process? Capability readiness: do the people who will use it have the skills and the authority to use it differently than what they already have?

Before significant technology deployment, ask the readiness question honestly and in advance. If you removed this technology tomorrow, would the organization still agree on how the work should happen? If the answer is no, the organizational work must come first.

5. Build the momentum system before you need it

Most initiatives do not fail dramatically. They fade.

The launch was real. The intent was genuine. The executive sponsor was engaged. And then something else became urgent. The sponsor’s attention moved. The steering committee continued meeting. The status reports continued being filed. Nobody declared it over. The initiative just gradually stopped being fed.

This is one of the most consistent findings across large-scale change work. Activity continues after momentum is gone because the organizational system produces incentives to report progress whether or not progress is happening. The governance structure that was designed to catch problems is operating on information filtered through every layer of the organization before it arrives.

Name the momentum owner before the launch. A specific person whose job it is to keep the initiative alive when the sponsor is managing something else. The role is distinct from the program manager (responsible for execution) and the executive sponsor (responsible for resources). The momentum owner is responsible for the ongoing vitality of the work: reading the signals, catching the drift, escalating when intervention is required.

Write the stall definition before anyone needs to interpret it under pressure. A momentum stall looks like declining cross-functional engagement, status reports that have become formulaic, steering committee attention that has shifted elsewhere. Name those signals explicitly and assign them thresholds before the first steering committee meeting, not after.

The test: can you name, right now, the person who will own momentum six months after launch when the sponsor is managing three other priorities? If not, the momentum system does not exist.

6. Sequence for value, not just for completion

Large-scale initiatives are almost always designed around a completion horizon. The value is real. But it arrives at the end. In the meantime, the organization is asked to invest time, money, and disruption in exchange for a promise. Boards tolerate it. Budget cycles challenge it. And the people absorbing the disruption and additional load are asked to keep going on faith.

Most of them will not wait that long without something to show for it.

Design the sequence of work so that real value arrives early and regularly. The difference between a proof of concept and a delivered result is not a technicality. A proof of concept tells the organization the approach might work. A delivered result tells the organization it is working.

Before the launch, identify what the initiative will deliver in the first ninety days that is real, visible, and financially meaningful. That question forces a sequencing discipline most long-horizon initiatives skip. The natural instinct is to build the full platform before delivering anything. That instinct is frequently wrong. The initiative that delivers nothing for eighteen months while promising everything at month twenty-four is asking for a level of sustained organizational faith that most cultures cannot provide.

The test: if the initiative were cancelled at month six, would anyone outside the program team have seen any benefit from what had been delivered? If not, the sequence has been designed for completion, not for value. Designing for completion and designing for value produce different sequences, different early milestones, and different levels of sustained organizational support.

7. Design for adoption, not announcement

Most transformations are designed around a launch event. The organization-wide announcement goes out. In that moment, the initiative activates every skeptic simultaneously. The people least ready to change, most invested in the current state, and most likely to interpret the announcement as a threat rather than an opportunity, all receive it at once.

The energy of the launch disperses across engaged adopters, wait-and-see observers, and active resistors simultaneously. The program spends its early months managing resistance that a different design would have avoided.

Adoption does not move in a straight line across a group. It moves through the group in a sequence. The people most ready to change adopt first. Their visible results change the calculus for the next group. By the time the skeptical majority is being asked to move, they are joining something that is already working, rather than being recruited into something that has not yet proven itself.

Instead of asking who needs to be informed of this initiative, ask who is most ready to move first. Identify the leaders, teams, or functions already closest to the desired state. Design the first phase entirely around them. Make participation in the first cohort selective. People who choose in are more committed than people who are assigned. Let the results of that cohort do the persuasion work that an announcement never can.

The test: have you identified the first cohort and designed the opening phase entirely around producing results with them? If not, the initiative has been designed for announcement. It has not yet been designed for adoption.

The Seven Disciplines

Before anyone is watching

The leaders who get this right are not operating on different information. They are operating on the same information most leaders have, and acting on it earlier, more specifically, and more honestly than the system typically rewards.

The seven disciplines are consistently skipped not because leaders lack awareness but because each one requires something the organizational system does not reward. Political confrontation before the problem is visible. Specific commitment before the outcome is certain. Structural investment before the pressure to act arrives. Resistance to urgency when internal conditions are not yet ready. The discipline to deliver something real before the organization is asked to keep believing in something that has not yet shown up. The patience to let adoption spread through demonstration rather than drive it through mandate.

The leader who does this work in the six weeks before launch will be doing invisible work. No milestone, no status update, no executive visibility. The work becomes visible only when the initiative continues to advance while similar efforts stall. When the outcome was defined before the kickoff. When the incentives were aligned before the announcement. When the handoffs were redesigned before the pressure arrived. When readiness was tested before procurement. When the momentum owner caught the drift early. When the value delivered in the first ninety days and the first cohort whose results made the case all produce something that looks, from the outside, like a well-run program.

It is not well-run execution. It is deliberate preparation.

The preparation happens before anyone is watching. That is what makes it hold.

Eight questions before the launch

1. Have you defined the outcome in terms specific enough to be proven wrong, in language every leader describes the same way?

2. Have you mapped every leader with veto power and resolved the incentive conflicts before the announcement?

3. Have you redesigned the handoffs the new work will depend on before the new work lands on top of them?

4. Have you tested organizational readiness across strategy, process and capability, before procurement?

5. Have you named the momentum owner and written the stall definition before anyone needs to interpret it under pressure?

6. Have you committed to a real, visible and financially meaningful result inside the first ninety days, not a pilot, not a proof of concept, but a delivered outcome?

7. Have you identified the first cohort and designed the opening phase entirely around producing results with them?

8. Have you confirmed you have been given the standing to do this work, or is the first task renegotiating the role itself?

Citations

McKinsey & Company, The State of Organizations 2026. Survey of more than ten thousand senior leaders; published February 19, 2026. Statistic cited: 56 percent of C-suite executives report clarity on strategic priorities; 27 percent at middle management.

Deloitte, State of AI in the Enterprise 2026. Survey of 3,235 senior leaders across 24 countries; January 2026. Findings cited: one percent of organizations describe themselves as AI-mature; 88 percent are actively deploying.

Forrester research, reported in HR Executive, “The truth behind AI-driven layoffs: 90% of companies aren’t ready,” January 16, 2026. Drawing on Forrester analyst J.P. Gownder. Finding cited: 90 percent of companies conducting AI-driven layoffs to create capacity for AI work did not have mature AI systems ready to fill the gaps.

Careerminds, survey of 600 HR professionals who had executed layoffs in the prior twelve months, conducted February 2026, reported in HR Executive. Finding cited: approximately two-thirds of organizations that conducted AI-driven layoffs had already rehired some of the people they let go.

The adoption sequencing argument in discipline 7 draws on the diffusion of innovations research tradition, most fully articulated in Everett M. Rogers, Diffusion of Innovations, fifth edition (Free Press, 2003) and applied to organizational culture by Simon Sinek in “How to Make a Cultural Transformation” (YouTube, 2020). The argument as developed here is the author’s own synthesis.

This is Paper 5 in the Why Change Fails series. Start with Paper 1: The Five Breakpoints Leaders Miss

Agentic AI doesn’t introduce organizational failure. It removes the slack that used to hide it.

A software development team deployed a multi-agent system to handle a moderately complex code review and refactoring workflow. The agents worked correctly in isolated tests. In production, across longer tasks, something predictable started happening.

As the workflow extended, the agents began losing the thread. Context established early in the task dropped out of reach. Agents continued executing confidently, producing coherent-looking outputs that had quietly drifted from the original requirements. The team did not catch the drift until they reviewed the final output against the original specification.

The failure was not in any individual agent. The agents did exactly what they were built to do. They did it on a progressively degraded version of what they were supposed to be building.

The architecture had no mechanism for maintaining purpose across the workflow. No checkpoints. No persistent memory layer. No escalation path back to the original intent.

That is the organizational design problem of agentic AI in miniature.

The failure is not primarily technical. The agents were capable. The system around them lacked the conditions any sustained effort requires: clear purpose maintained across handoffs, ownership of escalation, capable architecture for coordination and monitoring that catches drift before it becomes expensive.

The same conditions that determine whether human transformations succeed determine whether agentic systems do. What changes is the speed at which their absence becomes visible.

The argument is simple: AI doesn’t remove the need for stewardship. It removes the slack that used to hide its absence.

Routing and Stewardship Are Not the Same Thing

A significant portion of management work has historically been communication routing: scheduling, status updates, information distribution, basic decision propagation, summarization and the operational glue between people.

AI is genuinely good at much of that work. That is part of what has produced a wave of management-layer reductions across enterprises. If managers were largely communication routers and AI can route communication more efficiently, the layer can shrink. That argument is partially right.

There is a distinction the layer-reduction conversation keeps missing.

Routing and stewardship are different functions. Stewardship is interpretation, ownership, judgment, escalation and ongoing adjustment. It is the work of maintaining the conditions that keep execution connected to purpose. It is knowing when the answer is technically coherent but strategically wrong. It is noticing when a workflow is still active but no longer moving toward the outcome. It is deciding whose interest governs when an agentic system has multiple plausible paths.

Those functions require carriers. They may be redesigned. They may be concentrated in fewer people than before. But they do not disappear because routing got cheaper.

When organizations eliminate management layers without explicitly reassigning stewardship, the four forces lose their carriers. The breakpoints don’t disappear. They accelerate.

This is the mistake many AI restructurings risk making. They correctly identify routing work that technology can absorb, then cut the human layer that also carried informal interpretation, escalation and judgment. The spreadsheet shows efficiency. The operating system loses a stabilizing function.

The question is not whether management layers should shrink. In many cases, they should. The question is what work those layers were actually carrying. If the layer existed primarily to route information, AI should reduce it. If the layer carried stewardship, that function has to be deliberately rebuilt somewhere else. Otherwise the organization hasn’t become more efficient. It has removed the people who noticed when the system was drifting.

AI as Diagnostic

The clearest empirical signal of where the field stands is the widening gap between AI deployment and business impact. McKinsey’s State of Organizations 2026 found that 88 percent of organizations report deploying AI, and 88 percent saw no meaningful bottom-line impact. South Korea’s Hana Institute of Finance independently characterized the same pattern as the “AI productivity paradox”: individual productivity rising while organizational performance stays flat. Their prescription was not more pilots. It was workflow redesign, organizational restructuring, workforce upskilling and active executive leadership.

That is the same argument this series has been building toward. The tools are capable. The organizational system around them is not.

AI deployment is not just an implementation challenge. It is a diagnostic. It exposes whether the prior work has been done, faster and with less forgiveness than anything that came before.

A vague outcome can let three human teams interpret success three different ways and still produce reasonable-looking work. In an agentic system, that ambiguity either gets resolved up front or governed continuously, because the agent will execute one interpretation confidently and at scale. Strategic disconnection that took six months to surface in human execution can show up in six days in agentic execution.

The wiring will expose every undocumented handoff. The informal coordination human teams invented to survive a broken process, the workarounds, the side conversations, the personal favors that made the official process functional, does not exist when agents replace humans at handoff points. The capability gap that was hidden by human improvisation becomes visible immediately.

Either someone owns the escalation path or the system runs without one until something breaks visibly. Quarterly reviews will not catch agentic drift. The momentum gap that allowed six months of activity to mask declining movement gets compressed into weeks.

Vague purpose, undocumented handoffs, unclear escalation ownership, momentum that depends on individual attention rather than designed reinforcement: all of it surfaces. AI deployment is where prior choices about organizational conditions come due.

That is the most underappreciated value of AI deployment. It tells the truth about the organization around it.

The five breakpoints from the first piece show up in AI deployments with less delay and less disguise. Organizations whose four forces are already stewarded will absorb AI more effectively. Organizations whose forces are not stewarded will discover the gaps faster than they expected, and at greater cost.

The Window

Earlier technology transitions followed a similar pattern.

In the shift from mainframe to client-server and again from client-server to cloud, the organizations that built durable advantage were not simply the ones with the most resources or the earliest access to the technology. They were the ones that reorganized fast enough to build capability without legacy friction holding them back. The cloud laggards made real technology investments but tried to absorb cloud through structures built for the on-premises era.

The same pattern is forming around AI.

KPMG’s 2026 Adaptability Index found that 81 percent of boards have raised their adaptability expectations while only 30 percent of organizations report the ability to reconfigure quickly. That gap is not closing on its own. The technology is moving faster than the organizational redesign that would let companies use it.

The structural design choices made in 2026 and 2027 will determine competitive position for the next decade. Organizations that align the four forces around AI-native operations will build advantages that compound. Organizations that bolt AI onto misaligned conditions will not be held back by the technology. They will be held back by the same four forces this series has been about, now operating under conditions that make the absence of stewardship more expensive than it has ever been.

AI does not make purpose, commitment, capability or momentum easier to maintain. It makes gaps in those forces harder to absorb and more expensive to ignore.

The Question AI Makes Harder to Avoid

This is what the series has been building toward.

The Five Breakpoints named the failure patterns. The Stewardship Gap traced them to four conditions that need stewardship most leaders never explicitly assign. Designed to Stall argued that the design work behind that stewardship is reliably skipped because the system rewards skipping it.

This piece argues that AI is the moment when all of that gets stress-tested in real time. The test results come back in months rather than years.

The question is not whether your organization will use AI. It already does, or soon will. The question is whether the organizational conditions exist for AI to produce what the technology investment depends on producing.

AI will not wait for organizations to become coherent. It will accelerate whatever coherence or incoherence already exists.

That is why the question is no longer whether the organization is active, innovative or experimenting. It is whether the organization has been designed so that AI can create value without scaling drift.

Can you tell, right now, whether yours has?

Citations

McKinsey & Company, The State of Organizations 2026. Survey of 10,018 senior leaders across 16 countries, published February 19, 2026.

Hana Institute of Finance, South Korea, “AI Fails to Connect Worker Productivity to Organizational Performance,” reported in Korea Times, May 3, 2026.

KPMG, 2026 Adaptability Index.

Microsoft AI Red Team, “Taxonomy of Failure Mode in Agentic AI Systems,” April 24, 2025.

This is Paper 4 in the Why Change Fails series. Start with Paper 1: The Five Breakpoints Leaders Miss

There is a leader at most major enterprises right now who can see why their transformation may stall, has some authority to prevent it and will still be pulled toward choices that leave the stall pattern intact.

That is not mainly a story about weak leaders. It is a story about rational leaders operating inside an accountability system that rewards visible motion, diffuses consequences and treats structural design as optional until the damage is already visible.

The 70 percent transformation failure rate has held steady across decades. It has survived Six Sigma, agile transformation, lean methodologies, change management certification and an entire industry of consulting frameworks. Most leaders who have been through this cycle more than once can name the patterns themselves. The diagnosis is not the problem. The work that the diagnosis points to keeps not getting done.

The downstream consequence is the pattern most readers will recognize. The program stalls. A retrospective is convened. The findings are familiar: timeline was aggressive, scope was too broad, change management was insufficient, organizational readiness was misjudged. Accountability lands one or two levels below the actual decision point. The program director is replaced. The consulting firm is blamed. The VP who agreed to the scope has been promoted. The CFO who set the timeline has signed off on the post-mortem. The leader who declined to address the structural issues at launch is at the next company.

I have watched this play out across enough transformations to recognize that the post-mortem above is not a parody. It is the median outcome. The same five breakpoints reappear in the next transformation. The same four forces go unstewarded. The same design decisions get skipped.

“The Five Breakpoints” described the visible failure patterns. “The Stewardship Gap” traced them back to the underlying conditions that have to be sustained. This piece takes on the harder question: if the diagnosis is widely available and the prescription is understood, why does the failure rate hold?

The argument is that 70 percent is not a knowledge gap. It is a structural feature of how leadership accountability works in modern enterprises. Telling leaders to be different leaders has been the field’s response across decades. It has not moved the number. Moving it requires changing the system, not just the people inside it.

Why Leaders Skip the Design Work

Three pressures, all individually rational, push the design work off the leader’s plate. Each one alone would weaken the design discipline. Together, they make skipping it the path of least resistance.

Skill gravity

Senior executives are real experts in customer engagement, product judgment, operational firefighting and managing the board. Those activities produce visible results quickly and feel like leading. Organizational design is structural, slow, produces no short-term signal that anyone tracks and requires political confrontation with peers. It gets crowded out. The layer that should own it most, the group just below the CEO, is the layer most consumed by upward management and execution crises. The work falls in the gap between strategy above and delivery below. It belongs to everyone in theory and to no one in practice.

The feedback gap

Senior executive tenure averages around four years and is shorter for many transformation-era roles. Major organizational design decisions take 18 to 36 months to produce visible consequences. Most leaders who skip the design work will not be in the role when the transformation stalls. Accountability diffuses by the time the consequences arrive. The failure lands in the delivery layer, while the design choices that made the failure likely remain largely unexamined. There is no corrective feedback loop, so the same choices get made again by the same kind of leader.

Career calculus

Senior executive roles carry significant compensation and, for many leaders, real financial stakes. A real transformation effort means visible risk: political conflict, short-term disruption that looks like underperformance before it looks like progress and the possibility of being the person associated with a failed initiative.

There are softer alternatives that avoid most of that risk: a reorganization that signals decisiveness without redesigning incentives, a technology investment that demonstrates activity without requiring process change, a communications campaign that updates the language without changing the operating model. The board’s visibility into the difference is limited in the early years, and each leader who responds incrementally leaves the organization slightly more resistant to the next genuine attempt.

These are not character flaws in individual leaders. They are predictable responses to a system that rewards visible action over structural design, distributes consequences across a longer time horizon than tenure and treats incremental motion and substantive change as equivalent for purposes of board reporting and analyst calls.

What “Better Leaders” Does Not Fix

The dominant response from the change management field, across decades, has been to address this through training, certification, methodology and exhortation. Tell leaders what good design looks like. Show them frameworks. Make the case for sustained executive sponsorship. Across the same period, the failure rate has not moved.

The clearest case study is the Lean Manufacturing transplant phenomenon of the 1990s and 2000s. Hundreds of major manufacturers across automotive, aerospace, electronics and pharmaceuticals sent executives to Toyota for benchmark studies. They hired consultants steeped in the Toyota Production System. They implemented kanban systems, established lean centers of excellence, certified internal practitioners and adopted the methodology with high fidelity.

The pattern documented across decades of subsequent research was consistent: implementations that adopted the visible methodology without the underlying structural commitments produced sustained results in roughly the same proportion as the broader transformation literature suggests. The visible tools transferred. The deeper conditions did not. The frameworks were correctly applied. The structural conditions for them to work were not.

The strongest predictor of whether a leader does the design work is whether the structure penalizes skipping it. Training and frameworks improved over the same decades. The rate did not move, because the structural incentives that produced the skipping behavior were never altered.

The path to moving the failure rate goes through structural change. The rest of this piece is about the mechanisms that shift leader behavior at scale, inside the same set of human pressures.

Why Stewardship Alone Is Not Enough

“The Stewardship Gap” argued that the four forces, Purpose, Commitment, Capability and Momentum, each need a stewardship function with a named owner. That argument holds. But naming a steward is not enough.

Stewardship without structural support produces the dynamic anyone who has sat in one of those roles will recognize: responsibility for the gap, authority over neither side.

This is the DevOps pattern at scale. A common adoption pattern for DevOps was to take what was meant as a cultural change and operationalize it as a third team inserted between Development and Operations. Dev kept the speed mandate. Ops kept the stability mandate. DevOps became the steward of the gap with no power to change behavior on either end of it. Both sides now had somewhere to send problems they did not want to own. The DevOps team absorbed the blame for failures caused by the relationship between Development and Operations, not by the team itself.

The same pattern shows up in Chief Transformation Officer roles, Program Management Offices asked to drive transformation across functions, Centers of Excellence responsible for adoption without authority over the functions adopting and product operations teams tasked with cross-functional coordination while reporting into one of the functions they are trying to coordinate.

Stewardship without structural authority is worse than no stewardship at all. It signals that the work is being addressed while ensuring that it cannot be, absorbing the political pressure that would otherwise force structural change. The breakpoint pattern continues, now with a designated absorber.

Naming a steward is the first step. The harder step is building the structure that makes stewardship rational to take, possible to execute and consequential when ignored.

Six Structural Mechanisms

The mechanisms below are not six tips. They are interventions in how the organization structures recognition, accountability and tenure around transformation work. The current system has a cost too: capital waste, organizational fatigue, missed opportunity and another post-mortem that names the execution problem while missing the design decision that made the failure predictable.

The first three change accountability. The second three strengthen organizational memory, commitment and design capacity. Any organization that adopts even three of them seriously will see the failure rate move.

Mechanisms That Change Accountability

1. Stewardship lines that survive sponsor turnover

Most stewardship roles report into the executive sponsor. When the sponsor moves, the steward loses the authority that made the role functional. The transformation continues nominally. The energy disappears.

The structural fix is to give stewardship roles a reporting line that does not collapse when the sponsor changes. In practice, this often means direct reporting to the CEO or COO rather than the functional sponsor, independent reporting on transformation health to the board separate from the sponsor’s status updates and a formal handoff protocol when the sponsor changes. The new sponsor has to either reaffirm or restructure the stewardship roles. They cannot quietly starve them.

In many enterprises, this configuration takes the form of an Office of Transformation reporting directly to the CEO or COO. The configuration only works if the office has actual decision authority over the transformation, not just monitoring authority. The most common failure pattern is to create one with weak political backing, which becomes a PMO under a different name. The reporting line is necessary. The authority that comes with it is what determines whether the steward can act on what they see.

2. Pre-committed stall protocols

Most transformations have no formal definition of stalled. The judgment is left to the sponsor, the program team or whoever is reading the status reports. Activity continues. The conditions for action are vague. Drift becomes recognizable only in retrospect.

Pre-committed stall protocols define, before launch, what specific signals indicate that the transformation is losing force and what specific action follows at each level of severity.

Early-stage drift, like sustained slippage in decision velocity beyond an agreed number of business days, triggers structural review of decision rights at the executive committee level. Mid-stage drift, like rollout adoption falling below an agreed percentage at the 90-day mark, triggers mandatory readiness assessment with the CEO and a redesign of the rollout approach. Severe drift, like quarterly milestone completion below an agreed percentage for two consecutive quarters, triggers escalation to the board with the possibility of program restructuring.

The tiering matters. Every signal does not need to go to the board, but every level of severity needs a defined response that the political weather of the moment cannot soften.

3. Compensation tied to multi-year transformation outcomes

Most senior executive compensation is structured around annual cycles. Major transformations produce results across 18 to 36 months. The mismatch is structural and produces the skip behavior described above.

A meaningful share of executive compensation, not a token slice, is tied to specific multi-year transformation outcomes. Transformation-tied compensation vests over the original time horizon, regardless of role changes. The leader is exposed to the consequence of their own design choices, even after moving into the next role internally.

This pattern is most visible in sales organizations, where compensation rewards the close while the cost of a bad close is paid in installments by customer success teams, implementation partners, product teams handling commitments they did not sign up for and the customer. Most enterprises do not restructure the misalignment because sales talent is mobile and will not accept pay at risk for outcomes that depend on functions outside their control. The result is a stable misalignment that everyone names and no one fixes. The same dynamic operates at the executive level for transformation work.

There are working examples of the structural change. Microsoft’s cloud transition under Satya Nadella included a restructuring of executive long-term incentive grants tied to multi-year cloud adoption outcomes, exposing senior leaders to the consequences of decisions that would unfold over years rather than quarters. Berkshire Hathaway has structured executive compensation around long-term outcomes for decades and Warren Buffett has written extensively about why most peer companies have not followed. These examples are notable precisely because they are exceptions.

A note on equity, which is technically multi-year. Equity ties executives to stock price, which is market perception, and under quarterly pressure can drift toward managing perception rather than producing the operational outcomes the transformation requires. The tie this mechanism describes is to specific transformation outcomes measurable independently of market perception: customer retention, operating efficiency, organizational adaptability.

This is the mechanism that most directly addresses the feedback gap. It is also the one most boards and executive committees resist, because it changes the relationship between executive authority and personal financial outcome. The resistance is the signal.

Mechanisms That Strengthen Memory, Commitment and Design Capacity

4. Hard-to-reverse architectural commitments at launch

Most transformations are launched with reversible commitments. The board approves a budget that can be cut. The sponsor announces a timeline that can be revised. The program structure can be reorganized. The reversibility is what makes incremental retreat possible. The retreat is the dominant failure mode.

Hard-to-reverse commitments at launch raise the political cost of incremental retreat: external commitments to customers tied to transformation milestones, public board commitments with named accountability, contractual dependencies that make alternative paths visibly expensive and architectural decisions that lock in the transformation’s structural premises before the political pressure has time to soften them.

Amazon’s 2006 commitment to launch AWS as a public business is a working example. The customer-facing service contracts, the public pricing commitments and the technical investment levels could not be quietly walked back. The structural commitment made retreat costly enough that the organization continued forward through periods when the business case was not yet proven.

The contrasting pattern is IBM’s repeated reversibility around cloud strategy across multiple CEO transitions, which produced the corresponding reversibility of organizational commitment. The technology was comparable. The structural commitment was not. The resulting market position differed by an order of magnitude.

When retreat is structurally easier than continuation, organizations retreat.

5. Post-mortem discipline that names the skipped design decision

Most transformation post-mortems identify execution issues. The timeline was aggressive. Change management was insufficient. Organizational readiness was misjudged. These findings reach the program team and the consulting firm. They do not reach the design layer.

A disciplined post-mortem identifies not only what went wrong in execution, but what design decision at launch made the failure predictable. The findings reach the executive who made or skipped that decision. The pattern is documented. The next launch is required to address it.

Without this, the same skipped design decision produces the same breakpoint at the next transformation. This requires post-mortem authority that does not report into the leadership that authored the decisions being reviewed. Most organizations do not have this. Building it is the work.

6. A standing organizational design function

Organizational design is treated in most enterprises as a special-purpose activity. It happens during reorganizations. It happens during M&A integrations. It happens when a transformation is announced. It does not happen as continuous work owned by a function whose career depends on doing it well.

A standing organizational design function exists to do the work between transformations. It maintains the operating model. It surfaces structural friction before it becomes a transformation breakpoint. It has the authority to recommend structural changes outside the cycle of major announcements. It is staffed by people whose careers are advanced by structural quality, not by the success of any single initiative.

It exists to map actual work flow against formal process and identify structural friction across functional boundaries. It needs explicit mandate to recommend cross-functional changes, reporting authority to the CEO and political standing to challenge senior leaders who would otherwise prefer to keep their functional structures intact. It should be measured on structural improvement outcomes, not project completion.

The function should avoid becoming what many strategy and operations groups become in practice: a delivery arm for leadership-defined initiatives without the mandate or standing to challenge senior leaders. Over time, that kind of function comes to accommodate existing silos rather than address them, accumulating the dysfunction it was meant to prevent.

What This Changes

The six mechanisms have a common structure. Each one shifts the rational response to a transformation moment. The steward with structural authority acts on what they see. The leader whose compensation is tied to multi-year outcomes invests in design before launch. The team that knows the post-mortem will trace failures to design decisions stops skipping them. The board that has to undo a public commitment to retreat thinks harder before retreating.

Build these mechanisms into the system and the failure starts landing at the design layer where it originated. Leaders make different choices. Not because they have become better leaders, but because they are rational leaders operating inside a different structure.

The Honest Trade

Implementing the six mechanisms is not free. Boards lose some flexibility. Executives lose some upside optionality. The organization commits to a longer accountability horizon than the typical political cycle inside the company.

There are real reasons most enterprises have not adopted these structures. They are tradeoffs that historically went the other way. The argument of this piece is that the tradeoff has become harder to defend. The 70 percent failure rate is not an anomaly. It is the equilibrium produced by the current design. The cost of that failure rate, in capital, in opportunity, in organizational fatigue and in the credibility of leadership itself, is large and growing. Doing the structural work to move it costs less than the current arrangement does.

I have watched leaders see this clearly and still reach for the soft alternative because the structure rewarded it. The mechanisms above do not require those leaders to behave differently. They change the structure those leaders are operating inside.

The leaders who do this work first will operate inside a structurally different organization than their peers. They will be the ones building the cases that other leaders eventually point to as proof that the failure rate can move. For everyone else, the post-mortem pattern at the opening of this piece keeps repeating and the number keeps holding.

That raises the question for the next piece: what happens when AI enters organizations that were already designed to skip the work that transformation requires?

Citations

McKinsey & Company, multiple studies on transformation success rates published since 2009, with the most recent figures in The State of Organizations 2026, published February 19, 2026. The 70 percent figure has been independently corroborated in published research from BCG, KPMG and Bain across the same period.

Senior executive tenure data: a composite estimate drawing on Korn Ferry, Spencer Stuart and Crist|Kolder annual studies of CEO and C-suite tenure, most recent editions, 2024 to 2026. Average tenure has been declining across most C-suite roles for the past decade.

Lean Manufacturing implementation outcomes: see Liker, J., The Toyota Way, McGraw-Hill, 2004, for the original methodology framing, and Hines, P., Holweg, M. and Rich, N., “Learning to evolve: A review of contemporary lean thinking,” International Journal of Operations & Production Management, 2004, and subsequent literature for documentation of implementation failure rates and the structural conditions that distinguished successful from failed transplants.

Microsoft cloud transition compensation restructuring: documented in Microsoft proxy statements 2014 to 2020 and analyzed in Eichenwald, K., “How Microsoft Lost Its Mojo,” Vanity Fair, 2012; and Nadella, S., Hit Refresh, HarperBusiness, 2017.

Berkshire Hathaway compensation philosophy: see annual letters to shareholders, particularly Buffett, W., 2005 and 2017 letters, on the structural problems with conventional executive compensation.

AWS launch and structural commitment: documented in Stone, B., The Everything Store, Little, Brown, 2013, and Amazon Unbound, Simon & Schuster, 2021, and corroborated in Amazon shareholder letters from 2006 onward. IBM cloud strategy reversibility documented in IBM annual reports and analyst coverage across CEO transitions.

This is Paper 3 in the Why Change Fails series. Start with Paper 1: The Five Breakpoints Leaders Miss

A senior leader at a healthcare firm had done the hard work. He had diagnosed the transformation clearly, named the failure pattern and traced where the original purpose had fragmented between the executive vision and the vice presidents tasked with delivering it. He brought it to the steering committee. They agreed. They cited it in the next quarterly review.

Six months later, the breakpoint was still there. Slightly worse, now with documentation.

Most transformation failures are not mysteries. The leaders involved usually know something is wrong. They can name it. They discuss it in reviews. And then the same pattern appears in the next update, slightly worse, with more documentation.

The first piece in this series was about recognizing those breakpoints. This piece is about why recognizing them often does not change them.

The diagnosis was complete in the healthcare case. There was no one whose job it was to act on it. The executive sponsor owned the program. The vice presidents owned their functions. No one owned the gap.

Call this the stewardship gap: the space between knowing what the transformation needs and having someone whose explicit job it is to keep that work alive once the launch energy is gone.

In “The Five Breakpoints,” I described five predictable failure patterns that show up across large-scale change: strategic disconnection, incentive fragmentation, process friction, technology illusion and momentum mirage. Underneath those patterns are four conditions on which transformation success depends: Purpose, Commitment, Capability and Momentum. Most transformations launch with all four intact, at least on paper. They fail because no one is responsible for sustaining them once the original energy fades and the operating pressure arrives.

Closing the stewardship gap is the difference between transformations that move and transformations that report progress while losing force.

Four Forces, Four Stewardship Functions

The Four Forces are not steps in a change model. They are simultaneous conditions that must be present and maintained throughout a transformation.

Purpose is the shared definition of what success looks like. Commitment is the fuel that keeps the work prioritized when tradeoffs appear. Capability is the organizational machinery that allows it to actually move. Momentum is the velocity that sustains progress after launch.

When all four are active, transformation moves. When any one weakens, you get a breakpoint. Most transformations have all four at kickoff. The question is who maintains them when the organization gets busy, when competing priorities show up and when the original energy dissipates.

Forces do not sustain themselves. Each needs a stewardship function with a named owner.

Purpose is not announcement. Commitment is not endorsement. Capability is not talent or tooling. Momentum is not activity. Most leaders understand the forces intuitively. Few design the stewardship for those forces before the pressure arrives.

Purpose, Carried by Interpretation

An organization launched a cloud migration with a stated goal of improving deployment speed. The infrastructure team heard “reduce ticket resolution time.” The security team heard “maintain compliance posture.” The application teams heard “get off legacy hardware.” All three were defensible readings of what had been announced. None of them were the same outcome.

A year later, the migration had produced new infrastructure, a new compliance framework and faster hardware. Deployment speed had not changed.

Purpose, in the context of transformation, is not a values statement or a strategic direction. It is a specific, measurable definition of what success looks like that every team, at every level, would describe the same way if asked. The bar of getting that level of agreement across an entire organization is harder to clear than most leadership teams expect.

McKinsey’s State of Organizations 2026 report, drawing on more than 10,000 senior leaders across 16 countries, found that 56 percent of C-suite executives reported clarity on their organization’s strategic priorities. At middle management, that number dropped to 27 percent. A 29-point collapse across a single organizational layer.

What looks like a communication failure is more accurately a structural feature of how information moves through layered organizations. Strategy does not simply cascade. It gets retold, and each retelling changes it. Frederick Bartlett’s serial reproduction research from 1932 showed that information passed through a chain of people degrades predictably at each handoff. Three layers between an executive team and execution means strategy is effectively retold three times before it becomes action.

The stewardship function for Purpose is interpretation. That is different from announcement and from documentation.

Interpretation is the ongoing work of translating enterprise outcomes into team-level definitions of what success looks like this quarter, in this workflow, for this team. Done well, it produces the difference between a strategy people have heard about and a strategy people are actually working from.

Someone in your organization must own that work continuously. They must surface divergence early, when it can still be corrected, rather than discovering at a quarterly review that three teams have been optimizing for different outcomes. They must maintain coherence when conditions change and update the definition of success before teams are left guessing.

In the cloud migration case, the executive team treated the announcement as the work. The interpretation was left to each function. Three functions interpreted three different outcomes. There was no stewardship of the meaning. The result was three reasonable answers to three different implicit questions, none of which was the question the transformation had set out to answer.

Self-check: Who in your organization is actively maintaining the definition of success, not just announcing it?

Commitment, Carried by Ownership

An insurance company launched an AI-driven claims triage initiative with a clear mandate from the C-suite. Months later, the adjusters were still running dual processes: the AI model’s output alongside the manual review that had always existed.

When asked why, the answer was consistent across the team. No one had told them the manual process was no longer required and they were still being measured on claim accuracy.

The AI worked. The commitment had not been designed.

Commitment is the fuel of transformation. It shows up in budgets, in calendar time and most revealingly, in incentive structures. You can read an organization’s real commitments by looking at where money and time actually go under pressure, not at what was promised in the kickoff deck.

Commitment is not endorsement. It is the designed priority that holds when tradeoffs appear.

That distinction matters because commitment erodes. That is not cynicism. It is how organizations work under pressure. Competing priorities surface. Quarterly numbers create gravity. Leaders who fully intended to prioritize the transformation find that the incentive structures surrounding them make other choices more rational. Most organizations never explicitly design what commitment is supposed to look like once it becomes hard to maintain.

KPMG’s Adaptability Index, published April 2026 and based on surveys of more than 300 C-suite leaders, found that 81 percent of executives said boards had raised expectations for organizational adaptability, but only 30 percent said their organization could actually reconfigure structures, roles and processes quickly. Bain’s Live the Model survey of nearly 1,000 respondents found that only one in three felt personally motivated to adopt the new operating structure their organization was asking them to embrace.

The gap between expectation and capacity to act is the visible signature of weak commitment. Most boards mistake it for a strategy problem because the strategy is the easier thing to revisit.

The stewardship function for Commitment is ownership. That means named decision rights, designated accountability that cannot be reassigned to a working group, and an explicit check before the work launches on whether the incentive structures facing every leader with veto power over the transformation actually make prioritizing it rational. If they do not, that problem needs to be addressed before the announcement, not after.

In the insurance case, the C-suite read the announcement as the commitment. It was not. The measurement criteria the adjusters were judged on still rewarded the manual process they had always run and no one had explicitly retired that process. Both pieces of design work were skipped, so the organization absorbed the new tool into the old habits. The AI sat next to the manual review for months because the system gave the adjusters no reason to stop running both.

Self-check: For every team whose behavior has to change, do their measurement criteria reward the new state and has the old way been explicitly retired?

Capability, Carried by Architecture

A technology company invested in a new customer relationship management platform designed to align and accelerate handoffs between departments. The platform was well designed. The training was thorough.

Six months after launch, handoff failures had not declined.

The reason was not the technology. Each department still managed its own queue independently, with no shared view of which customers were transitioning between teams. The platform could show the information. The process for acting on it did not exist. Nobody owned the space between departments.

Organizations consistently overestimate their capability for transformation by looking at talent. They assess whether they have skilled people. They often do. But skilled people inside broken handoffs still produce slow, fragmented results. The bottleneck is rarely the person and almost always the structure they are working inside.

Capability is not about individual competence. It is the organizational machinery: how work moves, where decisions get made, how exceptions get handled and whether teams can coordinate across boundaries without losing time or creating conflict. These are the structural factors that determine whether good people can execute efficiently or whether they spend their energy navigating workarounds they have built to survive a process that no longer fits how the work actually flows.

McKinsey’s 2026 report found that 38 percent of respondents cited rigid structures as the primary barrier to transformation. That rigidity does not show up as a single dramatic failure. It shows up in handoffs that stall, decisions that escalate unnecessarily and processes that were designed for a different set of requirements but never redesigned. The workaround becomes the operating model. The official process becomes theater.

The stewardship function for Capability is architecture: designing how work flows across boundaries, where decisions live, how exceptions get handled and who owns the space between functions where most failures actually occur. Architecture is the work of identifying and removing the friction that forces skilled people to build workarounds inside their own organization.

In the technology company case, the platform was capable. The architecture was not. Who owns the customer as they move between departments? Who has authority to act on the shared view? What happens when a handoff fails? None of that had been designed. The result was a capable tool inside an incapable system.

Capability produces two of the five breakpoints. Process friction shows up when work cannot move through the system. Technology illusion shows up when leaders buy a tool and mistake it for the system. Both reveal the same missing stewardship: no one owns the architecture of how work actually moves.

Self-check: If you mapped how work actually flows today, would it look like the formal process or the workarounds your teams built to survive it?

Momentum, Carried by Reinforcement

A manufacturing firm launched an operational redesign with strong early momentum. New workflows were piloted. Early adopters were vocal supporters. The first 60 days showed real movement.

At the 90-day mark, the leader who had championed the change was pulled into other work. The redesign continued running on the original plan. But without someone actively watching for drift, teams had quietly reverted to the old process. They had not made a formal decision to revert. The new process had simply become more effort than the old one and nothing in the environment was reinforcing the change.

By the time the company ran a formal assessment, the old model had reclaimed the ground.

Momentum is the velocity that sustains transformation after the launch energy fades. It grows through early wins, visible progress and consistent reinforcement. It dies when organizations confuse activity with movement.

Momentum is not enthusiasm. It is not a kickoff. It is not the fact that people are still attending the meeting. Momentum is the organization’s ability to convert progress into confidence and confidence into continued action.

The launch is the event that gets celebrated. The leaders who drove it get recognized. Then the real work begins: the unglamorous, sustained effort of changing how an organization actually operates. And the reward structures largely go silent. Organizations are better designed to celebrate starting than to sustain finishing.

KPMG’s data makes this concrete. Only 9 percent of executives identified increased psychological safety as a key behavior change in their transformation. Only 24 percent made dynamic talent deployment a key change. These are not peripheral concerns. They are the conditions that allow people to raise problems early, shift resources to where they are actually needed and keep the work moving after the launch energy fades. When they are absent, the organization keeps reporting progress while momentum quietly bleeds.

The stewardship function for Momentum is reinforcement: a named person, distinct from the executive sponsor, who watches for drift, maintains short feedback loops and has the authority to intervene before a slide becomes a stall. This person does not just measure progress. They diagnose the difference between progress and performance, between teams that are actually moving and teams that are reporting activity to satisfy a stakeholder expectation. Without that distinction, a transformation can run for months producing convincing status updates while the underlying momentum is gone.

In the manufacturing case, the leader who left was the sponsor. There was no separate steward of the change. The activity continued because no one was responsible for the energy. By the time anyone looked, teams had quietly opted out, not through resistance, but through the absence of anyone making it harder to revert than to continue.

Self-check: Who in your organization is responsible for telling the difference between progress and performance on this transformation and what authority do they have to act on it?

Why Stewardship Is Hard to Staff

Naming the work is necessary. It is not sufficient.

Anyone who has worked inside a large organization will recognize a problem with the recommendation to name stewards for each of the four forces. Stewardship roles are structurally underrewarded.

Launches come with fanfare, executive visibility and credit. The steward inherits the work that follows, often including pieces of the launch that were never finished, and is measured against outcomes that take years to surface. The leader who declared victory at the launch has frequently moved on by the time the consequences arrive.

This is not a problem the steward can solve through better personal positioning. It is a design problem at the level of how the organization structures recognition, accountability and tenure.

There are partial moves that help, even inside an unchanged system. Before launching the transformation, name the stewards for each of the four forces. Modify their performance objectives so they are measured on sustained outcomes: adoption rates at twelve and twenty-four months, durable behavioral change and structural integration into how the organization actually works, not just launch milestones. Make the role visible enough at announcement that taking it carries real career upside, not just career risk. Pair launch sponsors with named stewards in formal communications, so the organization sees the two roles as equally consequential.

Naming stewards does not have to mean assigning four separate people. It means assigning four explicit functions. Interpretation and Reinforcement can often sit with one steward, since both involve maintaining coherence and surfacing drift. Ownership usually requires C-suite authority because it touches incentives, decision rights and executive tradeoffs. Architecture often belongs with the COO or with a designated operating model owner because it concerns how work actually moves across the organization.

No single existing enterprise role today does all four functions well. Chiefs of Staff often handle Interpretation informally but without the authority to make it stick. Chief Transformation Officers hold Ownership on paper but often with weak political backing. COOs sometimes do Architecture, depending on the company. Program Management Offices usually monitor Reinforcement-style indicators but lack the standing to intervene when drift appears.

The recommendation here is not to hire a new role by default. It is to assign the four functions explicitly, map them onto the existing leadership structure and give each function the political backing it requires.

None of this resolves the deeper structural problem. The system that rewards launches over sustainment will keep producing the dynamic at scale. But these moves raise the floor. They make stewardship visible enough to staff and concrete enough to measure, even before broader structural changes get made.

That raises the harder question for the next piece: if stewardship matters this much, why do organizations keep failing to support it?

The Difference Between Launching and Building

The Four Forces are shaping conditions in your transformation whether you are actively managing them or not. At any given moment, Purpose is drifting or being maintained. Commitment is eroding or being reinforced. Capability is calcifying or being redesigned. Momentum is building or bleeding.

None of those is static. Each moves in the direction the people responsible for it are pushing, including the direction of nobody pushing at all.

Most transformation leaders address these conditions reactively, after a breakpoint has appeared. The ones who build transformations that hold address them before launch. They name the stewardship functions explicitly, assign real ownership rather than implied ownership and build monitoring into the operating rhythm before the early energy fades.

A launch is an event that happens once. A build is a set of designed conditions that someone has to maintain, with named owners and the authority to act when those conditions begin to weaken.

The healthcare leader from the opening of this piece had the diagnosis. What he was missing was an owner for the function the diagnosis pointed to. The work of interpretation, the ongoing translation of strategic clarity across organizational layers, had no name attached to it, so it never happened. The forces were there at launch. The stewardship was not. That is the gap worth closing.

For each of your four forces, name the person whose job it is to maintain it. If the only name you can produce is the executive sponsor, you do not yet have a steward. The sponsor’s job is to launch, fund and unblock. The steward’s job is to keep the condition alive when no one else is watching. Conflating the two roles is what produces the breakpoint pattern that most transformations eventually report on and few ever recover from.

The harder version of the question, and the one most worth sitting with, is this: what would happen if you stopped actively managing this transformation for 90 days?

If the honest answer is that the work would keep moving without you, you have built stewardship into how the organization operates. If the honest answer is that the work would drift into status reports and lose force, you have not built a transformation yet. You have launched one.

Citations

McKinsey & Company, The State of Organizations 2026. Survey of 10,018 senior leaders across 16 countries, June to September 2025; published February 19, 2026. Statistics cited: 56 percent C-suite / 27 percent middle management strategic clarity; 38 percent of respondents identifying rigid structures as the primary barrier to transformation.

Bain & Company, Live the Model survey. 976 respondents across nine countries, September to October 2025. Statistic cited: only one in three respondents felt personally motivated to adopt the new operating structure.

KPMG, Adaptability Index 2026. Surveys of more than 300 C-suite leaders, published April 15, 2026. Statistics cited: 81 percent of executives say boards have raised expectations for adaptability; 30 percent say their organization can reconfigure quickly; 9 percent identified psychological safety as a key behavior change; 24 percent made dynamic talent deployment a key change.

Bartlett, F. C. Remembering: A Study in Experimental and Social Psychology. Cambridge University Press, 1932. Serial reproduction research demonstrating predictable degradation of information passed through chains of transmission.

This is Paper 2 in the Why Change Fails series. Start with Paper 1: The Five Breakpoints Leaders Miss

Organizations rarely fail to transform because they lack activity. More often, they fail because they were never designed to withstand the predictable pressures that large-scale change creates.

The roadmap exists. Governance is in place. Funding is approved. Milestones are green. Yet the business is not moving the way leaders expected. Teams are active without converging. Pilots are underway without scaling. Progress is being reported, but confidence is not increasing.

One executive described it to me this way: “It feels like youth soccer where everyone is kicking at the ball at the same time, but the ball still doesn’t move.”

That pattern shows up across cloud modernization, AI adoption, operating model redesign, customer transformation and broader business change. The surface details vary. The underlying failure patterns do not.

Across large-scale change efforts, the same five breakpoints tend to appear again and again. They are not random setbacks. They are predictable failure patterns that organizations often fail to design against, then fail to recognize early enough once they begin to surface.

Each breakpoint is a visible sign that one of the underlying forces of transformation has weakened: purpose, commitment, capability or momentum.

Leaders do not need another slogan about change. They need a way to design against predictable breakpoints before launch, then recognize the warning signs before drift becomes expensive.

1. Strategic Disconnection

The first breakpoint appears when a transformation is launched with broad intent but without enough precision to keep the organization aligned under real operating pressure. Leaders believe the strategy is clear, but the organization is operating from multiple versions of the outcome.

A healthcare organization launched a cloud transformation with visible executive support and strong early agreement. But each major stakeholder quietly interpreted the effort through the lens of their own function. Security processes would remain intact. Change windows would remain intact. Review paths would remain intact. No one openly resisted. No one had actually committed to the same destination.

A year later, the organization had new cloud platforms and an essentially unchanged operating model.

This is one of the most expensive failure patterns because it does not look like conflict at the start. It looks like consensus. That is what makes it dangerous: the organization has not aligned; it has only agreed not to disagree yet.

Leaders hear the same language repeated back to them and assume alignment exists. In practice, teams fill in the blanks with their own definitions, priorities and assumptions about what will or will not change.

The issue is not inspiration. It is precision.

A goal like “become more digital” or “use AI to improve customer experience” sounds aligned in a kickoff meeting and fragments in execution. A goal like “reduce customer resolution time by 40 percent within two quarters” gives teams a shared outcome they can translate into decisions, tradeoffs and accountability.

When strategic disconnection sets in, organizations do not usually stop moving. They simply begin moving in slightly different directions.

Self-check: If you asked ten leaders to describe the primary outcome of the transformation, would their answers actually match?

2. Incentive Fragmentation

The second breakpoint appears when a transformation depends on cross-functional cooperation but was never designed to align the incentives of the people whose decisions determine whether it moves. What looks like support early on often collapses once real tradeoffs appear.

A financial institution had a major migration effort underway with one deadline no one could ignore: datacenter leases were expiring. The VP of Data had aligned teams, built the business case and set the timeline. The CISO attended the planning meetings and raised no visible objection. Months later, he revealed that he had engaged a separate consulting partner, defined a different set of security requirements and that nothing would move until his scorecard was satisfied.

The cloud was not the problem. The program stalled because one executive with veto power had little reason to optimize for migration success. His job was to ensure security was never the cause of failure. Migration speed was not his metric.

This is where many leaders misread commitment. They interpret attendance as buy-in. It often means awareness. Sometimes it means observation. In this case, it was reconnaissance.

Incentive fragmentation is especially dangerous because teams often look productive while the system is quietly pulling them apart. One leader is measured on speed. Another on cost containment. Another on risk reduction. Another on quarterly output. Everyone works hard. The enterprise does not move coherently.

The issue is not whether leaders verbally support the change. It is whether the system makes it rational for them to prioritize it when tradeoffs appear.

If a transformation succeeds while a powerful stakeholder’s metrics stay flat or worsen, leaders should not be surprised when resistance shows up in delay, exceptions, side processes or alternative standards. Those responses are not random. They are the natural consequence of a system that was never aligned to move together.

Self-check: If the transformation succeeds but a leader’s metrics do not improve, will that leader still treat the work as a priority?

3. Process Friction

The third breakpoint appears when leaders set a faster ambition without redesigning the operating model required to support it. The strategy changes. The machinery does not.

A retail organization invested in cloud capabilities that could technically provision a working application environment in hours. But launching an application still required sequential handoffs across operating system, network, storage, identity, database, application, backup, monitoring and security teams. Each group had its own queue. Each worked on its own timeline. No one owned the full journey from request to result.

The cloud could move in hours. The organization still moved in weeks.

This is where many transformation efforts lose credibility with the people doing the work. Leaders announce a new ambition, but the underlying machinery remains unchanged. The handoffs are the same. The approvals are the same. The decision rights are the same. The dependencies are the same. Teams are told to move faster inside a system designed to prevent speed.

What makes this breakpoint so persistent is that organizations often overestimate capability by looking at talent rather than flow. They have skilled people. They have good technology. They may even have committed leaders. What they do not have is a delivery system that allows those ingredients to produce consistent business movement.

When process friction dominates, the strategy is not actually being executed. It is being negotiated one handoff at a time.

This is also where leadership credibility gets tested. Teams quickly learn whether transformation language is going to be backed by structural redesign or whether they are simply being asked to absorb more pressure inside the same constraints.

Self-check: If you mapped how work actually flows today, would it look like the formal process or the workaround your teams built to survive it?

4. The Technology Illusion

The fourth breakpoint appears when leaders invest in a new capability without designing the surrounding behaviors, workflows and decision norms required to make it valuable.

An enterprise software company invested in a new sales analytics platform. The data was better. The dashboards were better. The engineering work was solid. Months later, teams were still relying on legacy reports and spreadsheets.

Not because the new system was inaccurate or harder to use. Because the old process gave people more room to tune the story, soften the numbers or avoid difficult conversations.

The technology was ready. The organization was not.

This pattern is common in AI, analytics, workflow automation and broader modernization programs. Leaders invest in the visible artifact and underestimate the operational and behavioral change required to make it valuable. They hope the tool will force the organization forward. More often, the organization absorbs the tool into its existing habits and continues operating much as before.

Technology can accelerate aligned execution. It cannot create alignment on its own.

That is why so many well-funded initiatives look compelling in demonstrations and disappoint in practice. The technical capability becomes visible before the operating discipline required to use it. By the time leaders see weak adoption or shallow impact, the real problem has usually been present for months in unchanged incentives, decision habits, workflows and management behavior.

This is not a technology failure. It is a leadership design failure. The organization was asked to use a new tool inside an old operating system.

Self-check: If you removed the technology tomorrow, would teams still agree on how the work should happen?

5. Momentum Mirage

The fifth breakpoint appears when a transformation is launched with early visibility but without enough built-in reinforcement to sustain progress once leadership attention shifts.

A semiconductor company launched a digital transformation with strong executive attention and promising early wins. The first quarterly review looked strong. Pilots were working. Teams were engaged. Progress was visible. Then margin pressure pulled the executive sponsor into other priorities. Governance meetings remained on the calendar. Status reports continued. But decision velocity slowed, obstacles stayed unresolved longer and visible reinforcement faded.

No one cancelled the initiative. No one needed to. The organization simply stopped feeding it.

By the next planning cycle, the transformation was still alive in presentations and largely dead in practice.

This breakpoint is easy to miss because activity continues after momentum has weakened. Meetings happen. Slides update. The work still has a name. What disappears is the force that turns progress into confidence and confidence into adoption. People begin reading silence as a signal. They return to local priorities. The old system starts reclaiming ground.

Momentum is not enthusiasm. It is the organization’s ability to convert intent into visible progress, then reinforce that progress fast enough to sustain belief.

The leaders who manage this well do not wait for annual reviews to discover drift. They create short feedback loops, make wins visible, remove friction quickly and stop weak experiments before they consume confidence along with resources.

Transformations that survive leadership distraction, budget pressure or competing priorities are rarely the ones with the best launch. They are the ones designed with enough reinforcement to keep moving once the spotlight shifts.

Self-check: What would happen if you stopped actively managing this transformation for 90 days?

What These Breakpoints Are Actually Revealing

These five breakpoints are not random execution problems. They are visible signs that the transformation was not designed strongly enough in one or more of four underlying forces, and that leaders are now seeing the consequences in execution.

Purpose. Is the outcome clear enough that teams would define success the same way?

Commitment. Have priorities, incentives, ownership, and resources been aligned strongly enough to hold when tradeoffs appear?

Capability. Does the organization have the operating ability to execute and scale, not just the technical talent to begin?

Momentum. Is there enough visible progress, reinforcement, and feedback to sustain movement after launch?

These are not meant to replace every other change model. Leaders already have plenty of frameworks that describe what change should include. The value here is practical. These four forces help leaders do two things better: design transformations that are more likely to hold under pressure and recognize early when force is being lost.

Strategic disconnection usually points to weak purpose. Incentive fragmentation exposes weak commitment. Process friction and the technology illusion both reveal capability gaps, but in different ways. Process friction lives in how work flows across teams. The technology illusion reveals a capability gap rooted not in broken workflow but in the belief that the right technology can substitute for organizational readiness. Momentum mirage is what happens when reinforcement and decision energy fade before the organization has truly shifted.

The breakpoint tells leaders where the pain is surfacing. The underlying forces help explain what must change.

A Practical Diagnostic for Leaders

When transformations begin to stall, leadership teams often respond by adding governance, increasing communication or introducing more tooling. Those actions may help, but they are often treatments applied after deeper design weaknesses have already surfaced.

A better starting point is to ask four questions before the work scales and then ask them again as it progresses.

Purpose: Are we aligned on the outcome, and would teams describe success the same way?

Commitment: Have we aligned incentives, ownership and priorities strongly enough to survive conflict?

Capability: Does our operating model allow the work to move at the speed the strategy now requires?

Momentum: Have we built enough visible progress and short enough feedback loops to sustain confidence and action after launch?

Used early, these questions help leaders design against predictable breakpoints. Used later, they help identify where drift is already forming.

The goal is not to create a perfect scorecard. The goal is to make hidden weakness discussable while it is still manageable.

That is where many transformations fail. Leaders can feel the energy draining, but they cannot yet name the mechanism. Once the issue is named, it becomes actionable. An unclear outcome can be sharpened. A misaligned incentive can be redesigned. A broken handoff can be rebuilt. A weak feedback loop can be tightened.

But that only happens when leaders stop treating symptoms as the root cause and start asking whether the transformation was built to hold under the realities of how the organization actually works.

The Leadership Work Behind Every Transformation

Most organizations are not short on ambition. They are short on aligned execution.

That challenge is getting harder as companies layer AI adoption, operating model redesign, cost pressure and higher performance expectations on top of one another. In that environment, transformations do not fail because leaders lack effort. They fail because the organization was not designed to hold alignment, incentives, capability and momentum under real operating pressure, and because the warning signs are often recognized too late.

The real work of leadership is not just to launch change. It is to build and sustain the forces that allow change to hold, then see early when those forces are weakening.

That is why the best transformation leaders do more than sponsor programs. They clarify outcomes. Align incentives. Remove structural friction. Build reinforcement into the system. Watch for early signs of drift. They do not just ask whether the initiative is on track. They ask whether the organization is becoming more able to deliver what the business now needs.

That starts with one honest question:

Can you tell, right now, whether this transformation was designed to succeed?

The question is not whether the transformation is active. The question is whether it was designed to hold under pressure, and whether leaders can see the warning signs before activity becomes a substitute for movement.

This is Paper 1 in the Why Change Fails series