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 t…