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 executives simultaneously reporting 38% success and 80% ROI.[3] The two questions measured different things in the same survey, 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. The replacement cost for a churned customer in complex B2B engagements runs approximately five to seven times the original acquisition cost.[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 Global Survey (2008): 1,546 executives; when asked whether their transformation was successful, 38% said completely or mostly; when asked whether previous transformation investments drove meaningful ROI, 80% said yes. The two questions measured different things in the same survey.

[4] Bain & Company. Customer retention economics (B2B enterprise). Bain customer loyalty research series; commonly reported range for complex B2B acquisition-to-retention cost ratio.

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