Before It Breaks
What leaders who get transformation right do before anyone is watching.
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.