10 Years of Engineering Ladders

On March 26, 2015, I posted a short blog post to the Rent the Runway engineering blog, Sharing Our Engineering Ladder, with a quick intro to the RTR engineering career ladder and links to both spreadsheet and long-text versions. This was one of the first public engineering career ladders that came with a clear distinction between management and IC levels, and meaningful details about the requirements and expectations at each level.

I published these resources because, at that point, most of the companies that were writing ladders were either a) getting some consultant like Radford to help them bootstrap something, b) copying a big company that they had worked for in the past, or c) stealing a template from a friend’s company and modifying it. For teams without the resources to hire consultants, prior big company experience to draft on, or friends to copy, they were basically stuck. I knew that what we had created at RTR was special, because it had many different sources of inspiration, contribution from a smart team of tech leads and managers, and a lot of care behind it. And as an open source person, I believe in the value of sharing not only ideas but actual work for others to use, build upon, and expand, for the greater benefit of the tech community. Publishing the ladders for widespread use was an easy decision, and one that has had an impact on the industry: I still get occasional thank-yous from people who have used it as a baseline all these years later.

These days, this sort of thing is almost passé. Almost every company has done this work, many inspired by the very ladders we published, but others inspired by far different approaches published over the years. I am proud to have stoked a simmering conversation among leaders in the tech industry. It proved what I always knew: most people want a starting point to play off of when designing organizational processes as much as they want one for technical work. Even if all the starting point inspires is “ew, not this!”, it gives you something to riff off of.

Advice For Writing

I’ve done this exercise again at least twice over at different companies in the past decade, and it’s always a challenge. So here’s some brief advice for those embarking on this process.

1. Don’t let (or make!) HR do all of the work. It’s really not their job to define expertise in your functions.
2. Details matter. Your ladder should be more prescriptive than a horoscope; it’s impossible to avoid all subjective language like “increasing complexity”, “large systems”, “high impact”, but pay attention to where you use that and try to provide ways of roughly measuring this where possible.
3. One great way to flesh out details is writing long-form text to accompany the spreadsheet-style ladder. I think it’s a shame people don’t do this more, even if they don’t publish it, because it helps you envision the work and catch things you might miss when writing bullet points.
4. You should not try to create a ladder that functions as a pure checklist or scorecard that guarantees promotion if people check enough boxes; promotions are as much about the needs of the organization as the skills of the employees.
5. Be honest: not every job family has ladders that start at the bottom and go to the top. Some should start in the middle and go up; some may start at the bottom and only go to somewhere in the middle. Don’t promise people that they can become the VP of X just because some people do job X, and don’t pretend that you should hire people straight out of school into jobs that are specializations that you only take on after years of working as a generalist.
6. Also, maybe you don’t need to create a job ladder for literally every job. There’s something to be said for the finance company catch-all analyst/associate/VP/MD scale to cover everyone, with ladders for large population jobs (such as engineering) where it makes sense.
7. Err on the side of more early-career levels rather than later-career ones. Assuming you are still hiring junior engineers (you really should be even in this AI era), the good ones will learn quickly and want to see career progress in their first few years of working. Once the path splits IC/management, just match the management levels and you’ll be fine.

Are Ladders Passé?

Even as I write this, I’m not sure anyone will care. The industry is in backlash mode, and I wouldn’t be surprised to see many companies try again to make the “flat” organization work. But even with the aid of AI, I’m not convinced that we’ll overcome the human instinct to gather in groups and create leaders of those groups, and fight one another for power of those groups. The Tyranny of Structurelessness has yet to be overcome, and for those who still care about creating strong, transparent, equitable organizations, this work matters. Just please don’t make me personally write them again!

Enjoy this post? You might like my books: The Manager’s Path, available on Amazon and Safari Online, and Platform Engineering: A Guide for Technical, Product, and People Leaders, available now!