Name your top priority when a request conflicts…
When someone makes a request that would conflict with your top priority, name that priority explicitly and ask whether the request can wait or go to someone else with available bandwidth.
When This Fires
- When any request arrives that would consume time or attention currently allocated to your top priority
- When the instinct is to say "sure" without checking the priority collision
- When requests arrive with implied urgency that may not reflect actual priority
- Complements Surface trade-offs with forced-choice (forced-choice formula) and Decline with three components (three-component decline) with the real-time priority-naming version
Common Failure Mode
Silent acceptance: "Sure, I'll handle that." Your top priority just lost two hours to a request you never evaluated against it. The requester doesn't know a collision occurred because you absorbed it without communication.
The Protocol
(1) When a request arrives, check: does this conflict with what I'm currently working on or have scheduled? (2) If yes → name the priority: "I'm currently focused on [specific top priority]." (3) Ask the redirect question: "Can this wait until [specific time], or is there someone else who could handle it?" (4) If the requester says it can wait or be redirected → the priority is protected. Schedule the request for later. (5) If the requester says it genuinely can't wait and outranks your current priority → accept with explicit priority acknowledgment: "I'll shift to this, which means [current priority] is delayed by [amount]." The deferral is now strategic, not silent.