Decision Latency

Decision latency measures elapsed time across stated decision events. Here it runs from a proposal being submitted for a decision to that decision being communicated to the requester. Preparation before submission and implementation after communication are separate measures. Record when the proposal becomes ready for review so incomplete submissions can be distinguished from ready work waiting in a queue.

It is worth naming because it is the price side of governance. Every control has a cost, and for approval controls the cost is mostly time. Treating that time as free is what produces processes whose benefit nobody can demonstrate and whose expense nobody counts.

Locating the delay

Interval	What it is	What reduces it
Queue time	Submitted work waiting for an available decision-maker	Capacity, cadence, delegation, or asynchronous review; use measured waits to identify the constraint
Information time	Time after submission blocked on required evidence or clarification	Clear evidence requirements and tracking of missing inputs
Deliberation time	Time actively spent evaluating the proposal	Appropriate expertise, a well-defined question, and attention proportional to its consequences
Communication time	Between reaching the decision and communicating it to the requester	A timely, accessible decision record and a defined notification path

Record submission, readiness, review activity, decision, and communication events. Work can loop through clarification and review, and some activities overlap: assign a mutually exclusive primary state to each elapsed interval if the components are to sum to total latency. Otherwise report overlapping activity times separately. Track withdrawn and still-open requests as well as completed ones; a completed-only percentile can hide a growing backlog.

How waiting can change behavior

Waiting can affect behavior as well as schedules. DORA reports evidence supporting the batching explanation in software delivery; the other mechanisms below are possibilities to investigate in the local process.

Batches can grow when costly approval encourages fewer, larger requests. DORA’s change-approval guidance links heavyweight approval with slower delivery and describes larger batches as a supported explanation for increased risk. It does not establish that every approval step raises risk.

Work may use another path: a different account, an existing contract, or a feature flag. That can bypass intended authority, but it need not erase all evidence. Correlate messages, contracts, and system logs with the decision record to establish what was authorized and what happened.

Questions decay. By the time an answer arrives, the option set has changed, the vendor quote has expired, or the team has built around the gap. Late approval of a stale proposal is not the same decision the requester asked for.

Refusal can become an attractive default where approving creates visible personal exposure while delay or rejection carries little visible cost. Examine local incentives and record the basis of refusals as well as approvals; slow processes do not inevitably produce that behavior.

DORA warns against responding to instability by indiscriminately adding heavyweight approvals. More waiting can reinforce larger batches. Evaluate which failure a proposed control would address and whether safer implementation or recovery would provide better protection.

Reducing the wait while preserving authority

1. Delegate by class. Assign authority for a defined class and scope, including evidence, thresholds, and mandatory approvals. Keep escalation for work outside those limits. What the thresholds attach to is the subject of decision rights.
2. Decide asynchronously. Set a response target and an accountable decider. Define a substitute or escalation path when the target is missed; a deadline on a proposal alone does not bound the wait.
3. Define an authorized default. Proceeding after silence is appropriate only where an authorized policy has already delegated that outcome for a defined class, scope, risk range, and evidence requirement. Reversibility and a requester-set deadline alone do not confer authority. Required explicit approvals and out-of-scope cases must use the designated approval or escalation path; record the policy and instance eligibility.
4. Automate suitable checks. Policy as code can remove repeated checking when inputs are trustworthy and relevant paths enforce the policy. Compare lifecycle cost and residual exceptions, and retain any judgment or independent approval the rule does not replace.
5. Separate reversible from irreversible. Spend the wait where undoing is expensive. Applying the same scrutiny to both is the pitfall that the change research names as treating all changes equally, and it is also how risk-based decisions are supposed to be differentiated.

DORA associates a clear understanding of the change-approval process with better delivery performance. Publish the entry point, evidence, authority, and fallback route, then measure whether that clarity reduces avoidable waits.

Reading latency alongside outcomes

• Median and ninetieth-percentile wait per decision class. The tail is what teams plan around, and the median is what reports quote.
• Delegation share within comparable decision classes and risk ranges. Interpret changes with workload mix and outcomes; increasing delegation is not always the appropriate goal.
• Queue time as a fraction of total latency, using the stated event and overlap rules. Read it with information wait and active review time before changing cadence, capacity, or preparation requirements.
• Reasons for reversal or reconsideration. Separate preventable mistakes and missing records from valid responses to new information, appeals, or changed conditions. Revisiting a decision is not by itself evidence that it was made too quickly.

DORA recommends using delivery lead time and change fail rate to assess changes to software approval. Read those outcomes with decision waits for comparable changes and a consistent reporting window. Governance body explains how the body’s mandate assigns responsibility for the decision process.

How latency sits alongside decision rights, committees, and automated controls is worked through in Forty Approvals and Two Rejections.

References

• DORA, Capabilities: Streamlining change approval — the reported effect of heavyweight approval on delivery performance and batch size, the warning about adding process after incidents, the suggested metrics, and the finding about understanding the process.