So you want to write an Engineering career ladder?

So, you’re a founder, engineering manager, committee member, or other person/entity/collective that’s interested in introducing levels to your small (but growing!) company’s engineering team. Awesome! The good news first – there’s a ton of information available to you on the internet, including companies like Square/Block that have effectively open-sourced their ladders. The bad news is there’s a lot of nuance in when and how you roll out the framework to your team, and not a lot of guidance in that area.

While almost nothing is truly irreversible, levels are pretty damn close – they can be adjusted after the fact, but there’s no way to really roll them back once they’re out. Because of this, rolling levels out can seem daunting or scary, but it really shouldn’t be. In fact, if you’re reading this blog post, and others on the subject, and thinking “hey, maybe it’s time to start thinking about levels for my team”, well…

Let’s take a look at some of the considerations you should be thinking about before you present your shiny new framework to your team.

Why have levels at all?

Chances are you have some idea of what levels provide your team – but let’s make that explicit. What levels really do is make three things formulaic:

1. Expectation setting – Clear expectations aren’t just helpful for managers – they’re important for your reports too. Nobody likes to be in a position where they don’t know what they need to do, and how they’re doing. Levels make it easy to be explicit about these things, and gives you a repeatable framework to bring into performance conversations and career development. It’s honestly the biggest advantage you get from levels.
2. Compensation – You probably already have rough bands, with more experienced engineers sorted into the upper end of them. Great. Just like above, levels make them explicit, and allows you to easily compare engineers to ensure fairness, as well as design formulaic performance and tenure bonuses based on level.
3. Hiring – There’s really two aspects here, one is already covered: compensation. Properly written, levels allow you to sort a new hire into a band and write a fair offer for them. But they also allow you to easily plan headcount. – With levels, you can easily plan team composition and move budget around as needed.

The thing is, you can technically do all of this without levels. You probably already do – but you have to do it on a case-by-case basis. This is complicated, time consuming, and ultimately unnecessary. You may even be tempted by a flat org – hiring all seniors and holding them to the same expectations ala Netflix. Let me dissuade you – there’s enough variance in experience and aptitude in “senior” engineers that you’re really asking for trouble later on, as Netflix itself is finding out.

Better to roll out levels too early than too late

Levels clearly have advantages, but you might be thinking about some of the bad things that can happen: engineers focused on ladder-climbing instead of doing what’s best for the company, engineers afraid to speak their mind because a more senior engineer ‘outranks’ them, and a myriad of other possibilities. Levels are tied to compensation, so it’s natural that you’re going to run into some of these issues.

It’s easier to manage these concerns when your company is still on the small side. At smaller sizes, you can personally talk to all the individuals on the team and make sure they understand the intention behind levels and your framework. You can (and should) also get input from individual engineers as well as managers during the process of creating levels, which builds buy-in and ownership on your team. With big teams, you’ll need to be more selective of who you involve in the process just out of ability to manage the group size.

Ultimately, the longer you wait, the more it will seem like a Big Deal, and you will have far fewer opportunities to work one-on-one with the actual humans who are impacted by the change. In worst case scenarios like the one I mentioned with Netflix above, you have to deal with nasty organizational debt that frankly isn’t correctable – people will leave.

So how small is too small, and how big is too big? I’m not going to pretend I have a hard and fast answer here, but at 10 engineers, levels are a distraction. At 100, they’re a godsend. At Stytch, we rolled out levels when the company was around 50 people, with roughly 20 engineers, which is on the early side. At the end of the day, you know your team best, and should pick a stage before it becomes untenable to manually handle the things – namely, compensation and expectation setting – that levels take care of for you.

I described our early rollout to our team with the analogy of buying slightly-too-big pants for your growing kid – you can always wear a belt (in the case of this questionable analogy, context provided by your manager) while you grow into them.

“It’s all about impact”

This is the first sentence you see when you open Stytch Engineering’s career ladder. It’s probably the most opinionated feature of Stytch’s engineering ladder – we don’t require engineers at a given level to check all the skill boxes at that level. What we DO require is that engineers are able to personally deliver impact consistent with their level. This does a few things:

1. It helps hedge against some of the aforementioned things that can go wrong with levels.

If you don’t require everyone at, say, L5 to exhibit the exact same skillset, you prevent resource starvation and the bad things that come along with it. This includes things like fighting over the exec darling or technically challenging projects that are viewed as a path to promotion, etc.

2. It allows engineers to build their superpowers.

Much has been written on the subject of staff engineering archetypes, to the point where there are literal books on the subject, but realistically all engineers, regardless of level, have unique shapes and skillsets, especially if you’re hiring for spikes (and if you’re not, you should be). Focusing on their level of scope and ownership (e.g. impact) gives engineers the breathing room to achieve that in a way that makes sense to them as individuals. 

For example, one L5 may develop and roll out an incident process that ultimately gets adopted by other engineering teams, another may find and fix a complex cross-system bug impacting our largest customers, and yet another may lead a team shipping a critical product or initiative for their team. As long as they’re producing consistent outcomes consistent with their level, the ‘how’ is much less important – this ultimately gives engineers and their managers the leeway to keep a team collectively engaged and excited about what they’re working on.

3. Designing a ladder for outcomes over skills gives you some flexibility in writing the ladder.

Instead of having to be super dialed or prescriptive about an exact set of skills, you can ship and iterate on a lighter, more outcome-driven ladder first that can grow with your team and product as they mature. In fact, I’d argue that you don’t know what skills you want to highlight right now – your team and culture are still growing, and you don’t want to make the mistake of leaning too heavily on skills that may not scale with you. You can always change the ladder, but you can’t change the impact on culture and hiring that they’ve had in the meantime.

Don’t try to get creative

Good management is boring. Of all the things that managers do, creating systems and frameworks might be THE most boring. This isn’t a bad thing – people are going to people, and consistently surprise you in both good and bad ways. Your job in creating a framework is to provide enough wiggle room for interpretation to maximize the former, and enough structure to minimize the latter. 

The good news is that engineering career ladders are almost approaching an industry standard, with more and more companies adopting the L3-8+ levels popularized by Google and Meta (give or take some seasoning to taste). Levels.fyi is, of course, a good resource for benchmarking your comp bands, but also for exploring where various companies set their levels – you can infer the width of a level by how wide the comp band is. Numerous companies, as mentioned, have effectively open-sourced their levels and the methodology behind them: – Square, Carta, Gitlab, and many, many others are available for you to peruse, be inspired by, or steal borrow from.

Whatever you do, don’t start with a blank slate. Take the impact-first approach Stytch chose – this isn’t even unique to Stytch! While we arrived at this conclusion independently, this is exactly the same premise companies like Carta and Honeycomb have based their ladders on. Not convinced yet? There’s two more big advantages:

1. When you hire someone, they already roughly understand your levels. This is a huge win for both managers, who you can immediately speak a common language with, and engineers, who immediately understand what’s expected of them. Uber recently re-leveled Senior II and up to better align with the broader industry for this exact reason.
2. If something breaks down, you have resources. There’s a goldmine of blog posts (not to mention industry gossip on Quora and Blind) talking about career ladders, and the problems and solutions people have encountered as theirs have evolved. The more you go off the beaten track and forge your own destiny, the less help you have to fix it. – that vintage 1978 Porsche you’re eyeing sure looks cool, but when it breaks down, you’re going to be wishing it was a Honda instead.

The big irreversible decisions

Most of you are probably familiar with some decision-making framework highlighting the importance of paying attention to irreversible decisions. In developing a career ladder, there’s really only two in my mind – promotions and level visibility.

Promotions

Really, your decision here comes down to whether you promote as a lagging indicator (e.g. you’re already doing the job) or as a leading indicator (e.g. your manager is reasonably confident that you can do the job).

In my mind, the only choice is to promote as a lagging indicator – this is almost an industry standard at this point. If you promote as a leading indicator, engineers might be happy at first (they get the promotion earlier!) but might change their minds when they realize that their expectations have increased significantly in the next performance review cycle, and find themselves scrambling to even scrape by with an average review. Don’t make this mistake.

Level visibility

This is another deceptively simple binary decision is whether or not your levels are public internally, or not. The big advantage to public levels is that folks understand concretely what the next level looks like by just looking at an engineer at that level. I’m sure you can think of all the disadvantages, though – comparing yourself to others at your level and above, being intimidated by ‘higher ranking’ engineers, getting upset when a peer is promoted and you aren’t…the list goes on.

At Stytch, we decided to make levels private, which is consistent with the majority of companies in the industry with levels. This was actually not a popular decision among engineers on the team, but I’m still a firm believer it was the right one. I’m not convinced just yet that we’ll want to keep levels this way permanently, but we do have the option to make levels public at a future point – the inverse isn’t true, which makes this a logical starting point in my mind.

It’ll all be OK

So if you do all the things I mentioned above, can you roll out levels completely problem-free? Absolutely not. Maybe an engineer won’t get the level they wanted, or will be disappointed you’re rolling out levels because it’s a sign of Big Company things to come. Maybe an EM will struggle with a skill ladder they feel doesn’t fit their team because it’s too backend or product-heavy.

This is all normal! Remember, it’s a human system written by humans. As long as you’re willing to put in the work to invest in your system, and provide the context needed to interface with it, you’ll get through the initial pain points and have a system in place that should pay immediate dividends the next time you go through a review cycle or sit down to build a career development plan with someone. Remember, you’re going to have to pay these costs at some point, and the longer you wait, the higher the price.

Just do it – you’ll be happy you did!

About me

Hi, I’m Judd – I lead Engineering at Stytch. I’ve been programming computers since I was in the 3rd grade, and working in the industry for 15 years – somewhere along the way my love of systems and people combined, and I’ve morphed into one of those weirdos that is actually passionate about (shudder) management. I’m a big believer in the power of people, and building frameworks that let excellent engineers be excellent. When I’m not working I have an assortment of unreasonably expensive and time consuming hobbies – including (but not limited to) cycling, hifi and collecting records, cooking, art, interior design, wine, and probably more I’m not thinking of. I live in SF with my wife Dayna and my sheepadoodle Maisie.