Most teams don’t have a delivery problem.
They have a decision problem.
Work doesn’t slow down because people are lazy. It slows down because decisions sit:
- waiting for a meeting
- Waiting for a sign-off
- Waiting for someone who’s too busy (or too nervous) to choose
That delay has a name: decision latency.
And it quietly destroys ROI.
If you want the full ROI framing (inputs + a simple example + the Starter Kit), start here: https://berriaultandassociates.com/resources/agile-transformation-roi/
What decision latency looks like in real life
You’ll recognize it as:
- “We can’t start until leadership aligns.”
- “We’re waiting on legal/security/finance.”
- “We need one more deck.”
- “Let’s circle back next week.”
Meanwhile, the team keeps moving… but not forward.
They start work with assumptions, build the wrong thing, and then redo it once the decision is finalized.
That’s not a process issue. That’s a leadership system issue.
Why decision latency kills ROI (even if everyone is busy)
Decision latency creates three expensive side effects:
- Queueing and waiting Work piles up behind a single decision point.
- Thrash (starting, stopping, restarting) People context-switch, re-plan, and re-explain.
- Rework When decisions arrive late, they arrive after work has already happened.
If you’re building an agile transformation business case, decision latency is one of the easiest “value leaks” to explain to leaders because it’s visible and relatable.
The simplest way to measure decision latency
You don’t need fancy tooling. Start with a lightweight definition:
Decision latency is the time between a decision request and its execution.
Track it for the decisions that actually matter:
- Priority calls
- Scope trade-offs
- Risk acceptance
- “Ship vs. wait” decisions
A practical tracking method (low friction)
Create a simple log (a spreadsheet is fine):
- Decision requested (date)
- Decision owner
- Decision type (priority/risk/scope/budget)
- Decision made (date)
- Notes (what blocked it)
Even 10–20 decisions are enough to see patterns.
What to fix first (before you change any framework)
If you want faster flow, don’t start with ceremonies. Start with decision hygiene.
1) Make decision ownership explicit
A surprising amount of latency is “everyone thought someone else owned it.”
Pick one:
- Single owner (best for speed)
- Owner + consulted group (best for quality)
Avoid: “committee owns it.” Committees don’t own anything.
2) Set decision timeboxes
Not every decision deserves a month.
Try:
- 24 hours for small trade-offs
- 72 hours for medium decisions
- 1 week for big calls (with a clear agenda)
If a decision can’t be made inside the timebox, that’s a signal: the inputs are unclear, the risk is undefined, or the owner doesn’t have authority.
3) Define what “good enough” looks like
Perfection is a delay strategy.
Agree on:
- What data is required
- What data is nice-to-have
- What risk level is acceptable
This is where a behaviour-first approach matters: leaders have to model “we choose, we learn, we adjust.”
4) Create a visible decision queue
If decisions are invisible, they don’t get handled.
A simple board column works:
- Requested
- In review
- Decided
Then review it weekly (15 minutes). Not a meeting. A hygiene check.
The leadership behaviours that reduce decision latency
This is the part most transformations skip.
You can’t “process” your way out of leadership avoidance.
Here are the behaviours that change the system:
- Protect priorities (stop adding work mid-stream)
- Make trade-offs explicit (“If we do this, we’re not doing that”)
- Decide with incomplete info (and commit to revisiting)
- Reward surfacing problems early (instead of punishing it)
If you want the “how we work” version of this (behaviour-first, not framework-first), it’s here: https://berriaultandassociates.com/about-us/why-we-work-this-way/
A simple 30-day experiment (that creates ROI fast)
If you want something you can run without a big program:
- Pick one team (or one value stream)
- Track decision latency for 30 days
- Assign clear owners for the top 3 decision types
- Add timeboxes
- Review the decision queue weekly
What you’re looking for:
- Fewer stalled items
- Less rework caused by late decisions
- More stable throughput
- Calmer delivery rhythm
That’s the beginning of ROI.
Next step
If you’re building a business case, decision latency is one of the cleanest inputs to include because it connects directly to delay, rework, and predictability.
Grab the ROI Starter Kit here (template + assumptions worksheet): https://berriaultandassociates.com/resources/agile-transformation-roi/
And if you want help identifying your biggest decision bottlenecks (fast), book a quick call: https://meetings.hubspot.com/jberriault