Rent the Runway

GlobalRemote

Requirements

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.
This is a beta feature to avoid spam applicants.

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.