I gave a talk last year at the NYC CTO summit on how and why to introduce structure into an engineering organization (slides available here). I am a fan of structure and the clarity that it can provide an organization, despite its potential downsides. I'm not going to talk about the WHY very much in this post, but I thought it was about time that I helped with the HOW.
Creating an engineering ladder (that is, the job descriptions and levels of an engineering organization) is a daunting task. If you do a half-hearted job, you're likely to cause more problems than you solve. The very first ladder I presented to my team was based on the ladder at Foursquare*. It was very simple, with one or two descriptive elements per "attribute" of engineering (technical skill, communication skill, etc), and by all accounts worked very well for their team. I hoped that this style of providing fewer details would result in people being less obsessed with the ladder, less likely to try to negotiate their level on "technicalities". Boy was I wrong. Almost immediately I had engineers debating me over whether they were at the right level, and there was a great deal of anxiety and confusion throughout the organization. I left room for generous interpretation, and it made it difficult for me to explain what I really wanted and expected.
In addition to the ladder causing problems inside of my team, we were having a hard time evaluating candidates during interviews and determining what level to hire them into. Particularly at the more senior levels, it wasn't clear what the criteria for success really looked like. So, together with my tech leads and engineering managers, we rewrote the ladder to be more specific. It has been very helpful both for the process of reviews and promotion committees as well as for the process of hiring.
I have since shared my ladder privately with several engineering managers around the country who were looking for inspiration, and today we're making it public for the benefit of all. I'm sharing this ladder not to suggest that it is the be-all end-all of engineering ladders, but to give you what I hope is a more thorough starting point than you might have seen elsewhere. After all, no one is really writing these ladders from scratch, whether we pull directly from other companies (as this one does at points), or indirectly from our past experience, so the more data points the merrier.
Without further ado, I present our engineering ladder, in both spreadsheet, and long-winded text, warts and all. Please feel free to clone this ladder and update it for use in your own organizations.
*A special thanks to Harry Heymann, Jason Liszka and Andrew Hogue, authors of the original Foursquare eng ladder!
