Finding Staff-Level Scope
👋 Hi, this is Ryan with another edition of my weekly newsletter. Each week, I write about topics in software engineering, big tech/startups and career growth. Send me your questions (just reply to this email or comment below) and in return, I’ll humbly share my thoughts (example past question).
My biggest gap going from Senior to Staff Software Engineer was in finding staff-level scope. My manager paired me with a few mentors to fix this. I took tons of notes and followed their advice, which helped me get promoted to the Staff level in 2 halves. Here’s what I learned.
What is Staff-Level Scope?
Engineering work meets the Staff bar based on a few high-level characteristics:
Complexity — Solving problems that senior engineers can’t
Impact — Wins span more than just your team and achieve a significant part of collaborative goals
Workstream size — Many engineers involved and roadmap spanning quarters
To become a Staff Engineer you need to find work that fits these criteria and then deliver it. Otherwise you can’t grow to that level no matter how hard you work. We’ll go over two approaches for how to find staff-level scope.
Finding “Top Down” Opportunity
It is part of the engineering manager’s job to know what the top problems their teams are facing. Because of this, your leadership chain is likely aware of some staff-level problems. To find potential work you can ask your manager or skip manager about their top-of-mind problems and opportunities.
This approach is easiest since there is already alignment on the work’s importance and potential business impact. Sourcing work in this way also has the added benefit of building trust which can lead to future opportunities.
For example, my director was aware of my work since I’d been consistent and reliable on past projects. Because of this, he gave me the opportunity to lead two org-wide initiatives that contributed to my promotion.
Finding “Bottom Up” Opportunity
What if there is impactful work that your management chain isn’t aware of yet? You have the opportunity to convince people that the work is important and then see it through.
This approach is riskier since there’s an extra step in convincing others. However, it’s the more common path I see for engineers to have unusually fast growth. It also helps you build the skill of influencing others.
Although riskier, this “bottom up” scope has one major benefit in that it’s permissionless. No one needs to trust you to hand you the scope; you create the scope yourself.
My promotion to the Staff level came from a “bottom up” workstream. I championed investment in compute efficiency at the right time for our org. This led to massive compute savings wins I wrote about on Meta’s engineering blog. We were lucky enough to have Zuck himself write about the savings too.
Finding staff-level scope is hard. Often, such scope may not exist on your immediate team. When this happens, think outside of your immediate team (e.g partnerships or within your larger engineering org). That is a key behavior difference between the Staff and Senior levels.
If you have any questions, feel free to reply to this email or drop a comment with your thoughts. I will reply to every comment as usual.
Join 4000+ software engineers who read my Substack and support my work
Thanks for reading,
Ryan Peterman