Originally posted 2022-10-01, updated 2025-03-30
Due to market dynamics, I think companies across the tech industry eventually converge on approximately the same shared engineering ladder. In my opinion, this shared ladder reflects a skill trajectory that is essential to software engineering (and probably most creative pursuits).
When I first wrote this post, we’d just updated and extended our own internal engineering ladder at Pachyderm (R.I.P.). This update was a big project, the result of which had to meet the practical needs of a lot of different groups. Finishing it required me to read and think a lot about the engineering ladder, so I wanted to use the freedom of my personal blog to lay out my newly augmented understanding.
My original post (and my contributions to Pachyderm’s engineering ladder) characterized software engineering as a sort of game: make software that lots of people love and use, and you win! The engineering ladder captured the level of meta-game each engineer was playing. Do you stew over tactical issues like variable names and module boundaries? Junior engineer. Do you ponder strategic concerns like user experience and product trends? Staff engineer! Since then, I’ve gained more management experience at more companies, and as I re-read this post and realized how much my thinking has changed, I decided to revise it and discuss that change instead. I think it reflects a larger change in my understanding of tech companies and the tech industry.
I now feel that the software-engineering-as-a-game framework, while amusing, was totally wrong. Tactics vs. strategy is not the difference between Junior and Staff engineers. Here’s how I think of the job ladder now:
| Level | Description |
|---|---|
| L1 | I don’t understand how this organization works or what’s expected of me day-to-day. When working on a project, I need help by default (how else can I learn?). I want to be able to get work done on my own. |
| L2 | I know how to go through the standard motions of completing a project, but if anything unexpected happens, I’ll need help. I get stuck a lot. I want to get through projects without anyone holding my hand. |
| L3 (Senior) | I come to work and complete projects. If I need help with something, I know where to get it; I unblock myself. I’m not too worried about how the projects are chosen. Or maybe I feel that the company should be doing something differently, but I can’t reliably implement that sentiment for one reason or another. |
| L5 (Staff) | I know how teams (like mine) are supposed to work in the context of the larger company, so when the team starts going in the wrong direction, I can come up with effective, realistic solutions using my experience. I also have good communication skills, so I can convincingly explain to stakeholders why a different approach will be better for the company. Finally, I have strong project management skills, so I can coordinate the implementation of that approach. Company leaders know that I have a track record of effectively solving technically, politically, and organizationally complex problems, so they seek my guidance in difficult situations. |
| L6 (Principal) | I’m highly regarded in our industry, and I have a network of industry contacts. When the company starts going in the wrong direction, I can come up with effective, realistic solutions using my experience and the expertise of others within my network. I can organize the implementation of those solutions with managers and engineers across the company as well as external colleagues and partners. Industry leaders know of me, and I can have significant influence on industry-wide decisions and trends. |
Staff engineers
This description was the main thing I changed when revising this post.
To understand why Staff engineers have more prestige and higher salaries than Senior engineers, you must first understand what types of problems tech companies typically have, and then you must understand how Staff engineers make themselves indispensable to their employers.
At most companies where I’ve worked (or on most teams, at larger companies), the typical state of affairs is that you have 10,000 problems that are absolutely guaranteed to kill your company/get your product cancelled at some point. In any given week, you have time to solve maybe two of those problems. If you can pick the two that will kill you first and solve them, you get to not die! One of the reasons this is hard is that every single person around you sees some subset of those 10,000 problems, knows that they’ll kill the team/company, and is panicked about it and demanding something be done. Therefore a default failure mode for companies is lack of focus, leading to inaction, leading to death by whatever the next problem is.
What makes Staff engineers awesome is not (only) that they have the best ideas, but that they can execute, and they can execute even when execution involves herding other people. Many people hit a wall here; they can write code (or whatever their job is) but they can’t communicate convincingly or keep a multi-person project organized.
This isn’t (only) a matter of having a silver tongue, either. You have to have ideas that are good enough to actually work and simple enough to be tractable, and you have to be able to explain those ideas compellingly to colleagues, and you have to be organized enough to make sure all aspects of implementing the idea are addressed. All of that is necessary. And at the end, you have to have actually solved an important problem. The reason Staff engineers are a big deal is because without them, the company tends towards quivering helplessly.
Wait, what are managers for?
There is obvious overlap between the skills and responsibilities of Staff engineers and managers. I must first note, though, that this question is backwards: Staff engineers typically make more money than Engineering Managers at the same level. The reason that Staff engineers and managers are at the same level in many job ladders is that Staff engineers should be able to do manager-sized projects (see also the concept of Completed Staff Work). Finally, while managers do (some of) this stuff too, the emphasis of their job is different. See my manager README; a manager’s job is largely planning, communication, and coordination, and “having ideas” is nice when it happens, but that’s not really the point. Managers are mostly an interface to their teams.
Why do companies have a level in the ladder for engineers who’ve developed a set of management skills, though? Because, as a practical matter, some engineers do learn them, and there’s a lot they’re able to accomplish afterwards.
Consider, in contrast, that there is a type of engineer out there who complains that their ideas don’t go anywhere, and what they seem to expect is for management to pick up their idea in a one-on-one, coordinate the entire implementation of their idea for them (or somehow dictate that the rest of the company must re-orient around implementing this idea), and then turn around and give them a promotion at the end. Those people aren’t Staff engineers.
What do you think?
As with all my posts, I hope this helped someone. I spent many of my early-career years trying to understand the inscrutable-to-me job ladder of my employer (“I wrote a design doc and showed it to another team; am I ‘working across teams’?”). But I also would love feedback from any readers on this post in particular, since the “standard job ladder,” insofar as it exists, is necessarily defined by what each company out there thinks. Please post a comment or send me a note if you’re so inclined!