Rent the Runway

Mar 26 Mar 26 Sharing Our Engineering Ladder Camille 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 f