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

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. Pick the scope and state WHY (leverage × fit × org need) — and, as importantly, state what you're NOT doing, so the focus is real. A staff engineer who owns everything owns nothing.
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 chosen scope, the rationale, the leverage type, the fit, and the explicit non-scope.

The staff archetypes, the leverage-vs-busy-ness test, the trap catalog, and the scope-rationale format: 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
CHOSEN scope:    <the scope> — leverage type=<multiplier|direction|hard-problem|glue>; fit=<strength>
Rationale:       leverage × fit × org-need — why this over the others
NOT doing:       <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).
• The choice has 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 — 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).