Volunteering for scope

Saying yes to everything is not ownership. It is fragmentation. Incomplete projects destroy trust faster than small scope ever will. One shipped project beats three half-owned initiatives.

When you volunteer, make the contract explicit with your manager: problem statement, success metric, time box, and what you will not do. That conversation is ownership in practice.

Three rules

1. Finish before you expand. If you already have a project in flight, the next "exciting opportunity" is usually a no — or an "after this ships."
2. Match the next-level gap. Strong technically but invisible? Pick work with a clear metric and a demo.
3. Prefer a natural finish line. "Make search better" is a career trap. "Cut p95 search latency from 800 ms to 300 ms for the top query class by end of Q2" is a scope you can own and prove.

Walking through a proposal

Managers and PMs say yes more often when the ask is cheap to evaluate. Use a half-page:

Problem: [pain + who feels it + rough frequency/cost]
Proposal: [what we would change]
Success: [metric + target + time box]
Effort: [S/M/L or engineer-weeks; who else is needed]
Non-goals: [what we will not do]
Ask: [approve / defer / pick alternative B]

Problem: On-call gets 4–6 pages/week from false-positive disk alerts
  on batch workers; ~90 minutes/week of engineer time, plus alert fatigue.
Proposal: Retune thresholds from p99 of four quiet weeks, add a
  10-minute pending window, document in the runbook.
Success: False pages from this rule under 1/month for the next quarter;
  real disk failures still page within 15 minutes
  (validate with a controlled fill test in staging).
Effort: ~3 engineer-days; needs SRE review of the threshold change.
Non-goals: Rewriting the whole alerting stack.
Ask: Approve for this sprint.

If they reject it, you still practiced senior behavior: you brought a framed problem, not a vague complaint. Save rejected proposals. Patterns of "we never invest in reliability" are career strategy data.

Talk about scope without arrogance by switching mode. With your manager, be direct: "I need a project that proves end-to-end ownership. Here are two candidates." With peers, be collaborative: "I can drive design and rollout if you own the storage slice." In writing for committees, adjectives only work when a skeptical reader can click evidence.

People who wait to be tapped often wait forever. People who grab scope without finishing earn the wrong reputation. The middle path is propose → contract → finish → broadcast.

Common mistakes

• Yes to every exciting opportunity. You become the person who starts everything and finishes nothing.
• "Make X better" with no number. You cannot prove the finish.
• Volunteering for more of what you already do well. That is comfort, not a gap.
• Vague complaints instead of a framed ask. Bring the half-page.

Check yourself

1. You have a migration in flight and a shiny new platform project appears. What do you say? After this ships — or no. Finish before you expand.

2. Why is "cut p95 search from 800 ms to 300 ms by end of Q2" a better volunteer than "make search better"? It has a metric, a target, and a finish line you can own and prove.

Key takeaways

• Finish before you expand.
• Volunteer for the gap your next level requires, with an explicit success metric.
• Write a half-page proposal: problem, success, effort, non-goals, ask.
• Propose, contract, finish, then broadcast.

Further learning

Next, make the finish count in making impact visible.