# Priority Flood (Everything Becomes Urgent) This is an anti-example: a common failure mode where “urgent” becomes the decision system. People aren’t lazy. They’re usually trying to help. But when everything can bypass trade-offs, the system will reliably stop finishing. ## What it looks like - Priorities change daily (or hourly). - “Can you just…” interrupts are normalised. - Work starts fast and finishes late. - People feel busy and guilty at the same time. ## Why it happens - There’s no shared definition of “urgent enough”. - Leaders get surprised late, so they pull work forward aggressively. - Trade-offs are implicit, so the loudest request wins. - Nobody owns the cost of interruption. ## Quick repair loop (Observe → Frame → Decide → Learn) Observe with: - [[Overload and Interruptions]] - [[Work and Flow]] Tools: - [[Signal Log]] Frame with: - [[Constraints]] - [[Trade-offs and Opportunity Cost]] - [[Ownership and Consequence]] Decide with: - [[Decision Snapshot]] (make the trade-off explicit) - If it will stick, use [[Decision Record]] One useful decision to make: - “What counts as urgent enough to interrupt work in progress?” Learn with: - [[07_Tools/Signals and Review Points]] - [[15-minute Review]] (use Decision Learning Mode if the “urgent rule” starts drifting) ## One small experiment - [[Interrupt Budget - Experiment]] - [[Protected Thinking Time - Experiment]] ## See Also - [[Leadership as the Constraint (Decision Rights and Trade-offs)]] - [[Decision Debt and Drift]] - [[From Raw Complaint to Signal (Example)]] — Owlery examples are constructed illustrations, not documented case studies. This note also shows the diagnostic phase that precedes any tool deployment ## What to try next Make the next move small and learnable. - Capture 3 signals in [[Signal Log]] (what changed, where did work wait, what created friction?) - If this decision might stick, write a [[Decision Record]] (include a review trigger) - Run one experiment: - [[Interrupt Budget - Experiment]]