Decision Turnaround Time

Overview

Slow decisions are one of the most underacknowledged causes of delivery delays. When a team blocks on a question — about product scope, technical approach, stakeholder preference, or resource allocation — and that question takes days to answer, the cost is not just the wait time. The developer loses context, adjacent work accumulates, and the sprint plan quietly shifts. Decision turnaround time is a delivery metric that most teams do not measure because the cost of slow decisions is distributed and invisible.

For escalating decisions that cannot be made at the team level, see Escalation Protocols. For communicating status when decisions are pending, see Stakeholder Communication Frameworks.

Why It Matters

Blocked developers do not stop working — they start the wrong work. When a developer cannot proceed without a decision, they either block (costly) or move to something else (costly differently). The work they need to do accumulates as unfinished business. When the decision eventually arrives, re-establishing context adds time to the original estimate.

Decision latency compounds. A single decision that takes a week instead of a day does not add one day to the project. It pushes every downstream decision back, every dependent story back, and often invalidates assumptions made during the wait.

Decision quality is not the bottleneck — decision availability is. In most teams, decisions are not slow because they are hard. They are slow because the right person is not in the right place at the right time, because the question was not formatted in a way that makes it easy to answer, or because there is no expectation for when a response is required.

A team that cannot get decisions is not autonomous. Teams that require frequent external decisions to proceed are blocked by the availability and responsiveness of stakeholders. Building decision infrastructure — clear ownership, defined turnaround times, async-first processes — reduces this dependency.

Transparency about decision latency creates accountability. When blocked decisions are visible in status updates, the delay is visible. Invisible delays are not managed; visible delays create pressure to resolve.

Standards & Best Practices

Decision types and appropriate owners

Not all decisions require the same person or process:

Setting explicit turnaround expectations by decision type is more effective than setting a single SLA for all decisions. It also makes it clear who owns each category.

The RACI model for decisions

RACI (Responsible, Accountable, Consulted, Informed) clarifies who has what role in a decision:

• Responsible: Does the work to make the decision (gathers options, assesses trade-offs)
• Accountable: Has final authority and is answerable for the outcome (one person only)
• Consulted: Provides input before the decision is made
• Informed: Notified of the decision after it is made

The most common failure mode in RACI is multiple Accountable owners. When two or more people are accountable for a decision, each assumes the other will make it. Decisions with no single accountable owner do not get made.

Async-first decision making

Synchronous decision-making (meetings, calls) should be reserved for decisions that genuinely require real-time negotiation. Most decisions can be made asynchronously:

1. The person raising the question formats it clearly with context, options, and a recommendation
2. They send it to the decision owner with an explicit response deadline
3. The decision owner responds (asynchronously) within the deadline
4. If the deadline passes without a response, the requestor escalates

The key requirement is that the question is formatted for async response: self-contained, with options laid out, and with a clear ask. "What do you think about the checkout flow?" is not async-ready. "We need to decide between option A (store card details with PCI compliance overhead) and option B (tokenise via Stripe, no PCI overhead but less flexibility). I recommend B. Please confirm by Thursday EOD so we can proceed with sprint 4 stories." is async-ready.

Decision log

A decision log is a record of significant decisions made during a project. It captures:

• What was decided
• Why (the reasoning)
• Who decided
• What alternatives were considered

The decision log serves three purposes:

1. It prevents the same decision from being relitigated when team members change
2. It provides context when the decision's implications surface later
3. It creates accountability — decisions with names attached are treated differently than verbal agreements

How to Implement

Formatting a decision request

When raising a question that requires a decision:

## Decision needed: [Brief topic]

**Context:** [2–3 sentences explaining the situation]

**Options:**
A. [Description] — pros: [...] cons: [...]
B. [Description] — pros: [...] cons: [...]

**My recommendation:** Option [X] because [brief reason]

**Decision needed by:** [Date and time]
**Impact of missing deadline:** [What happens if this isn't decided by then]

Well-formatted decision requests get faster responses. Decision owners who receive a clear options analysis can respond in minutes. Decision owners who receive an open-ended question spend time gathering the context the requestor should have provided.

Decision SLA enforcement

Once decision turnaround times are agreed:

1. When a decision is needed, log it in the RAID log (Issues section) with the deadline
2. If the deadline passes, the product manager escalates to the decision owner's manager
3. If a decision owner is consistently missing their SLA, surface it in a retrospective

Tracking missed decision SLAs — even informally — changes the culture around decision speed. Decisions that are invisible can be missed without consequence; decisions that are tracked cannot.

Decision log maintenance

Maintain a decision log for significant decisions throughout the project:

## Decision Log — [Project name]

| Date   | Decision | Options considered | Chosen option | Rationale      | Decided by |
| ------ | -------- | ------------------ | ------------- | -------------- | ---------- |
| [date] | [what]   | [A, B, C]          | [B]           | [why B over A] | [name]     |

Review the decision log at major project milestones to confirm decisions are still valid given changed context.

Tools & Templates

Decision request template

## Decision Request — [Topic]

**Requested by:** [Name]
**Date:** [Date]
**Decision needed by:** [Date]

### Context

[What situation requires a decision? 2–4 sentences.]

### Options

**Option A — [Name]**
[Description. Key benefit. Key drawback.]

**Option B — [Name]**
[Description. Key benefit. Key drawback.]

### Recommendation

[Your recommended option and brief rationale.]

### Impact if not decided by deadline

[What blocks or slips if this is not resolved on time.]

Decision turnaround SLA table

Use this as a reference for the team and stakeholders:

## Decision Turnaround SLAs — [Team name]

| Decision type                     | Owner              | SLA             |
| --------------------------------- | ------------------ | --------------- |
| Story scope clarification         | Product manager    | 4 hours         |
| Technical approach (within scope) | Engineering lead   | Same day        |
| Backlog priority change           | Product manager    | 24 hours        |
| Cross-team dependency             | Lead + counterpart | 48 hours        |
| Sprint scope change               | PM + stakeholder   | 48 hours        |
| Strategic or budget decision      | Senior stakeholder | 5 business days |

Common Pitfalls

Open-ended questions sent without a deadline. "What do you think about X?" has no urgency signal. The recipient will deprioritise it. Every decision request must have an explicit deadline and a statement of what happens if the deadline is missed.

Multiple accountable owners. When two people are accountable for a decision, neither feels sole responsibility. Decisions with joint ownership are consistently slower than decisions with a single named owner. Clarify accountability before raising the question.

Synchronous default. Teams that default to "let's schedule a meeting to discuss this" for every decision create a decision queue that is gated on calendar availability. Most decisions can be made asynchronously by one person with a clear framing. Reserve synchronous sessions for genuine negotiation.

Decision log not maintained. Decisions that are not recorded get relitigated. The new engineer asks why the team chose approach X; nobody remembers. The stakeholder reverses a decision made six months ago because the reasoning was never documented. A decision log takes five minutes to maintain and prevents recurring arguments.

Treating slow decisions as unavoidable. Teams that accept slow decisions as "just how it is here" stop measuring them and stop trying to improve them. Decision speed is a process outcome, not a personality trait. It responds to clear ownership, explicit SLAs, and visibility of delays.

Not surfacing blocked decisions in status updates. A decision that is blocking delivery but is not mentioned in the weekly status update is invisible to the stakeholders who could unblock it. Status updates should include a section for pending decisions with deadlines.