The Engineering Ladder

My perspective on Software Engineering¹ is that it can be understood as a kind of game. When you make great software that everyone loves and uses, you win.

At Pachyderm, we’re updating and extending our engineering job ladder right now. The result of that project had to meet the practical of needs of a lot of different groups, but, now furnished with the reflection that the project required, I wanted to use the freedom of my personal blog to lay out my newly augmented understanding of engineering levels.

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 an essential truth, even though a lot of tech companies don’t exactly understand it and are just trying to keep up with market compensation. Specifically, I think every tech company is playing the Software Engineering game above, and the engineers employed at these companies, as these companies’ instruments of execution, are playing the Software Engineering game personally in the course of their job. Each “level” of the ladder, then, reflects the level of the software engineering meta-game that one is playing:

Level	How are you playing the game
L1	I come to work and one of my colleagues tells me what change to make in the code. I want to be able to make changes on my own without help.
L2	I come to work and one of my colleagues gives me part of a product change we want to make. I want to complete a full project end-to-end on my own.
L3 (Senior)	I come to work and implement product changes, competently completing projects end-to-end on my own (or occasionally deputizing others). I don’t really design my own solutions to user problems, though, or if I do, my solutions rarely get many actual users. I want to solve some people’s problem for them and build something they actually use.
L5 (Staff)	I can reliably solve users’ problems, but a lot of these problems arise from broader structural issues. I want to stop playing whack-a-mole and give users a better environment to work in.
L6 (Principal)	I solve or apprehend the structural issues that make users lives hard. When users use my work, they have fewer, easier problems than they would otherwise.

One aspect of the above that we discussed at length in writing our job ladder is that the most senior levels are distinguished by the impact of their work, but that that can be hard to estimate. Specifically, if a user makes a huge impact with a small change, are they automatically qualified for promotion?

At both of the companies at which I’ve worked, the criterion for getting promoted has been “you’re operating on the next level already”. That standard, in addition to guarding somewhat against the Peter principle, clarifies the difference between e.g. a Senior Engineer who happened to wander into a high-impact fix and a Principal Engineer who identified the fix as some kind of user-experience linchpin and dove in immediately. If an engineer does something exceptionally impactful, that work can only sensibly be evaluated in the context of their longer track record.