Digital Transformation Leadership: Why Change Needs a Single Throat to Choke

Digital transformation leadership is not a team sport. When a company claims that a steering committee or a “transformation office” owns the strategy, they are admitting that nobody actually owns it. The primary reason most large-scale change initiatives stall is not a lack of technical skill or a shortage of budget, but a vacuum of accountability. For a project to succeed, there must be a single person who is responsible for the outcome: one throat to choke. Without a solitary individual who can make a final call, budget decisions, and sequencing priorities, the programme will inevitably dissolve into a series of veto meetings where the goal is to avoid blame rather than deliver value.

Why does shared accountability kill digital transformation leadership?

Shared accountability is a polite way of saying “nobody is responsible.” In many corporate environments, the default response to risk is to distribute it. This leads to the creation of steering committees. On paper, a committee looks like a governance best practice. It ensures that all stakeholders are heard and that different departments align. In practice, it is often a shield. When a project misses a deadline or blows through its budget, the committee can point to the collective consensus of the group. Because everyone agreed, no one person is to blame.

This structure creates a fatal incentive. In a committee, the safest path is to avoid making a definitive decision that might prove wrong. Instead, the committee asks for “more data” or “further alignment.” This leads to a state of perpetual deliberation. When accountability is shared, the pressure to deliver is diluted. If five people are responsible for a milestone, each person only feels twenty percent of the failure. This dilution of pressure is why so many initiatives fail to deliver their promised value.

Real digital transformation leadership requires the ability to be wrong, to pivot quickly, and to force a decision when the team is deadlocked. A committee cannot do this. A committee can only compromise. But transformation is rarely the result of a compromise; it is the result of a decisive move in a specific direction. When the “ownership” is a group, the programme loses its edge. It becomes a series of polite suggestions rather than a series of directives. This is the hidden cost of corporate consensus: it trades speed and clarity for a false sense of security.

How to tell your programme has no real owner

You do not need to read the org chart to know if your programme is ownerless. You only need to look at the artifacts of the project. The first sign is the language used in meeting minutes. In an owned programme, minutes record decisions: “The owner decided to cut feature X to meet the October deadline.” In an ownerless programme, minutes record “noting.” You will see phrases like “the committee noted the delay” or “the group discussed the budget overrun.” Noting is not deciding. If your primary record of governance is a list of things the committee has “noted,” you have no owner.

The second sign is the routing of escalations. In a healthy project, an escalation has a destination. It goes to the owner, who evaluates the trade-offs and provides a resolution. In an ownerless programme, escalations route to nowhere. They are sent to the steering committee, where they are added to the agenda for the next monthly meeting. This creates massive decision latency. A developer who is blocked on Tuesday must wait until the third Thursday of the month for a group of executives to “discuss” the issue. By the time a decision is reached, the context has changed, or the team has found a workaround that introduces technical debt.

The third sign is the “veto culture.” When no one owns the programme, every stakeholder becomes a gatekeeper. Since no one is responsible for the overall success, individuals focus on protecting their own domain. The head of security can veto a feature; the head of compliance can veto the timeline; the head of operations can veto the tool. In a programme with a single owner, the owner acknowledges these concerns but ultimately decides if the risk is acceptable. In an ownerless programme, a single “no” from any stakeholder stops the momentum. The result is a product that is the lowest common denominator of everyone’s preferences, which is almost always a failure.

What does a single accountable owner actually do?

A real owner is not a project manager. A project manager tracks the schedule and reports the status. An owner manages the outcome. The difference is that the owner has the authority to change the schedule, the scope, and the team to ensure the outcome is reached. According to McKinsey research, the leaders of transformation initiatives make the most significant difference when they take full ownership of their individual initiatives. This ownership manifests in four concrete behaviors.

First, the owner manages the budget as their own money. They do not just “track” the spend; they make the hard calls on where to cut. If the programme is over budget, the owner does not ask the committee for a solution. They identify the lowest-value features and kill them. They understand that a finished, limited product is better than a perfect, unfinished one.

Second, the owner controls the sequencing. Many programmes fail because they try to do everything at once. This leads to the second system trap, where the ambition of the rebuild exceeds the capacity of the organization to absorb the change. A single owner forces a sequence. They decide that “Step A must be fully operational before we even discuss Step B.” They protect the team from “scope creep” by acting as the only filter for new requirements.

Third, the owner makes the “kill decisions.” This is the most difficult part of digital transformation leadership. It requires the courage to stop a project that is not working. A committee will almost never kill a project because no one wants to be the person who admitted a mistake. An owner kills the project early to save the remaining budget and time. They value the organization’s resources more than their own ego.

Fourth, the owner maintains weekly face time with the delivery team. They do not rely on a PowerPoint slide deck updated every two weeks. They are in the trenches. They know who is struggling, which dependencies are actually blocking progress, and where the “green” status reports are lying. This proximity allows them to resolve issues in minutes that would take a committee weeks to process.

Is there a difference between a sponsor and an owner?

Yes, and confusing the two is a primary cause of project failure. A sponsor is usually a senior executive who provides the budget, the political air cover, and the high-level mandate. The sponsor’s role is to ensure the programme has the resources it needs and that other executives do not interfere. They are the “champion” of the project at the board level.

The owner, however, is the person responsible for the daily reality of delivery. While the sponsor asks “Are we on track?”, the owner is the one who ensures the project stays on track. The sponsor provides the “what” and the “why”; the owner provides the “how” and the “when.” The danger arises when the sponsor thinks their role is to manage the project. When a sponsor starts making granular decisions about features or sequencing without being in the daily loop, they introduce volatility. Conversely, if there is a sponsor but no owner, the project has money and permission but no direction.

A successful transformation has a clear line of sight: the delivery team reports to the owner, and the owner reports to the sponsor. This hierarchy ensures that strategic goals are translated into tactical actions. When this line is blurred, the delivery team is forced to manage the sponsor’s expectations directly, which leads to the “yes-man” culture where every request is accepted, regardless of the impact on the timeline.

What if you are the owner but have no mandate?

Many professionals find themselves in the “owner” role by title but not by authority. They are told they are the “Programme Lead,” but they still have to ask three different VPs for permission to change a deadline. This is the most frustrating position in corporate life. You have the accountability for the failure, but not the authority to prevent it.

If you are in this position, your first task is not to manage the project, but to negotiate your mandate. You must have a direct conversation with your sponsor. You need to make them understand that the current structure is a recipe for failure. The conversation should be framed around risk: “I am currently accountable for the delivery of this project, but I do not have the authority to make the decisions required to hit the date. This gap is the biggest risk to the programme.”

You must ask for specific powers. Do not ask for “more authority.” Ask for “the power to make final decisions on feature prioritization without committee approval.” Ask for “the ability to reallocate budget between workstreams.” If the sponsor refuses to grant these powers, you have a clear signal that the project is likely to fail. At that point, the most professional action is to document the lack of mandate as a primary project risk. This is not about avoiding blame; it is about being honest about the structural barriers to success.

How should handovers between owners work?

Accountability cannot be “shared” during a transition. When a programme moves from one owner to another, the handover must be an explicit transfer of the “throat to choke.” Many handovers are treated as knowledge transfers: the old owner hands over the new owner some documents and a few briefings. This is insufficient. A knowledge transfer tells you how the project works; an ownership transfer tells you who is responsible for it.

A proper handover requires a “Closing of the Books” meeting. The outgoing owner must present the current state of the budget, the current list of risks, and the current set of commitments. The incoming owner must then formally accept these. This should be a recorded event. The new owner must explicitly say, “I now accept full accountability for these milestones and this budget.”

This formality prevents the “legacy excuse,” where a new owner spends the first six months blaming the previous person for the state of the project. By formally accepting the state of the programme, the new owner takes ownership of the recovery. This is how you avoid the cycle where every new leader spends their first quarter “auditing” the project instead of driving it forward. It is the difference between inheriting a problem and taking responsibility for a solution.

The BCG study of transformation programmes archived at bcg.com reaches a related conclusion: committed leadership behaviour during the transformation, not committee size, separates the programmes that land from the ones that drift.

Frequently Asked Questions

Does a single owner replace the need for a steering committee?

No, but it changes the committee’s purpose. The committee should be for alignment and strategic guidance, not for day-to-day decision-making. The owner uses the committee to flag risks and secure resources, but the owner remains the final decision-maker on delivery and sequencing.

Can a project have multiple owners for different workstreams?

You can have workstream leads, but there must still be one overall programme owner. If workstreams have equal authority, they will eventually clash over resources or dependencies. The overall owner resolves these conflicts to ensure the total system delivers value.

What happens if the owner is too aggressive with “kill decisions”?

That is why the sponsor exists. The sponsor provides a check and balance. If an owner is killing too many features or pivoting too often, the sponsor can step in to realign the strategy. This is a healthy tension between strategic ambition and delivery reality.

How do you handle stakeholders who feel ignored by a single owner?

Ownership is not about ignoring stakeholders; it is about managing them. A good owner listens to all perspectives but makes it clear that the decision rests with them. Transparency about why a certain path was chosen reduces friction more than trying to please everyone.

Why do AI pilots succeed while full rollouts stall?

Pilots often have a small, dedicated owner with a limited scope. Full rollouts require digital transformation leadership at scale. When the pilot ends, the ownership is often handed to a committee, and the momentum dies because the “single throat to choke” has been replaced by a group.

Digital transformation leadership is fundamentally about the courage to be accountable. In a world of corporate committees and shared risks, the most valuable asset a company can have is a leader who is willing to stand alone behind a decision. When you remove the shield of the group, you find the speed and clarity necessary to actually change the business. Stop looking for a consensus and start looking for an owner.