Not too long ago, Camille Fournier at Rent the Runway shared the software engineering ladder their team uses for promoting engineers within the development team. I thought I’d take the opportunity to share the ladders we use at Chartbeat and look at how you might structure a ladder for your startup.

First, The Basics.
A ladder is an outline of expectations for people at various levels within the company. Many companies of varying sizes have them, you may vaguely remember seeing one during a new hire orientation, or you may have revisited it regularly if you’re gunning to climb the ladder quickly. They serve both as a means for people to know what’s expected of them to get a promotion, and a framework for managers to know when to promote someone.

This is Chartbeat’s ladder for Backend Engineers. We have a separate ladder for Frontend Engineers and Designers, and another ladder for Data Scientists. For comparison, here is Rent the Runway’s ladder and Joel Spolsky’s ladder for Fog Creek.

I hadn’t seen Camille’s or Joel’s prior to doing ours, yet they have a lot in common. I guess there are some universal truths in charting growth once you know a little about how engineers and engineering teams work.

Do I really need a ladder? HR is such a drag.
If your company is just starting out, you probably don’t need a ladder. However, it’s reasonable for an engineer to start thinking about promotion eventually, and you’ll need to address that. You may be able to start by giving promotions in a more haphazard manner, but as the team grows you need to do it evenly and with some justification.
If your company is more than 2 years old, and you have employees that have been around since the beginning (and I hope you do) it’s time to start thinking about it. I joined Chartbeat when it was just over 2, but it had had an extended gestation at Betaworks and was just getting an established engineering team. I waited 3 years to put a ladder in place, which was probably a bit longer than I should have.

It’s also worth noting that raises are not tied directly to the ladder at here at Chartbeat. A move up the ladder will always come with a significant raise and title change, but smaller raises can happen in the mean time.

Two Paths
The Chartbeat and RtR ladders both include a concept of “Manager” and “Architect” tracks. This is a common distinction in software engineering teams and one that most developers will face at some point in their careers. “Do I want to build bigger and better systems, or do I want to manage bigger and better teams?”

Both jobs require leadership. For an architect, it’s more about thought leadership. Thinking long term and getting a team to share your vision. For a manager, it’s more about hiring, team organization, and helping people up the ladder.

There’s no right answer to this, it’s all about your personality and preferences. They are not typically mutually exclusive either. In my experience, if you’re excellent at one of them you’d probably be excellent at the other as well. Maybe this is why Fog Creek makes no distinction between the two (in their ladder, anyway).

Experience Counts
The Chartbeat ladder does not explicitly include years of experience in the requirements for moving up. However, I’ve told the team to expect it to take 2-3 years to move up a stage. RtR has what looks like years of experience associated with each stage on the left side of their Ladder. Fog Creek disassociates experience from skills entirely, but does tie it to salary.

How experience relates to the value you bring to a team as an engineer is not always obvious. In one regard, it could be argued that a new grad with all the skills of a developer with 25 years of experience should be paid the same, but are they really the same? What metrics do you use for measuring experience and how is it valued?

For starters, the top rungs of the ladder will include some things new grads will not have done at a company of scale. “Successful platform cycle launch”, “Plays a key role in developing multi-year technology strategy”, or “Owns the development for a major project” are not something you will have done without a few years under your belt.

But more to the point, if you are an experienced engineer bringing your hard earned knowledge to bear on your work; sharing experiences, offering insight and guidance, you are delivering far more than quality code to team.

Climbing The Ladder
When it comes down to it, creating a ladder is the easy part. How you apply it is much trickier. You can use a form, have a meeting, write a letter, but these are only useful if they create honest discussions around performance. An honest discussion, structured around the framework you’ve provided your team, is the best and most transparent way to help someone grow their career. Those discussions can be hard to have, but a ladder will help you focus on tangible actions both good and bad.

As a an engineering manager it’s your job to help your team up the ladder. That’s not just because it’s good for your business, it’s your commitment to them when they joined your team. If I didn’t believe that I’d have stuck with writing code instead of managing coders. I could have avoided a lot of meetings, but I like to think I’m helping good engineers along their way.