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)
Before GitHub, the engineering career track I have been most familiar with looked something like this:
At GitHub in 2021, the 1st to 3rd is the same, with different terminology I’ll gloss over, but there are 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+ 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 the same. For example:
- Senior Engineers and Engineering Managers primarily focus on the engineering output of a single team
- Staff Engineers and Directors of Engineering primarily focus on the engineering output of a single group of teams/organisation/department (i.e. more than one team)
- Principal Engineers and Senior Directors of Engineering primarily focus on the engineering output of multiple groups of teams/organisations/departments (i.e. many teams)
- Distinguished Engineer and Vice Presidents (VPs) 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
The difference in responsibilities between an Engineering Manager and Senior Engineer is generally well understood. An EM should have regular 1:1s with their direct reports, 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 should have no people management responsibilities whereas 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 code 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). 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. After discussions with my manager, we agreed it was better for me to no longer be on the critical path for features.
As I embraced my staff engineer role, I found myself fitting into 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 feature 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, part of our performance review process.
When I became a staff engineer, I expected that I’d be doing less feature work and less coding. I probably code a little less than I expected to but I am happier with this than I expected to be.
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. Being a staff engineer has been a significant improvement for me for where I’m at in my career, family life and geographical location/timezone.
Despite it being a relatively well-trodden path in the technology industry at this point, there are limited resources to learn more about being a Staff+ engineer. Those I’d recommend are:
- The 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+ engineers can do (and all engineers, really) that is often 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
Thanks to Graeme Arthur, Sarah Vessels, Keith Duncan and Luke Hefson for reviewing this post and providing helpful feedback.