Write what your role includes AND excludes — default to 'no' for out-of-scope requests unless you consciously choose otherwise
Define professional scope boundaries by writing what your role explicitly includes and excludes, then default to 'no' for requests falling outside that scope unless you consciously choose to make an exception.
Why This Is a Rule
Professional scope creep happens one reasonable request at a time. "Can you also handle the client presentation?" "Would you mind reviewing the budget?" "Could you sit in on this hiring panel?" Each individual request is reasonable; the accumulation is unsustainable. Without an explicit scope definition, the default response to reasonable requests is "yes" — and every "yes" to an out-of-scope request expands your actual role while the formal role stays the same.
Written scope boundaries create a structural defense: a documented list of what your role includes (in-scope: say yes by default) and what it excludes (out-of-scope: say no by default). The "default to no" for out-of-scope requests isn't inflexibility — it's a decision architecture that requires conscious choice rather than automatic compliance. You can still say yes to an out-of-scope request, but it requires deliberate override rather than passive acceptance.
The written documentation also protects against role distortion: when your actual work diverges significantly from your documented scope, the gap becomes visible and addressable. Without documentation, scope creep is invisible until burnout makes it undeniable.
When This Fires
- When entering any new role or after a significant role change
- When feeling overwhelmed by requests that "aren't really my job"
- When scope creep has accumulated to the point of unsustainability
- When you need to push back on requests but lack a reference point for what's in vs. out of scope
Common Failure Mode
Undefined scope with default-yes: every request feels like it could be your responsibility, so you accept it. This produces a role that expands indefinitely — limited only by your capacity to burn out. The boundary is set by exhaustion rather than by conscious design.
The Protocol
(1) Write two lists: In-scope (tasks, responsibilities, and decisions that are genuinely part of your role). Out-of-scope (tasks that are adjacent to your role but not part of it — these are the scope-creep vectors). (2) For in-scope requests → default to yes. These are your job. (3) For out-of-scope requests → default to no. Use Acknowledge, boundary, alternative — this three-part structure preserves connection while maintaining limits's three-part structure: "I understand this needs attention [acknowledge]. This falls outside my current scope [boundary]. [Person/team] might be better positioned to handle this [alternative]." (4) For conscious exceptions (you choose to take on an out-of-scope task) → document the exception and its expiration. "I'll handle the Q3 presentation this time, but this should be reassigned for Q4." (5) Review scope documentation quarterly — roles evolve, and the boundaries should evolve with deliberate updates rather than silent expansion.