A modernization request clears the sponsoring vice president in a week. It waits three weeks for a finance review that asks the same questions the sponsor already answered, then three more weeks for a security review that applies a checklist built for a different category of system. Legal review adds three more weeks confirming vendor terms unchanged since the last renewal. By week ten the package is complete, ready for the steering committee, which meets once a month and just closed its window, so it waits three more weeks for the next session, a full quarter in, having been re-explained four times to four audiences who each needed to hear it fresh. Nobody in that chain did anything wrong. The technology leader who owns the outcome still watches the calendar slip.

Why Approval Speed Fails Even When Ownership Is Clear

When a technology decision moves too slowly, the fix is rarely who owns it. Even when ownership is clear, the decision can still stall, because clarity of ownership settles who is accountable; it says nothing about how quickly the call can move. What slows it down is the architecture it travels through: how many layers sign off, in what order, and whether those layers move in sequence or together. Decision rights determine who owns the call. Approval architecture determines how efficiently that call can move. That architecture acts on the decision while it is still a proposal, carrying it toward the point where it can be executed. The two mechanisms interact, and mistaking one for the other is why so many governance fixes change nothing. A CIO can clarify ownership perfectly and still watch the same decision take the same number of weeks, because the chain it has to pass through was never rebuilt.

The Anatomy of a Layered Approval Chain

A technology decision above a modest threshold rarely clears one gate. It typically passes through several, in a fixed order with little relation to the decision's actual risk. A sponsor approves the business case. A finance reviewer checks budget impact against a plan built months earlier. A security reviewer applies a checklist calibrated for a different kind of system. A legal reviewer checks contract terms that rarely change from one vendor to the next. A steering committee revisits the whole case again, sometimes without the context earlier reviewers already established. The CIO signing off at the start of that chain is rarely in the room for any of the later steps. Each layer exists for a defensible reason, but none was designed with the others in mind, so the chain accumulated one control at a time, each addition solving a narrow problem without anyone asking what the full sequence would cost. Info-Tech Research Group's governance research describes a common version of this pattern: committees that review a decision without holding the authority to approve it, adding a step that consumes time and resolves nothing.

How Latency Compounds Across Sequential Sign-Offs

The damage from a layered chain rarely shows up step by step. A two-week finance review looks tolerable on its own, and so does a one-week security check. The damage shows up in the sum, which is worse than the parts suggest, because each layer re-explains the decision to an audience that was not in the room for the layer before it. One documented case from a large enterprise transformation tracked cross-functional approvals that moved weekly early in the program, then stretched into multi-week cycles as the sign-off chain grew, with teams making informal assumptions to keep working while the decision was still in review. None of that appears on a status report. It shows up later, as rework, as scope drift, and as a program that looks like it is running behind on delivery when the real problem is a decision that has not yet cleared its chain.

Decision Latency vs. Decision Rights: Two Different Failure Modes

Two different organizational-design problems get treated as one, and that confusion is what keeps the fix from working. Decision rights establish who has the authority to make a given call. Approval architecture establishes how many steps that call has to clear, in what sequence, before it can be acted on. A senior technology leader can hold undisputed authority over an infrastructure decision and still route it through six sequential sign-offs built for a different era of the organization, because ownership and routing sit in separate mechanisms. A chain collapsed to two fast steps can move an unauthorized decision just as quickly as an authorized one, which produces a different failure entirely. The two mechanisms sit next to each other and shape the same outcome, which is why a redesign that touches only one of them leaves the other exactly as it was. Fixing who owns a decision is necessary work; it does not by itself change how fast the decision travels once owned. A CIO with unambiguous authority over infrastructure spending still needs an approval chain built for speed, or that clarity changes nothing about how fast anything moves.

The Levers That Collapse Approval Layers

The first category of fix removes steps rather than reordering them. It applies once an audit turns up a review that duplicates another reviewer's scope, or a committee that reviews a decision without the authority to change it. A technology leader can test every remaining sign-off against a single question: does removing this step measurably increase the decision's risk, or does it just satisfy a habit the organization built up over time. Approval thresholds set years ago, before the organization's risk tolerance and deal sizes changed, are also candidates for resetting so fewer decisions require the full chain at all. The control that keeps a collapsed chain from trading one risk for another is a defined threshold: decisions above a set dollar amount, blast radius, or vendor-risk rating still route through the full chain; only decisions below that line take the shortened path. McKinsey's research on organizational decision-making documents a specialty-chemicals company that opened membership on each of its six governance committees to every senior leader without clarifying who held the decision; the result was meetings that produced opinions instead of approvals, until the company limited participation to accountable owners and cut the number of decision-making bodies to what decisions actually required. Removing a standing step changes the chain itself and needs its own sponsor: typically the CIO working with the functional leader who owns the review being cut, so the removal is a decision someone made rather than a step that quietly stopped happening. Collapsing layers does not lower the organization's risk standard. It calibrates the depth of review to the actual exposure.

The Levers That Resequence and Parallelize Approval

The second category of fix changes when each step happens instead of removing it. Resequencing applies when a review runs against an early draft that will change several more times before the chain finishes, wasting attention on a moving target: a security review scheduled after the architecture is locked wastes fewer cycles than the same review run against an unsettled design. Parallelizing applies when the reviews do not actually depend on each other: finance, security, and legal typically evaluate different risks in the same decision rather than building on one another's findings, which makes routing them in sequence a scheduling habit rather than a real dependency. Instead of finance, then security, then legal, an organization can send the decision to all three at once. Each reviewer receives a fixed response window. Silence does not equal approval. An unresolved review escalates automatically to the named decision owner, who determines whether the risk justifies stopping the decision. The forums do not disappear. They stop waiting on each other. A senior technology leader adopting this lever needs one structural commitment most organizations resist: that same named owner, empowered to act the moment a window closes rather than waiting for every reviewer to circle back and confirm. Parallel review without that owner just produces four separate delays running at the same time instead of one long delay running in sequence. Resequencing and parallelizing both change the chain itself, so both need the same kind of sponsor as any other redesign: the CIO and the functional leaders whose reviews are being reordered, agreeing on the new sequence before it becomes the default path.

Rebuilding an Approval Structure Built for Speed

None of these levers require reopening who owns the underlying decision. That question stays settled by decision rights. Redesigning the approval chain is a separate decision that needs its own explicit sponsor, typically a senior technology leader working with the functional leader who owns whichever review is being changed. Without that sponsor, the redesign is just another unauthorized change, added to a chain nobody designed. The deeper work is treating latency as a first-class design constraint alongside risk, the way a security review is designed around threat models and a finance review around budget exposure. An approval chain that nobody designed on purpose keeps producing the delay nobody intended, regardless of how clearly the organization has assigned ownership. A technology leader who rebuilds the chain on purpose ends up with a decision architecture where speed and governance are both accounted for, the maturity of an organization that has looked at how its own decisions actually move and rebuilt the path deliberately.

Approval architecture is a structural choice, and most organizations never make it on purpose. CIO Mastermind gives technology leaders a confidential peer forum for pressure-testing where their own approval chains break down, and which layers are worth collapsing, resequencing, or running in parallel. Explore the CIO Mastermind peer network.