Decision-making speed is a hidden constraint on transformation success

Late into a large-scale SAP transformation, the technical work was on pace. Build was closing, system integration testing was underway and cutover readiness was taking shape. What was not on pace were the decisions the program depended on.

Cross-functional calls around data ownership, process exceptions and cutover sequencing, decisions that had moved weekly earlier in the program, began stretching into multi-week cycles. Teams moved forward on assumptions to maintain progress, effectively making decisions informally because the formal ones were not being made. The technical critical path was holding. The decision path was not.

Decision latency does more damage than technical debt

When decisions stretch from weeks into months, the work does not stop. It mutates. Teams make assumptions to keep moving. Leads rework designs based on best guesses of what leadership will eventually decide. Mid-level managers negotiate informal exceptions with their counterparts in other functions to unblock their people. None of this appears on a status deck. It shows up weeks later as scope creep, integration gaps and unexplained variances in testing.

Research from McKinsey has shown that organizations with fast, high-quality decision-making are significantly more likely to outperform their peers, with decision effectiveness driven more by role clarity than by the amount of information available. That finding mirrors what I have seen in practice. When decisions slow, it is rarely because leaders lack information. It is because the architecture of who decides has broken down.

The compounding effect is what makes it dangerous. A single week lost on a decision early in a program shows up as a week. The same delay repeated across dozens of decisions, with downstream teams building on assumptions in the gap, shows up as months of rework and significant avoidable cost. What leaders experience as a program running hot is usually decision latency compounding, not technical complexity emerging.

The second-order damage is harder to see. Experienced leaders, the ones you most need engaged, begin disengaging from the decision process once they recognize it is not producing outcomes. What remains is a forum of participants who either stop pushing for resolution or route critical decisions around the forum entirely. Governance does not fail loudly in these programs. It fails quietly, and the program follows.

That pattern rarely stays contained to a single program. Once decision latency takes hold, it begins to shape outcomes across the portfolio, slowing time-to-value, eroding credibility with the business, and widening the gap between what the technology roadmap promises and what the organization can absorb.

Ambiguity in decision rights is the root cause, not governance design

When programs hit decision drag, the instinctive response is to add more governance, another steering committee, another working group, another tollgate. It is almost always the wrong instinct. The root cause of slow decisions is rarely that governance is too light. It is that decision rights are too ambiguous.

On the SAP program I referenced, when I mapped where decisions were getting stuck, the pattern was consistent. Multiple stakeholders across business and IT believed they had input, but no one was clearly accountable for the final call. Governance forums were reviewing decisions that no single person had yet owned. Escalations looped upward because the same ambiguity existed at every level. The unclear decision rights that made middle management unable to decide also made senior leadership unable to resolve decisions when they escalated.

This is what alignment culture produces when it is not paired with decision discipline. The desire for broad alignment is healthy up to a point, and then it becomes counterproductive. You end up with too many voices in the room, each reasonable in isolation, collectively unable to converge. Harvard Business Review has consistently highlighted that decision effectiveness depends less on how many stakeholders are involved and more on whether ownership is clearly defined. In transformation environments, that distinction becomes critical as cross-functional complexity increases.

The most misleading signal is that governance appears healthy. Meetings are well attended. Status decks are complete. Senior sponsors are engaged. But when you ask a simple question, for this decision, who has the authority to say yes, and by when, the room goes quiet. That silence is the problem. It is not solved by adding another forum. It is solved by removing ambiguity about who decides.

Shift governance from reporting to resolution

The fix for decision latency is not more governance. It is clearer ownership. On that program, we rebuilt decision flow around three moves.

• We defined decision ownership by category. Instead of treating the transformation as a single decision domain, we broke decisions into areas such as data ownership, process exceptions, and cutover sequencing, and assigned a single accountable owner for each.
• We reduced the number of required stakeholders in each decision forum. Alignment does not require everyone in the room. It requires the right people, with clear roles, making decisions they are accountable for. We removed participation that did not contribute to decision outcomes and protected the time of accountable owners. The forums became smaller and the decisions moved faster.
• We reset the forums themselves with the expectation that decisions would be made in session, not deferred. Every decision had a named owner, a decision timeline, and a default action if no decision was made. The default action created clarity. When the cost of not deciding became visible and attributable, decisions started happening at the pace the program required.

What that shift did in practice was move governance from reporting to resolution. The same forums that had absorbed program time without producing decisions began producing outcomes at the pace the program needed. Velocity improved. Rework decreased. The critical path held. None of this required new technology, new tools, or a new operating model. It required clarity about who owned each decision and an expectation that governance would produce outcomes.

There is a line I have used with executive sponsors for years:

You do not have a decision problem. You have an ownership problem.

Korn Ferry’s research on the critical drivers of business transformation reinforces that transformation outcomes depend as much on leadership capability and organizational behavior as they do on the technical solution itself. In practice, decision-making sits at the center of that dynamic, shaping how effectively organizations translate strategy into execution.

CIOs are not typically leading day-to-day transformation execution. They operate as decision-makers and orchestrators, shaping how decisions are structured, who owns them, how quickly they move and what happens when they do not.

Technology delivery will always have constraints. Decision velocity does not have to be one of them.

The organizations that successfully deliver complex transformations are not the ones with the cleanest roadmaps. They are the ones with the clearest decision rights.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?