What is a Staff (or Staff-Plus or Principal) Engineer?
In 2020, GitHub promoted me from Senior to Staff Engineer. This title (and role) seems commonplace and well understood at some technology companies but unknown and unused at many others.
The Engineering Career Track(s)
The engineering career track I have been (prior to GitHub) most familiar with looks something like:
At GitHub in 2021, 1-3 is the same (with different terminology I’ll gloss over) but at there’s effectively three possible choices:
- you stay as a Senior Engineer forever (this is supported and encouraged)
- you continue on the Engineering Manager (EM) track
- you progress on the Individual Contributor” (IC)/Staff-Plus track
The EM and IC tracks run in parallel so you have something like:
Generally, the reporting structures are across a level so that you can expect a Senior Engineer to report to an Engineering Manager, Staff Engineer to a Director of Engineering, etc.
The compensation scales and expected areas of influence for each level are also the same. For example:
- Senior Engineers and Engineering Managers mostly focus on the engineering output of a single team
- Staff Engineers and Directors of Engineering mostly focus on the engineering output of a single group of teams/”organisation”/”department” (i.e. more than one team)
- Principal Engineers and Vice Presidents (VPs) of Engineering mostly focus on the engineering output of multiple groups of teams/”organisations”/”departments” (i.e. many teams)
- Distinguished Engineer and Head of Engineering focus on the engineering output of the entire company
Similarly, Principal Engineers output is expected to affect the entire company and Distinguished Engineers output across more than just the company (i.e. the industry).
Differences between EM and IC tracks
It’s generally well understood on the difference in responsibilities between an Engineering Manager and Senior Engineer. The prior will (or at least: should) have regular 1:1s with the members of their team, will provide their performance reviews and, depending on the organisation, may provide some technical leadership, product management, project management or even coding beyond their (primary) people management responsibilities.
A Staff/Principal/Distinguished Engineer will generally not have any (or extremely limited) people management responsibilities where their EM/Director/VP counterpart will find that taking up a significant part of their role. The Staff/Principal/Distinguished Engineer will take responsibility for technical leadership, mentorship and is likely to still do some coding (and, in some cases, spend the majority of their time still doing so).
My staff engineer role changed from primarily feature coding work to engineering-wide work and feature non-coding work (e.g. scope adjustment, review, architecture). This happened after trying (and mostly failing) to do both for a while and agreeing with my manager which type of work was a better use of my time.
Increasing non-feature, time-critical commitments (e.g. mentoring, code review outside of the feature’s area, on-call, support existing staff projects, performing low-context fixes for my manager) caused me to be slow to complete feature coding work.
As I embraced my staff engineer role I found myself to fit in the “Solver” (and somewhat “Right Hand”) archetype. I am more useful as a value multiplier for other engineers rather than coding in areas where I have less context than other engineers.
I now optimise for unblocking others, being a “💩 umbrella” for other ICs, taking on high-urgency but low-context work and focusing on development experience for engineers at GitHub.
As I’m not part of a specific team, I fill out a weekly Geekbot report in Slack and keep track of my work in my GitHub project board. This increases the visibility of my work to others, stops things falling between the cracks and makes it easier to write my self-review for performance reviews.
I expected that when I became a staff engineer I’d be doing less feature work and less coding. I probably code a little less than I expected to but am happier with this than I expected to be.
Personally, I’ve been consistently and passionately disinterested in going into engineering management because I still like doing non-trivial amounts of coding and being evaluated based on that sort of work. For where I’m at in my career, family life and geographical location/timezone right now: being a staff engineer has been a big improvement for me.
Despite it being a fairly well-trodden path in the technology industry at this point, there’s limited resources to learn more about being a Staff-Plus engineer. Those I’d recommend are:
- The single most important thing I’d consumed is Tanya Reilly’s Being Glue talk. It’s a great way of thinking about the sort of work that effective Staff-Plus engineers can do (and all engineers, really) that can be undervalued. Find more from her at her LeadDev blog, personal blog and talks.
- Staff Engineer: Leadership beyond the management track book by Will Larson
- Staff Engineer stories/blog on Will’s staffeng.com site
- StaffEng podcast (also on staffeng.com). Check out my episode if you’re interested.
- Rands Leadership Slack’s