I have just completed building the first version of our Engineering Career Ladder together with our Head of R&D at TimeLog. The ladder will serve as a tool for developers (and QA) as well as the technical leadership to grow each developer and in effect all teams.
So why build a career ladder in the first place? To make it very visible how to progress, gain experience and grow in our R&D organization. Most people strive to advance in their career over time, but it’s not always easy to know what is expected from each individual to progress, and the technical leadership might not even know – or at least it’s subjective and implicit. We have decided to spend the time to carefully craft a career ladder to clearly set the expectations for our technical crew at each level. In effect, we are defining what a great engineer does, and what he/she is, for us. Naturally, this could vary based on the company culture and leadership, but after looking into what other companies have done, it aligns quite nicely. For example, we found inspiration in the published ladder from the team behind Rent the Runway, the engineering career framework from Buffer and engineering career development at Etsy. Also the blog by Chuck Groom and a talk by Marco Rogers is good input for crafting the ladder.
I would have likes even more examples, so I have decided to share ours for others to get inspiration from. The TimeLog Career Ladder for Engineers ended up like this:
We ended up with 7 different positions, each of them defined as the scope of influence, how work is conducted (and expected) by the role, the hard competencies required, anti-patterns that a developer at a given level shouldn’t have and finally which kind of ownership is expected.
Apart from being a great alignment tool within the department, I also see this a great tool for the technical leadership to pin-point each developer within the matrix and figure out which elements to coach and nurture. Naturally, these items can also be added to each developers’ IPM (individual performance management) plans as action points to enhance on.
Another great benefit is that the career ladder also clearly sets the scene for discussions about promotions. Well in advance, a developer can prepare for negotiating a promotion based on the ladder – naturally other things might factor in as well, but you get the idea. By introducing a career ladder with this level of details might also cause developers to transition up and down from their current title, so I suggest to validate it carefully before making it public. In TimeLog, none of our developers needed to transition as part of introducing this, but we have got a more clear understanding of who under- and over-performs based on their current level from an objective point of view. Both cases gives great material to grow each developer to new levels. Another interesting experience is, that we now see how some colleagues at the same level, wildly differ in strengths, which fortunately correlate with their personalities.
To make it a more visual experience, we have attempted to flag/color each statement that is either not met or require coaching based on each individual in an Excel spreadsheet. Below is the results on myself (it’s blurry by design, but you may correlate with the ladder itself, it you find the need).
An interesting fact is that each individual might have a shape of flagged cells. Consider a developer which conducts work as expected according to his/her role as well as having the right competencies, but a lot of anti-patterns flagged. An inverse L shape. Or a developer with no anti-patterns and conducts work as expected, but lacks competencies. An upside-down T. Which one do you prefer? Competencies can be taught, anti-patterns require behavior change.
One thing we noticed during this flagging exercise was that a few of the anti-patterns changed scope based on the anticipated level of developers. For example, the demands behind “Disregards opportunities where he or she can have a positive impact” is very different from Tech Lead to Software Engineer III. In any case, we decided to stick to this model for now and then evaluate after using it for a while. After all, it’s just one tool in toolbox to align and grow developers.
I hope this gives some inspiration into creating your own career ladder. I would love to hear feedback and get questions about this.
Søren Øxenhave 