The cost of a slow decision

Decision latency is a real cost

Decision latency is the time between a team recognising that a choice is needed and receiving a usable decision. It includes the wait for a meeting, the time taken to restate context, the queue for approval and the delay while a decision record is found or recreated. It is easy to miss because no invoice arrives with “waiting for a decision” printed on it.

Yet work rarely stops cleanly. People pause a task, choose lower-value work, build around an assumption, repeat analysis for a new audience or begin work that later has to change. A decision that is late can therefore affect more than the person who asked for it. It can block a handoff, stretch a risk window and make the next decision more expensive.

This is not an argument for careless speed. Some choices deserve more evidence, broader input or formal approval. The cost comes from avoidable waiting: information is already available near the work, the decision boundary is unclear, and the team must still send the choice through a distant queue. The aim is not fewer controls. It is the right decision at the right point, with a clear record and a stated boundary.

Estimate the cost in five inputs

Use this simple model for a single decision: teams × fully-loaded cost × days of latency ÷ working days × share of capacity affected. It is a starting estimate, not a claim of false precision. Its strength is that every assumption can be seen, challenged and changed.

Define the inputs before calculating

Teams is the number of teams materially held up by the choice. Do not count a team because it is interested. Count it when the decision changes what that team can do next. Fully-loaded cost is the relevant cost of a team over the period used in the model, including the employment and operating cost you normally use for capacity decisions. Days of latency is the elapsed working time from issue recognised to a decision that can be acted on.

Working days converts the team cost into a daily cost. Use the organisation’s normal planning assumption and state it. Share of capacity affected prevents the calculation from pretending that every person is idle. Estimate the share of each affected team’s capacity that is waiting, reworking or diverted by the uncertainty. If different teams are affected differently, calculate them separately rather than forcing one average.

The model should be documented beside the decision. Record the decision date, the point when the issue was first visible, who had the relevant evidence, the authority boundary, and the capacity assumptions. That turns a complaint about bureaucracy into a reviewable management fact.

Why the number is usually bigger than expected

First, leaders often count only direct waiting. They do not count partial waiting: a specialist who spends time preparing a case again, a delivery lead who manages a dependency, or a team that moves to a less valuable item because the priority is unresolved. The share-of-capacity input exists to make these partial effects visible without overstating them.

Second, a delayed choice often sends work downstream on an assumption. The first cost is time spent waiting. The next cost is time spent changing work after the decision arrives. The later the decision, the more artefacts, handoffs and commitments may have formed around the old assumption. The visible delay is only the first part of the cost.

Third, latency repeats. A single late decision may look tolerable. The pattern is not. If the same approval route delays priority, design, risk and quality choices, the capacity loss becomes a normal operating cost. People then learn that raising a question is slow and stop raising it early. Risk appears later, when it costs more to change.

Put decision rights at the point of information

Decision rights at the point of information means giving authority to the people who hold the most current, relevant evidence, within explicit purpose and guardrails. It does not mean every person can make every decision. It means the team knows which decisions it owns, which need consultation, which cross a threshold for escalation and what evidence is required for each route.

What it looks like in practice

A leader states the outcome, not merely the instruction: reduce customer waiting time while protecting service quality and cost. The team has a visible target, a baseline, a quality guardrail and a risk threshold. It can then choose the next action when the choice stays within those conditions. The team records the context, options, evidence, decision, owner and review date. A material change to the boundary triggers escalation; routine work does not.

This approach replaces permission-seeking with accountable judgement. The team is not asked to guess what a senior person might prefer. It is asked to explain how the decision supports the target, what evidence supports it, what risk remains and when the choice will be reviewed. That makes local decisions easier to inspect, not harder.

TEAM IQ uses D.I.R.E.C.T Value Routing to direct effort using value, evidence and confidence. Insight Risk Triggers define the points at which a team must pause, pivot, escalate or run a new test. A D.I.R.E.C.T Decision Audit then asks whether purpose, evidence, assumptions, risk, authority and review were clear. Together, these practices reduce delay without hiding uncertainty.

Keep the boundary clear

Local authority works only when the boundary is specific. A team needs to know the outcome it is protecting, the value and quality measures that matter, the risks it may accept, the information it must share and the point at which the choice belongs elsewhere. A vague “use your judgement” instruction is not a decision right. It is a transfer of risk without a usable frame.

Good boundaries also protect leaders. They remove routine choices from senior queues while preserving a clear route for decisions that carry material customer, financial, regulatory or organisational consequences. Leaders see the decisions that need their judgement. Teams stop waiting for approval that adds no new information.

Start with one recurring bottleneck. Identify the decision, measure the current latency, calculate the capacity affected and ask where the richest information sits. Define the purpose, guardrails and escalation trigger. Run the new route for a review period. Then compare latency, rework and the quality of the decision record. The evidence will tell you whether the boundary is right.

Take the estimate to the board

A board does not need a dramatic claim. It needs assumptions it can inspect. The cost-of-inaction model shows the inputs behind the number so finance, delivery and leadership can change them together. It helps separate a genuine control from a habit that consumes capacity without improving a decision.

Open the cost-of-inaction model in the board case. Enter your own team count, fully-loaded cost, working-day assumption, latency and capacity share. The resulting number is not the end of the discussion. It is the starting point for deciding which decision right to move closer to the work.

Make latency visible, then reduce it

Slow decisions are rarely caused by one careless person. They usually come from an operating design: unclear ownership, hidden evidence, vague boundaries and queues that have become normal. Those conditions can be measured. Once the cost and the route are visible, the team can change the smallest part of the system that removes unnecessary waiting.

Measure the days. Estimate the affected capacity. Put decision rights where information is richest. Keep the guardrails and the audit trail. A faster decision is valuable only if it remains a sound one.