Staff level is, for most people in tech, the ultimate career goal. Staff is typically the 5th level in the engineering ladder, although it’s often called L6 due to Google's leveling system.
The first three levels using the software engineer role are SWE I (right after college), SWE II (1-2 years of experience), SWE III (2-4 years of experience). I use the following framework to define the persona behind each of these levels:
SWE I is early in their career, in their first job, just focus on learning.
SWE II is all about execution, they should be able to pick up the next batch of work (about one week long) in a project and deliver it on time and with quality.
SWE III is expected to take on a vaguely defined initiative that spans a quarter or so, figure out the plan, and execute it (including delegating work to more junior teammates).
From SWE I to SWE III, progression is mainly in the hands of the individual contributor (if there is budget, of course). My rule of thumb: if someone meets or exceeds expectations for a year, I want to see the same performance in the second year to ensure it wasn’t just a fluke, and then I promote them.
The next level is Senior SWE, where expectations flip: instead of being told what to do, the Senior SWE is expected to tell us what to do next and where to invest. I still see Senior SWE as an evenly spaced progression after SWE III. However, the transition is harder because business needs become an additional factor in promo decisions. Senior level is a perfectly fine place to “retire.” While failing to progress from SWE I to SWE III might raise concerns, there’s no requirement for a Senior SWE to aim for Staff.
Staff SWE is not just another incremental step: it’s a phase transition. To justify a Staff-level role, an engineer needs to operate across multiple teams. A Staff SWE is not just a more senior engineer, it’s a fundamentally different role with very high expectations (which is why many Senior SWEs choose not to go for it).
There are four archetypes of Staff SWE
The Solver
The Tech Lead
The Architect
The Right Hand
In my career, I’ve worked mainly with Solvers and Tech Leads, which are also the most common archetypes according to Will Larson. Architects are less frequent (and as a job title Architect has now bad connotations), and the least common all is the Right Hand.
One Solver Data Engineer I worked with was very allergic to collaboration. He was open to mentoring others and providing guidance, but struggled to share his own initiatives. Tracking progress with him was difficult, and I had to “trust the system.” He would disappear into a bubble for weeks, without any updates, only to reemerge with an elegant data model that solved multiple existing and future use cases. Over time, we became dependent on him, so I assigned a couple of Data Engineer III to learn his craft and create some level of redundancy.
He had unique, deep domain expertise in a specific niche, and as a result he found it difficult to create impact outside his specific area. This led to frequent discussions with leadership because one of the most common misunderstandings about Solvers is assuming that they all thrive by jumping to new domains all the time. One of my Solvers Data Scientist was exactly like that. He craved new challenges across different domains, jumping from MLOps for a couple of quarters, to A/B testing infrastructure, then to ML models for time-series forecasting.
One of my best Data Scientists was a fantastic Tech Lead, somewhat out of necessity. She would have preferred to spend more time as a Solver, but she had a natural talent for organizing a squad and mentoring junior teammates. Tech Leads are strong candidates for the transition to the management track, because they have deep domain and technical expertise, but also the ability to deliver impact through others. As the team scales, you need to find ICs who can lead a squad and own a specific area of responsibility (AOR), and potentially spin off a new team out of it. However, do not position the people management track and the only next step in their career. People management is a whole different game, and they need to be ready to take the leap on their own.