Name your top priority when a request conflicts with it — then ask if it can wait or go to someone with bandwidth
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.
Why This Is a Rule
The moment a conflicting request arrives is the critical decision point where priorities are either protected or silently displaced. The default response — accepting without negotiation — is silent deferral (Did you choose to defer or fail to negotiate? Strategic deferral preserves sovereignty, silent deferral surrenders it). The structured response — naming your priority and asking whether the request can be redirected — is boundary enforcement at the point of contact.
Naming the priority explicitly serves two functions. First, it makes the trade-off visible to the requester: "I'm currently focused on the product launch" tells them what they're competing against, enabling them to assess whether their request genuinely outranks it. Second, it grounds your decline in strategic reasoning (Frame professional boundaries as quality commitments, not capacity confessions — 'protecting the review' beats 'I have too many meetings', Decline with three components: what you're declining, which priority you're protecting, and an alternative — never just 'I''m busy') rather than personal capacity: you're not saying "I can't" — you're saying "this would displace something specific."
Asking "can this wait or go to someone else?" offers the requester two paths that don't involve displacing your priority. Often, the answer is yes to one of them — the request wasn't as urgent as its presentation implied, or someone else has bandwidth. When the answer is "no, this genuinely needs you now and outranks the launch," that's a legitimate priority shift — but it's been negotiated, not silently absorbed.
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: 'I can do X or Y this week — which matters more?' instead of silently absorbing both (forced-choice formula) and Decline with three components: what you're declining, which priority you're protecting, and an alternative — never just 'I''m busy' (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.