Software Engineer Leveling & Expectations

There’s a persistent pattern around promotions in the software industry. It goes something like this: a software engineer begins their career, learns a lot over a couple years, and then thinks “How do I get promoted?” Surely being a Senior Engineer is better, but in most companies, this engineer will have received little to no guidance on how to level up.

“People get promoted for being on the right projects, and I’ve never had a chance to be on one of those projects.”

This method of rewarding only those who work on high-visibility projects, a poor measure of skills development and impact to the company, is nevertheless used by many companies to promote people. It’s not a good method for many reasons, an important one of which is its bias against people from underrepresented groups in tech. Getting promoted should not be the result of how well-liked you are, which seat you happened to be in when the next exciting project team was assembled, or even how long you’ve “waited in line” for such a promotion.

Promotions should be based on recognition of skill development and consistent demonstration of specific behaviors that lead to greater and more positive impact on the business.

In other words, doing a better and bigger job should lead to a…better and bigger job. It doesn’t seem strange when phrased that way, but it’s disheartening to see how many companies fail to do even this bare minimum. To give them some benefits of doubts, it’s worth asking what it means, specifically, to become a more skilled software engineer, which behaviors should be demonstrated consistently, and what type of impact on the business matters most.

Wouldn’t it be handy, then to have a relatively comprehensive set of skill and behavioral expectations for each level of the role Software Engineer? I agree: it would. I have written a few of these sets of expectations for a couple different companies, and tuned them with feedback from real software engineers and managers, and I’m now open-sourcing my generic framework:

Software Engineer Leveling Matrix

I expect this to be a living document—it’s on GitHub, after all—and I welcome feedback and community improvement. It’s licensed as CC-BY 4.0, so feel free to reuse and remix it internally, externally, in talks, in trainings, etc. with attribution.

I hope this helps at least a few companies make better paths for their software engineers, along with fair and consistent evaluations at every level.

I will publish some companion material on the best ways to use the matrix, along with further updates.