A program office has been established, a governance framework defined, a steering committee exists, a set of workstreams running in parallel, a red-amber-green status dashboard, and a biweekly leadership update that goes out as a slide deck to forty people. Every meeting runs on time. Every status report lands in the inbox as scheduled. The program has never, not once, been flagged as at risk.
The business outcome it was supposed to deliver hasn't arrived.
When I ask people inside what's going wrong, I hear the same things. "Nobody's really driving it." "The steering committee receives updates but doesn't actually decide anything." "The people who know what needs to change aren't the people who have the authority to change it." "The program office owns the program. Nobody owns the outcome."
Not governance failure. Leadership absence.
The program is running exactly as designed. That's the problem.
Governance and leadership are not the same job
This sounds obvious until you look at how most transformation programs are actually structured.
Governance creates the conditions for decisions to happen. It sets the cadence, defines the forums, provides the oversight, and makes sure the right information reaches the right people. Done well, it's invisible infrastructure. It keeps the program honest, surfaces risks early, and prevents the kind of decisions someone makes at 11pm and regrets at 9am.
Leadership is something different. It's knowing what actually needs to change, deciding what to do, and pushing that through regardless of the organizational friction in the way. Owning the substance: the what, not just the when. Making the call when the data is ambiguous. Taking responsibility when something doesn't work. Not deferring to "we'll align on this next quarter."
Most transformation programs are structured around governance. They have steering committees, workstreams, tollgates, escalation paths, and RACI matrices, plus sponsors and owners and program leads. What they rarely have is a single accountable person who knows the substance deeply enough to make the hard calls and has the mandate to make them.
When governance fills the space that leadership should occupy, the result is motion without direction. Status updates happen on time, meetings stay on the calendar, decisions get escalated and re-escalated until they disappear into a queue. And the transformation produces, at enormous cost, a slightly different version of what already existed.
The problem usually starts before governance even enters the picture
Most transformations fail not in execution, but in framing. The framing problem happens at the very beginning, when someone decides what kind of transformation this actually is.
There are three different levels at which a transformation can operate. Organizations almost always underestimate which level they're actually at, and that mismatch drives the two most common failure modes.
Level 1: Technology renewal. We're replacing the legacy system. The new platform goes in, the old one goes out, and the business operates more or less as before, just on better infrastructure. This is a technology project with a technology scope. It requires good engineering, careful migration, and solid change management for the technical transition. It doesn't require rethinking how the business creates value.
Level 2: Process and technology redesign. We're changing how work flows and modernizing the tools at the same time. The new system doesn't just replace the old one, it enables different ways of working. Roles change, handoffs are redesigned, the IT system and the operating model are updated together. This is harder than Level 1 by an order of magnitude, because it requires real alignment between the technology agenda and the business agenda.
Level 3: Business model and capability transformation. We're rethinking how we create, deliver, and capture value, and building the business capabilities required to do that, before we even ask what technology supports those capabilities. Level 3 starts with the customer and the market: what value are we trying to create, and for whom? Then it asks what business capabilities that requires. Only after that does it ask what technology enables those capabilities.
Most large-scale transformations are Level 3 in ambition and Level 1 in scoping.
The strategy slide says "customer-centric digital transformation." The project charter says "replace the core banking system" or "implement the new ERP." The business model, the operating model, the value proposition, the required capabilities — none of it has been consciously designed. The assumption is that the new technology will somehow produce the strategic outcome, with minimal disruption to how the business actually works.
It won't. It never does.
When the technology scope doesn't match the transformation ambition, one of two things happens. The first: the program runs over budget and past deadline, because the business requirements were so weakly defined that the delivery team spends months in the gap between what the technology can do and what the business actually needs. A requirement gets delivered, the business side realizes it's wrong, the scope gets revised, and the cycle repeats. Not because anyone is incompetent. Because the business side of the transformation was never designed before the technical work began.
The second failure mode is quieter and in some ways worse: the program delivers. On time, roughly on budget, the new system goes live. Eighteen months later, the business benefits haven't arrived. Revenue growth stalled. Costs didn't drop. Customer experience didn't improve. The value creation, delivery, and capture mechanics the transformation was supposed to unlock were never redesigned, and the new technology is now running the same broken business logic as the old one, just faster.
Both failure modes have the same root cause: nobody took leadership responsibility for the business design question. The technology was defined. The business transformation wasn't.
That's why the level question is a leadership question. It can't be answered by a governance framework, a project charter, or a steering committee. It requires someone with the authority and the depth to look at the stated scope, compare it to the strategic ambition, and say plainly: "We are scoped for Level 1 but we need to operate at Level 3. That means the scope, the mandate, and the leadership model all have to change."
That conversation is uncomfortable. It expands the program, creates complexity, and surfaces disagreements about what the transformation is actually for. It is entirely the leader's job to have it, as early as possible, before the Level 1 infrastructure is so far along that changing course feels impossible.
The four patterns I see repeatedly
The status update meeting
A leadership forum runs every two weeks. Eight to twelve senior people, an hour each time, a prepared deck with workstream updates and traffic-light statuses. Amber items get discussed briefly. Green items get acknowledged. Red items get put on a watch list.
Nobody decides anything. The forum receives information. It does not produce decisions.
When something hits a wall, it gets noted in the next deck. The wall stays.
The steering committee had perfect attendance. Nobody led.
The distributed accountability trap
Transformation programs are often built around a shared ownership model. No single person is the decision-maker; the answer emerges from alignment. This feels safe. When many people own something, no single person carries the risk of being wrong.
The downside is identical: when many people own something, no single person carries the risk. No one is genuinely accountable, so no one moves with urgency. When things stall, the response is another alignment meeting.
This is how organizations end up with three teams who all nominally "own" the customer journey, each managing their own slice, none of them empowered to design the end-to-end experience. Or five product managers who each own a different part of a platform the customer experiences as one thing, and the customer experience reflects exactly that fragmentation.
Ownership without authority is theater. The title says owner. The operating model says committee.
The governance layer that blocks more than it protects
Governance layers are almost always added reactively. Something went wrong, a surprise launch, a bad investment decision, a technology choice that caused problems, and the response is an additional review checkpoint. That checkpoint makes sense as a reaction to a specific failure. It rarely makes sense as permanent infrastructure.
A year later the checkpoint is still there, now reviewing everything, not just the class of decisions that caused the original problem. The original problem hasn't recurred. But hundreds of decisions have moved slower than they needed to because of the checkpoint, and nobody has counted that cost.
This is what I call the Steering Committee Tax: the hidden cost of governance overhead that nobody tracks because it shows up as slow decisions, not as a line item on a balance sheet. The cost isn't paid in one place. It's distributed across dozens of delayed calls, opportunities not taken, and good people who left because they couldn't ship anything without three layers of approval.
The PMO that owns the program, and nobody who owns the change
A program management office is essential. It coordinates workstreams, manages interdependencies, tracks the schedule, runs the governance cadence, handles reporting. Without it, large programs collapse into chaos. That's not the problem.
A program can be perfectly managed and still deliver nothing that actually changes the business.
PMO manages the program. That's the job, and a good PMO does it well. What PMO doesn't own, and was never designed to own, is the actual business change: making sure the business genuinely changes its ways of working, builds the capabilities the new model requires, and captures the benefits the transformation was funded to deliver. That work sits somewhere between the PMO and the business leaders, and in most programs it falls into the gap between them.
Business leaders are too occupied with the day job to drive it themselves. The PMO doesn't have the business mandate to own it. Nobody commissions a dedicated transformation lead to bridge the two. So change management becomes a workstream on a Gantt chart instead of a core leadership responsibility — something that gets done to the organization rather than led from within it.
When the program wraps up and the PMO ramps down, the real test arrives. Did the business actually change? Do the people who need to work differently know how? Are the new capabilities in place? Is anyone tracking whether the benefits are landing?
In too many cases: no. The program was delivered. The transformation wasn't.
What real transformation leadership looks like
None of this is an argument against governance. Well-designed governance is what separates a serious program from a collection of good intentions. The question is what governance is for, and what has to exist alongside it.
Ownership of the substance, not just the process
There needs to be a person, not a committee, not a workstream, not a shared responsibility, who owns the outcome deeply enough to defend it, adapt it, and drive it when things get hard.
That person knows the substance. They understand what the change is supposed to produce for the customer and for the business, not just which milestones are on the Gantt chart. When a decision needs to be made, they make it. When something isn't working, they call it and change course. When stakeholders push back, they engage with the content of the pushback, not just the politics.
This isn't the program manager role, though it can sit alongside one. It's the role that answers the question: if this transformation succeeds, who gets credit? That person should also be the one accountable when it doesn't.
Making calls on ambiguous decisions instead of escalating them
The decisions that stall programs are rarely the clean ones. Clean decisions, clear data, clear ownership, clear answer, get made. The ones that sit in queues are the ones where the data is mixed, the stakeholders disagree, the risks are real on multiple sides, and making the call requires someone to accept responsibility for the outcome.
The reflex in most organizations is to escalate. Find the next person up, present the options, let them decide. Escalation has its place: genuinely irreversible decisions with major consequences should reach people senior enough to carry that weight. But most decisions that get escalated are not irreversible. They're reversible decisions that nobody wants to be wrong about.
The leader's job is to distinguish between decisions that genuinely need senior judgment and decisions that are being escalated to diffuse accountability. Then make the second category themselves.
Driving the substance between the meetings
Governance happens in meetings. Leadership happens in between them.
A program meeting reviews what happened last week. A leader is on the phone the day before the meeting, already dealing with the thing that would show up amber if nobody did anything. A program report notes that a decision is outstanding. A leader has already had the informal conversation that will make the formal decision a formality.
This work doesn't appear in any framework and can't be captured in a RACI. It's the ongoing effort to keep things moving: understanding the real blockers (which are rarely the stated ones), building the coalitions that make decisions possible, and giving the people closest to the work enough clarity that they can move without waiting for approval.
The willingness to have the difficult conversation
Some transformations stall for structural reasons: the operating model doesn't support the change, the incentives are misaligned, the decision rights are wrong. Those require redesign, and I write about them in Structure Decides.
Many stall for a simpler reason: nobody has said out loud what isn't working. The executive sponsor knows a key business leader isn't committed but addresses it obliquely in meetings. The steering committee knows a workstream is structurally impossible as scoped, but what reaches the slides is "some resourcing challenges." The people closest to the customer know the product being built won't solve the actual problem, but that observation hasn't reached anyone who can act on it.
These aren't information failures. They're leadership failures — the failure to say the uncomfortable thing clearly enough that it produces a response.
Real leadership in transformation means being the person who says "this is not working, and here's what I think we need to do instead" — not in a retrospective eighteen months later, but when it matters.
Five questions to spot the gap in your own program
These are the questions I ask early in any transformation engagement. Not a framework, just the fastest way to understand whether the program has leadership or just governance.
Who makes the call when two senior stakeholders disagree? If the answer is "we align until we find consensus," there's a governance process but no leadership. Consensus is fine when both parties reach it naturally. It's a red flag when it's the default mechanism for handling disagreement, because it means no one is accountable for the final decision.
Does your program scope match your transformation ambition? If leadership says "digital transformation" but the program charter says "system replacement," nobody has done the business design work. The gap between those two framings is where transformations go to die.
Who owns the outcome, not the process? Walk the org chart of the program. Find the person who would be most accountable if the business outcome doesn't arrive. Ask whether that person is actively shaping what's being built or changed. If the answer is the program office, there's a gap.
Where do decisions sit for more than two weeks? Some decisions legitimately need time: new information, deep analysis, genuine alignment. But decisions that are simply waiting for the next forum, or waiting for someone to have the conversation that would unlock them, those are leadership failures, not governance failures.
Can the people doing the work describe the intended outcome in one sentence? Not the program objective from the charter. The actual change they're making and why it matters. If the team describes the program in terms of activities and milestones rather than outcomes and customers, the substance hasn't been communicated with enough conviction to land.
Where to start
If your transformation has governance but feels leaderless, the first step is not adding another layer of process. It's getting honest about the ownership question.
Pick the most important decision currently outstanding in your program, the one that's been in the queue the longest. Ask: who would be accountable if this decision turned out to be wrong? If the answer is unclear, or effectively "nobody in particular," you've found the gap.
From there, the work is redesigning the ownership model so that the person who should be accountable for the outcome has the authority and the proximity to actually drive it. That's not a governance change. It's a leadership design problem.
This is the work I do under the Transformation Lead service: coming in as an embedded partner who owns the substance alongside the business, not just the process alongside the program office. If you're in the middle of a transformation that's moving but not landing, let's talk.
