Prioritize blocking decisions by cost of delay, not perceived importance
For decisions blocking three or more downstream dependencies, calculate cost of delay by multiplying the decision's delay duration by the combined capacity waiting idle, then prioritize decisions by this metric rather than by perceived importance.
Why This Is a Rule
Decisions get prioritized by perceived importance — "this is a big strategic decision, so it should take time." But the system impact of a decision depends on how much is waiting for it, not on how important it feels. A "small" technical decision blocking three teams' work for a week has higher system cost than a "big" strategic decision that only affects next quarter's planning.
Cost of delay quantifies this: multiply the decision's delay duration by the combined capacity sitting idle downstream. If three engineers (billing at $150/hour each) are blocked for 5 days by a decision, the cost of delay is $18,000 — regardless of whether the decision feels "important" or "trivial." This metric reorders your decision queue by system impact rather than by emotional salience.
Decisions blocking three or more dependencies are the critical threshold because below three, local optimization is sufficient. At three or more, the decision is a system-level constraint — and constraint management (Goldratt's Theory of Constraints) requires treating it as the highest priority regardless of its surface-level importance.
When This Fires
- A decision has been deferred while multiple downstream tasks wait
- Sprint planning reveals that pending decisions are the primary blocker
- Someone says "we're waiting on a decision" and multiple people nod
- Any backlog review where undecided items have downstream dependencies
Common Failure Mode
Deferring "small" decisions because they feel unimportant: "I'll decide on the API format later, we have bigger things to discuss." Meanwhile, three engineers are blocked on that API format decision. The decision feels small; its system cost is enormous. Cost of delay makes this visible by attaching a number to the wait time.
The Protocol
When a decision blocks 3+ downstream dependencies: (1) Calculate cost of delay: number of blocked people × their time cost × estimated delay duration. (2) Compare this number to whatever you're currently working on instead. (3) If the cost of delay exceeds the value of your current work → make the blocking decision now, even if it's imperfect. A fast 80% decision that unblocks three teams beats a slow 95% decision that keeps them waiting. (4) If the decision genuinely can't be made (missing information), identify the specific information needed and assign someone to get it by end of day.