Sometime in summer 2015, when preparing yearly feedbacks for my team at vaamo, I started formulating our team’s (engineering) ladder. Back then the concept of a ladder, the act of spelling out what the requirements and expectations for a specific role and position are, was pretty new to me. Still it immediately appealed to me.
And while working on vaamo’s ladder I came across many more ladders, many of them inspired by RTR’s ladder, or inspired to be shared by RTR’s sharing.
After a while, keeping tabs on all those published ladders became nearly impossible. Yet, I found it very inspiring and helpful to have a list of resources in the spirit of “that’s how others do it”, in order to pick and choose what works best for our case.
So in order to make it easier to get inspired by other companies’ engineering ladders, I decided to put together a complete list of all published engineering ladders.
When using any of the below ladders as a starting point, be aware, that you’ll need quite a bit of effort to adapt and develop your own understanding of what the roles’ and positions’ classifications mean for you and your organization.
- Rent the Runway
- Travis CI
- Urban Airship
- Intent Media
- Charles Krempeaux
- Fog Creek
- Cap Gemini
When looking at some of the other ladders, this is the one that kicked off many if not most of them to be shared.
I find it very well structured, approachable and it reveals deep thinking behind it. I especially liked the concept of the four pillars “Technical Skill”, “Get Stuff Done”, “Impact”, “Communication & Leadership”.
The ladder from Arty’s team, as shared by their CTO Daniel Doubrovkine has a much simpler structure than the RTR ladder, even though it says it’s much inspired by it.
While the ladder itself is not overly prominent in the slidedeck and video, the reasoning and story behind the compensation framework, which is based on the ladder, is very interesting.
Kickstarter’s engineering ladder, as shared by James Turnbull, features paths for Technical and Data people as well as People Management roles.
Each role and position, up to the CTO, is described in helpful and concise prose.
Urban Airship’s ladder covers engineers’ and operations’ paths as well as the respective manager ladders.
Similar to RTR’s ladder, Urban Airship’s organizes the
expectations towards each engineering and ops level around the concept of four
pillars, namely “Domain Knowledge”, “Teaching and Mentoring”, “Culture and
Leadership” and “Customer Success”. Notice the absence of anything
“Technical” from this list of pillars.
Management positions are described using three pillars “Scope and Impact”, “Team Development” and “Customer Success”.
Intent Media divides it’s engineering organization into three paths, namely “Team Contributor”, “Technical Leadership” and “Engineering Management”.
It provides a lot of context about how engineering in general is structured at Intent Media and all positions are described in a concise yet extensive prose. It’s very well structured, offers a lot of inspiration and conveys deep thinking that lead towards the ladder.
Chartbeat’s ladder is also built around four pillars, namely “Responsibilities”, “Expertise”, “Qualities” and “Objectives”. Furthermore it’s actually three different ladders for the paths Backend, Frontend/Design and Data Science.
The descriptions are very compact, thus require probably quite some effort in communicating and to create a shared understanding. Which of course is not necessarily a bad thing, as it’s nearly impossible to formulate a ladder that doesn’t trigger or even requires a discussion around it’s assumptions and definitions.
Very interesting and comprehensive read and bonus points for providing a very different approach to an engineering ladder, than most others in this list.
HT to Robert for sharing these links with me.
It’s extra helpful, as it contains specific reasoning in which circumstances titles are helpful or maybe even necessary, and why it’s a bad idea to have a ladder where the top technical level is something like “Senior Software Engineer”.
Honorary mention for the infamous ladder by Joel Spolsky which dates back to the year 2009 and is probably one of the first publicly shared engineering ladders.
Compared to the more recently shared ladders, it has a completely different approach and is the only one in this list, where “years of experience” is a measure of sorts. Which in my opinion, simply isn’t appropriate anymore. Go watch Konstantin’s explanation of how a better way to think about an employee’s value contribution to a company looks like.
So just to be clear: Don’t base your ladder this one, as there are better ways to arrive at compensation levels than “years of experience”.
Last year, we identified a need to redefine the career framework for our software engineers within the UK engineering teams and started work on a Capgemini Software Engineering grade ladder. The grade ladder is our team’s self-produced documentation to enable everyone, both inside and outside our team, to understand our ethos and values and what’s expected of them.