Write what your role includes AND excludes — default…

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.

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…'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.