Your transformation is not stuck in tech. It is stuck in approvals

Estimated reading time: 8 minutes

For CEOs, COOs, CFOs, CIOs, and CDOs who need execution speed without chaos: how to build decision velocity into your operating model.

Transformation fails when decisions move slower than delivery. If the roadmap is approved but teams cannot get timely answers on scope, tradeoffs, risk, or funding, they compensate with workarounds. Backlogs fork, priorities collide, and adoption stalls. The fix is not more meetings or a better dashboard. It is a decision system: clear decision rights, decision SLAs, and lightweight guardrails that let teams act without constant escalation. Put a weekly decision docket in place where only decision-ready items enter, one accountable owner is named, and decisions are made within defined time windows. Technology delivery becomes predictable when decision throughput is predictable. Speed comes from authority and rules, not heroics.

The steering committee pattern: “We met, we aligned, nothing changed”

You walk into the steering committee with three simple asks that unblock the next six weeks of delivery.

The room is full. Updates are crisp. Risks are “noted.”

Then the meeting converts decisions into discussion.

Someone asks for more analysis. Someone else wants alignment with another initiative. Legal wants a review but cannot commit to a date. IT wants architectural validation. Product wants “one more sprint” of discovery.

You leave with action items, not decisions.

Delivery teams do what teams always do under uncertainty: they keep moving. They split the backlog into parallel interpretations, build temporary workarounds, and defer the hard tradeoffs. The program looks busy. The value case quietly degrades.

That is not a technology problem. That is decision latency.

Define decision velocity

Decision velocity is the rate at which an organization moves from a decision request to a committed decision, with clear ownership and timing.

It is not a leadership vibe. It is an operating capability.

McKinsey has published research showing a strong relationship between decision speed and decision quality, challenging the myth that faster decisions must be worse.

If you want transformation to move, you have to manage decision throughput the same way you manage delivery throughput.

Why transformation gets stuck: four approval traps

Most transformations stall in predictable places. Not because teams cannot build. Because no one can decide.

1) No single accountable owner

When “the committee” owns a decision, nobody owns it. Discussion expands to fill the room, and the timeline becomes indefinite.

Your first test is brutal and simple: Can you name one person who can say yes?
If not, you do not have governance. You have group therapy.

2) Decision timing is disconnected from delivery timing

Delivery works in sprints and increments. Approvals often work in monthly or quarterly cycles.

That mismatch forces teams into two bad options:

• Wait, and lose momentum.
• Build, and risk rework.

Either way, you pay.

3) Everything is treated as high stakes

If every decision requires maximum scrutiny, you create a permanent bottleneck.

You need risk-tiering:

• Reversible decisions should be fast and local.
• Irreversible decisions should be deliberate and escalated.

4) Control functions are invited too late

Legal, security, finance, and architecture are often pulled in after a solution is emotionally “chosen.” Then they become the blocker.

When control functions are late, the organization learns the wrong lesson: “Governance slows us down.”

The real issue is sequencing. Controls need earlier involvement with clearer inputs, not bigger meetings.

A practical operating model fix: SLAs, guardrails, and a decision docket

You do not need a new org chart. You need three design elements that turn approvals into flow.

1) Install decision SLAs

A decision SLA is a time commitment for a decision category, with a named accountable owner.

Create a short taxonomy of decisions that repeatedly block transformation.

Example for commerce:

• Pricing and promo exceptions
• Experience deviations from design standards
• Data usage and privacy constraints
• Vendor selection thresholds
• Scope tradeoffs impacting ROI

Then set SLAs:

• 48 hours: reversible, low-risk decisions (minor experience changes, small scope tradeoffs)
• 5 business days: cross-functional tradeoffs (promo exception, integration approach)
• 2 weeks: high-risk or high-cost decisions (vendor commitment, major architecture choice)

Decision SLAs work only if you name a single accountable decision owner. Not a working group. Not a forum. A person.

2) Create guardrails, not gates

Guardrails are rules that let teams act without permission. Gates are checkpoints that force teams to ask.

You need fewer gates and stronger guardrails.

A good guardrail has three properties:

• It is measurable.
• It is reusable.
• It travels with the work.

Examples:

• “Customer-facing changes must meet accessibility standard X.”
• “Promo exceptions above Y margin impact require finance sign-off within 5 days.”
• “PII cannot be used for model training unless condition Z is met.”

This is also where decision rights frameworks earn their keep. HBR’s “Who Has the D?” makes the core point: clarity of decision roles improves speed and execution consistency.

3) Run a weekly decision docket

This is the meeting your steering committee should have been.

30 minutes. Pre-reads only. Decisions only.

Rules:

1. If it is not decision-ready, it does not enter the docket.
2. Each item has one accountable owner who will decide.
3. Each item has a recommendation and options, not a status update.
4. If the owner cannot decide, the escalation path is explicit and time-bound.

This shifts governance from “review” to “throughput.”

Make it real: what changes for steering committees and teams

If you implement the above, three governance behaviors must change.

Steering committees stop being decision routers

Steering committees should not be a place where decisions wait for “alignment.” They should be a place where:

• Decision rights are clarified when ambiguous
• Escalations are resolved quickly
• Tradeoffs are accepted explicitly

If the committee is mostly updates, it is not steering. It is reporting.

Product teams get autonomy inside guardrails

Autonomy is not freedom. It is freedom inside rules.

When teams know what they can decide, they stop asking permission. And when exceptions are needed, they become clean, decision-ready escalations.

Control functions shift from blockers to designers of safe speed

Your legal, security, and finance partners should spend less time reviewing one-off work and more time creating reusable policy packs.

This is the only scalable way to increase speed without increasing risk.

When this advice does not apply

There are cases where “faster decisions” is not the goal.

• When the decision is truly irreversible and existential (example: divesting a core business)
• When your risk posture requires deliberate pacing (highly regulated environments with active enforcement)
• When the organization lacks basic operating hygiene (no stable backlog, no clear scope, no accountable owners)
• When the problem is not decisions but capacity (for example, teams are underfunded or key roles are missing)

What to do this week

If you are leading a transformation, do these five moves in one week:

1. List the last 10 decisions that delayed delivery. Categorize them.
2. Assign a single accountable owner per category.
3. Set decision SLAs for each category.
4. Write 3 to 5 guardrails that let teams act without escalation.
5. Replace one status meeting with a 30-minute decision docket.

If decision throughput improves, delivery throughput will follow.

Governance category
Operating Model category
Strategy to Execution category

---

Facts that matter

• McKinsey reported that respondents who said decision making was fast were 1.98 times more likely to say decision making was also high quality (May 1, 2019).
• McKinsey has also stated that executives, on average, spend almost 40% of their time making decisions and believe much of that time is poorly used (McKinsey collection page, accessed via their “Make faster, better decisions” hub).
• HBR’s decision roles article argues that unclear decision roles undermine speed and consistent execution (“Who Has the D?”, January 2006).
• BCG’s OVIS framework is explicitly designed to clarify decision rights and improve decision speed to help organizations hit strategic objectives, including transformations (June 10, 2021).
• PMI has published research emphasizing the performance impact of effective communications on projects, including links to on-time, on-budget outcomes (PMI thought leadership page referencing Pulse communications research).

---

FAQ

What is decision velocity in a transformation?

Decision velocity is how quickly the organization turns decision requests into committed decisions with clear ownership and timing. It is measurable: time-to-decision by category, percent of decisions made within SLA, and backlog items blocked by missing decisions. When these are visible, you can fix governance with the same discipline you use to fix delivery.

How do I set decision SLAs without increasing risk?

Start by tiering decisions by reversibility and risk. Low-risk, reversible decisions should be local and fast. High-risk, high-cost decisions should be deliberate but time-bound. Then attach guardrails to each tier so teams know what “safe to decide” means. The goal is not speed at all costs. It is predictable speed.

What is the difference between guardrails and gates?

Guardrails are reusable rules that let teams act without asking permission. Gates are checkpoints that require approval before work can proceed. Too many gates create queues and rework. Strong guardrails reduce escalations and keep risk controlled because teams can operate independently inside clear boundaries.

Why do steering committees often slow transformations down?

Because they default to reporting, alignment, and risk noting instead of decision throughput. When committees try to make every decision collectively, they create ambiguity and delay. A steering committee should clarify decision rights, resolve escalations quickly, and enforce decision SLAs. Updates belong in asynchronous reporting.

How do I know if I have an approvals problem or a delivery problem?

Look at the blocked work. If teams are waiting on answers about scope, tradeoffs, policy, or funding, it is an approvals problem. If they have clear decisions but cannot execute due to missing skills, underfunding, or unstable technology, it is a delivery problem. Most large programs suffer from both, but approvals bottlenecks are usually easier to fix first.

---

Glossary

• Decision velocity: The measurable speed from decision request to committed decision, by decision category.
• Decision SLA: A time commitment for a decision type, with a named accountable decision owner.
• Guardrails: Reusable policy rules that allow teams to decide locally without escalation.
• Gates: Approval checkpoints that block progress until a forum or leader signs off.
• Decision docket: A short recurring meeting where only decision-ready items are decided, not discussed.

---

Executive Takeaways

• A weekly decision docket beats another steering committee update.
• Your stack is rarely the bottleneck. Decision latency is.
• If you cannot name the decision owner, you do not have governance.
• Decision SLAs turn approvals into flow.
• Guardrails let teams move fast without multiplying risk.