Staff Scope Selector

---
name: staff-scope-selector
description: Help a staff+ IC (or one aspiring) choose the highest-leverage SCOPE to work on — not "what task is assigned" but "what should I pick to maximize impact at my level?". Identify the org's important under-owned problems, match them to leverage archetypes (multiplier/unblocking work, direction-setting, hard problems others avoid, critical glue) and the person's strengths, avoid the traps (only-fun-work, only-firefighting, scope too narrow for the level, invisible glue with no attribution, over-reaching into others' owned scope), and choose deliberately with an explicit rationale and an explicit NOT-doing list. Use when a senior/staff+ IC is choosing what to work on, when their impact feels scattered or below their level, or when picking a next big bet. Do NOT use to rank a given backlog (prioritization-frame-picker), plan the team roadmap (roadmap-under-uncertainty-planner), or document impact already delivered for promotion (promotion-packet-writer).
---

# Staff Scope Selector

**Reading key:** an individual contributor (IC) is an engineer who does not
manage people; staff+ means staff level or above (staff, principal and higher
technical levels).

## Purpose

The step from senior to staff+ is the step from "execute what's assigned"
to "choose what's worth doing" — and it's where strong engineers stall,
either firefighting reactively, chasing shiny tech with no impact, or
doing excellent senior-level work that never adds up to staff-level
leverage. This skill helps a staff+ IC (or one aspiring) select scope
deliberately: find the org's important, under-owned problems; match them
to genuine leverage (work that multiplies other engineers, sets
direction, or solves the hard thing everyone avoids) and to the person's
strengths; dodge the traps that make busy people low-impact; and commit
to a scope with a stated rationale and an explicit list of what they're
NOT doing. It's about choosing the work, not ranking a backlog or
documenting impact already delivered.

## Use When

- Use when: a staff+/senior IC is choosing what to work on next and wants
  the highest-leverage scope, not just the next ticket.
- Use when: someone's impact feels scattered, reactive, or below their
  level despite working hard.
- Use when: picking a next big bet / area of ownership at staff+ level.
- Use when: an aspiring-staff engineer needs to find scope that
  demonstrates staff-level leverage.
- Do NOT use when: the task is ranking a given team backlog by value/
  effort — that is `prioritization-frame-picker`.
- Do NOT use when: the task is planning the TEAM's roadmap over horizons —
  that is `roadmap-under-uncertainty-planner`; this is one person's scope.
- Do NOT use when: the task is documenting impact ALREADY delivered for a
  promotion case — that is `promotion-packet-writer`; this chooses FUTURE
  scope.

## Inputs to Inspect

1. The person's level and trajectory: current level, the level's
   expectations for scope/leverage, and whether they're aiming to grow
   into the next.
2. Their strengths and interests: what they're unusually good at and drawn
   to — leverage is highest where strength meets org need.
3. The org's important problems: the high-value problems, especially the
   under-owned ones nobody is driving.
4. The current portfolio: what they're working on now, and whether it's
   leverage or busy-ness (firefighting, shiny work, invisible glue).
5. Ownership boundaries: who owns what, so chosen scope fills a gap rather
   than over-reaching into someone else's area.

## Workflow

1. **Anchor on level-relative leverage.** Scope is judged against the
   level: staff+ impact multiplies others or moves the org, it isn't just
   more/harder individual output. Name what leverage means at this level
   before choosing.
2. **Find the important under-owned problems.** The best staff scope is
   usually a high-value problem nobody owns — the gap between teams, the
   decision nobody's making, the system everyone complains about but no
   one drives. List candidates.
3. **Match to leverage archetypes and strengths.** Map candidates to real
   leverage: multiplier work (unblock/enable many engineers),
   direction-setting (the technical strategy others build on), the hard
   problem others avoid, or critical glue. Weight by where the person's
   strengths fit — impact is highest at that intersection.
4. **Screen against the traps.** Reject or fix scope that is: only-fun
   (shiny tech, low impact), only-firefighting (reactive, no direction),
   too narrow for the level (senior work relabeled), invisible glue
   (valuable but with no attribution path — add visibility or reconsider),
   or over-reach into someone's owned scope (align first).
5. **Choose deliberately with a rationale.** The scope is the person's own
   career choice, so teach it rather than pick it for them. Define
   *leverage* (impact that multiplies others or moves the org, beyond one
   person's output) and *non-scope* (work they will explicitly decline or
   hand off) in plain language. For each screened candidate give why it
   fits (leverage × fit × org need), its pros and cons, and its cost in
   time and attention, alignment setup (manager or owner conversations),
   ongoing upkeep, and any budget or headcount it needs, or unknown.
   If level, strengths, or org priorities are missing, ask only for one
   missing fact per turn, one atomic discovery question at a time, until all
   three are known; only then recommend one, say why and what fact would
   change it, then ask exactly one atomic decision question. Once the
   person chooses, state WHY and what they're NOT doing, so the focus is
   real. A staff engineer who owns everything owns nothing. The answer is
   their preference; it claims no one else's owned area without alignment
   and commits no budget or headcount.
6. **Make the scope legible.** Ensure the chosen work is visible and its
   impact will be attributable (the glue-work trap is invisibility). This
   also feeds a future `promotion-packet-writer` case — but that's a
   separate, later job.
7. **Deliver** the scope selection in the Output Format: the options and
   recommendation with the one question (or only the discovery question
   when a decisive fact is missing). An answer to a discovery question
   supplies a fact, not the decision: while any of level, strengths, or org
   priorities is still missing, the next turn asks only for the next missing
   fact; once all three are known, the next turn presents the options and
   recommendation and asks the decision question. Only the answer to
   that decision question fixes the chosen scope, the rationale, the
   leverage type, the fit, and the explicit non-scope (until then, mark
   these as a provisional draft for the recommended candidate).

The staff archetypes, the leverage-vs-busy-ness test, the trap catalog,
and the scope-rationale format:
[references/staff-scope-sheet.md](references/staff-scope-sheet.md).

## Output Format

```
STAFF SCOPE SELECTION — <person/level>
Level leverage:  what impact means at this level (multiplies others / sets direction)
Candidates:      important under-owned problems considered
Choice:          plain terms; per candidate why/pros/cons, time/alignment/upkeep cost or unknown;
                 recommendation + what would change it; ONE question — the person decides
CHOSEN scope:    (after the answer to the decision question; else "provisional: <recommended>")
                 <the scope> — leverage type=<multiplier|direction|hard-problem|glue>; fit=<strength>
Rationale:       (after the answer) leverage × fit × org-need — why this over the others
NOT doing:       (after the answer) <explicit non-scope, so focus is real>
Trap check:      not only-fun / not only-firefighting / not too-narrow / glue is visible / no over-reach
Legibility:      how the impact will be visible + attributable
Boundaries:      rank backlog → prioritization-frame-picker; team roadmap →
                 roadmap-under-uncertainty-planner; document past impact → promotion-packet-writer
```

## Validation Checklist

- [ ] Leverage is defined relative to the LEVEL (multiplies others / moves
      the org), not as more individual output.
- [ ] Candidate scope includes important UNDER-OWNED problems, not just
      what's already assigned.
- [ ] The chosen scope maps to a real leverage archetype AND the person's
      strengths.
- [ ] It's screened against the traps (only-fun, only-firefighting,
      too-narrow, invisible-glue, over-reach).
- [ ] Discovery asks one missing fact per turn until level, strengths, and
      org priorities are all known; no recommendation is made before then.
- [ ] The person makes the choice: terms defined; each option's why,
      pros/cons and cost-or-unknown; a recommendation plus what would
      change it; one question; the answer grants no authority. The chosen
      scope then gets an explicit rationale AND an explicit NOT-doing list.
- [ ] Invisible/glue scope has a visibility/attribution path or is
      reconsidered.
- [ ] Backlog-ranking, roadmap-planning, and promotion-documentation are
      handed to their owning skills.

## Gotchas

- Working hard is not the same as leverage. Firefighting all quarter feels
  productive and demonstrates no staff-level impact — it's senior
  execution on repeat. Direction and multiplication are the level.
- Shiny-tech scope (the rewrite in the trendy framework) is fun and
  usually low-leverage. Pick the boring high-impact problem over the
  exciting low-impact one.
- Glue work — the coordination, the unblocking, the unglamorous
  integration — is often the highest real leverage AND the most invisible.
  Do it, but build in the attribution, or it advances the org and not the
  engineer.
- Owning everything is owning nothing. Staff scope needs a NOT-doing list;
  without focus, the leverage dilutes into being spread thin.
- Over-reaching into another person's owned scope creates conflict and
  undermines them. Fill gaps and align on shared areas; don't colonize.
- Scope too narrow for the level (a well-executed feature) caps impact at
  senior no matter how well done. Match the ambition to the level.
- This chooses FUTURE scope; it doesn't document PAST impact. If you're
  assembling evidence of impact already delivered, that's
  `promotion-packet-writer`.

## Stop Conditions

- The task is ranking a given backlog → route to
  `prioritization-frame-picker`.
- The task is planning the team's roadmap → route to
  `roadmap-under-uncertainty-planner`.
- The task is documenting impact already delivered for promotion → route
  to `promotion-packet-writer`.
- The highest-leverage scope requires authority or headcount the person
  doesn't have, or entering someone else's owned area → surface it as an
  org/manager decision to align on rather than unilaterally claiming the
  scope.

## Supporting Files

- [references/staff-scope-sheet.md](references/staff-scope-sheet.md) — the
  staff archetypes, the leverage-vs-busy-ness test, the trap catalog, and
  the scope-rationale format.
- `evals/evals.json` — behavior cases including the firefighting-to-
  leverage shift, the glue-visibility fix, and the over-reach alignment.
- `evals/trigger-evals.json` — discrimination against `prioritization-frame-picker`
  (rank backlog vs pick personal scope), `roadmap-under-uncertainty-planner`,
  and `promotion-packet-writer` (future scope vs past impact).