Most transformations do not fail because the strategy was wrong. They fail because nobody owned the gap between the slide deck and Tuesday morning. The CEO announces a new direction, consultants build a roadmap, and then the organisation keeps running the old way because the people doing the work were never given time, tools, or a reason to change.

That gap is the COO's job. A transformation is the deliberate, sequenced rewiring of how a company works — its processes, its technology, its structure, and often its culture — so it can serve a different or larger set of customers than it can today. The CEO owns why and the destination. The COO owns whether it actually happens, at what pace, and without the current business falling over while it does.

This guide is about leading that work: how to scope it honestly, sequence it so early wins fund later ones, govern it so it does not drift, and protect the running business the whole time. It is not about measuring outcomes after the fact (see how to know your transformation actually worked) or about squeezing waste out of a stable operation. It is about steering the change itself.

Start by naming what kind of change this actually is

The first mistake is treating every transformation as one thing. "Transform the business" can mean five different jobs, and each has a different risk profile and a different owner. Before you build a plan, force the conversation to a specific noun.

A STRONG scoping conversation ends with a sentence like: "We are moving from selling one-off projects to selling annual subscriptions, which requires new billing systems, a customer-success team we do not have, and a sales comp plan that rewards retention over new logos." That is concrete enough to plan against. A WEAK one ends with "we need to be more digital and customer-centric" — a mood, not a mandate, and a mandate you cannot resource, sequence, or declare finished.

Use a simple frame to separate the layers, because each layer moves at a different speed and needs a different kind of leadership.

The point of the table is not the exact timings — those vary by company. It is that a transformation is almost never a single layer. When someone says "we tried the software and it did not stick," they usually changed the technology layer and left the process, structure, and incentive layers untouched, so people used the new tool to do the old job.

Assess readiness before you commit a date

Executives love a launch date. The COO's job is to earn the right to give one by testing whether the organisation can actually absorb the change. A readiness assessment is not a survey — it is three honest questions asked of the real operation.

Can the current business survive the disruption? Every transformation borrows capacity from the running business. If your best operators are also the only people who can lead the change, you cannot do both at full strength. A STRONG COO names this trade explicitly: "Standing up the new fulfilment process will slow order throughput about 10% for a quarter — here is the plan to hold service levels while we do it." A WEAK one pretends the change is free and then acts surprised when quality slips. Do the incentives point the same direction as the change? People do what they are paid and promoted to do. If you ask a sales team to sell a new product line while their commission still rewards the old one, the change will lose every time. Check the comp plans, the KPIs, and the promotion criteria before you check the technology. Is there real executive air cover, or just a signature? Transformations create losers — teams that shrink, managers whose empire consolidates, processes people were proud of. When those people push back, and they will, does the CEO hold the line or quietly grant exceptions? Getting this alignment locked in advance is one of the highest-leverage parts of the COO–CEO partnership; without it, the COO ends up absorbing resistance the CEO should have pre-empted.

Sequence for momentum, not for tidiness

Once you know the scope and the organisation can absorb it, the design question is order. The instinct is to sequence by logic — fix the foundations first, then build up. That is usually wrong, because a long stretch with nothing to show erodes belief and budget faster than any technical risk.

Sequence instead for momentum: pick a first move that is genuinely useful, visibly finished within one quarter, and honest about the harder work ahead. If you are moving to a new operating model, do not start with a two-year data-platform rebuild that no one outside IT will see. Start with one end-to-end process — say, how a new customer gets onboarded — redesigned and running on the new tools for one segment. It proves the model, it trains the first cohort of believers, and it surfaces the integration problems while they are cheap to fix.

A useful discipline here is the PDCA loop (Plan, Do, Check, Act) or, in OKR language, quarterly objectives with measurable key results: each quarter delivers something real, you check what happened against what you predicted, and you adjust the next quarter. STRONG sequencing looks like a staircase where each step stands on its own. WEAK sequencing is a single 18-month "big bang" whose value only appears at the end — so you learn whether it worked at exactly the moment it is too expensive to change course. If digital systems are the core of your change, a phased digital transformation strategy matters even more: it has to bank value in stages, not in one final cutover.

Govern it, or it drifts

A transformation without governance becomes a list of well-intentioned projects that quietly compete for the same people and slowly revert to business-as-usual. Governance is the unglamorous machinery that keeps the change on course, and it is squarely the COO's to build.

The core of it is a small, senior forum — call it a transformation office or a steering group — that meets on a fixed cadence and does three things: kills or unblocks work, reallocates people and money to what is working, and forces honest status. STRONG governance has a single owner accountable for each workstream (a clean RACI, not a committee), a live view of dependencies, and a standing agenda item for "what should we stop." WEAK governance is a monthly slide review where every project is green until the quarter it is suddenly red.

The most important governance decision is protecting the run. Keep two portfolios visibly separate: the change work and the keep-the-lights-on work. When a production incident competes with a transformation milestone for the same engineer, someone has to make that call deliberately rather than by default. Sound governance is where a transformation and everyday operations strategy meet — the same forum that steers the change also has to defend current service levels while it does.

Take the people with you

Every framework above is machinery. The reason transformations succeed or die is people, and the COO who treats change as a technical rollout will be beaten by resistance they never saw coming. Kotter's change model captures the pattern well: create real urgency, build a guiding coalition of respected insiders, communicate relentlessly, remove the barriers in people's way, and generate short-term wins that make the change feel inevitable.

The practical version is simpler than the theory. STRONG change leadership over-communicates the "why" until people are sick of hearing it, then keeps going — because the moment you stop, the rumour mill fills the silence. It moves credible, respected operators into visible transformation roles so the change is led by people the organisation already trusts, not by an outside team it resents. And it treats the first sceptics as a source of design feedback rather than obstacles to overcome. WEAK change leadership sends one all-hands email, declares the change launched, and mistakes compliance for commitment. The disciplines here run deep enough to be their own craft — worth studying in change management strategies and, for the slower work of shifting norms and incentives, cultural transformation.

One concrete tactic: name the losers early and treat them well. A transformation that consolidates two departments will end some roles and shrink some empires. Handling those people with honesty and generosity is not just decent — it is the single loudest signal to everyone watching about whether this change is safe to believe in. Nothing sells a transformation like the way you treat the people it costs.

Key takeaways

• A transformation fails in the gap between strategy and execution — closing that gap is the COO's core job, not the CEO's.
• Force a specific scope before you plan. "Be more digital" is a mood; "move from projects to subscriptions" is a mandate you can resource and finish.
• Separate the five layers — process, technology, structure, capability, culture — because each moves at a different speed and a change that touches only one layer rarely sticks.
• Sequence for momentum: deliver something genuinely useful and visibly finished each quarter, using PDCA or OKR cadence, rather than a single big-bang release.
• Build governance that can kill work, reallocate resources, and protect the running business — and keep a clean RACI so every workstream has one owner.
• People decide the outcome. Over-communicate the why, put trusted insiders in visible roles, and handle the people the change costs with honesty.

Frequently asked questions

Who should own a business transformation — the CEO or the COO? The CEO owns the vision, the case for change, and the executive air cover; the COO owns execution, sequencing, resourcing, and protecting the running business. When one person tries to do both, the transformation usually starves either the change or the day job. The clearest arrangement mirrors the classic Visionary and Integrator split: the CEO points at the destination and the COO makes the machine get there. How long should a business transformation take? It depends on which layers you are changing. A single process redesign can land in one to three months, a technology and data platform in six to eighteen, and a genuine culture shift in years. The mistake is planning it as one long project with value only at the end — sequence it so each quarter delivers something real and you can course-correct while it is still cheap to do so. What is the biggest reason transformations fail? Resistance that leadership underestimated, usually because the incentives were never realigned. If you ask people to work a new way while their pay, KPIs, and promotion criteria still reward the old way, the old way wins. Check the comp plans and the org's spare capacity before you check the software, and confirm the CEO will hold the line when the pushback arrives. How do I keep the current business running while transforming it? Treat "change the business" and "run the business" as two separate portfolios with deliberate trade-offs between them. Name upfront how much capacity the change will borrow — a temporary dip in throughput while a new process beds in, say — and staff the run so your best operators are not the only ones who can also lead the change. When the two compete for the same person, make that call in the open rather than by default. Do I need consultants to lead a transformation? Consultants can bring capacity, a proven method, and an outside view, but they cannot own the change — the moment they leave, ownership has to already sit inside the company. Use them for specialist skills or surge capacity, and make sure a credible internal leader owns each workstream from day one. A transformation led entirely by an outside team tends to be resented and to evaporate the day the contract ends. How do I know the transformation is actually working, not just busy? Define what "working" means in outcome terms before you start — adoption of the new process, the business result it is meant to unlock, not just milestones hit — and check each quarter whether reality matches the prediction. Busywork shows up as lots of green project status with no movement in the metric that mattered. Measuring this honestly is its own discipline, covered in the companion guide to transformation success.