Implementing software engineering levels (with fully-usable examples)

Introduction

As a consultant, I work at a lot of startups. Many of them find a need to implement engineering levels. Because I’ve done this many times before, it has become second nature. And, one of the companies I worked at gave me permission to share the levels I developed while there.

So today I’m sharing example engineering levels, and an outline of the process I go through to roll out engineering levels.

Why use these levels instead of any other levels?

These have been used at multiple companies and refined over time.

In my experience, most people copy engineering levels and then let them languish. These have received updates every year. And because I’ve done this at many companies, I have a lot of experience I’ve brought to bear on building them.

My recommendation is to review the design choices below and decide if you think it matches your needs.

There are a lot of examples of engineering levels you can steal from, such as the Rent the Runway engineering levels. Carta does a nice job of explaining the philosophy of their engineering levels.

Whichever you choose to base your engineering levels on, you can still use the process below to roll them out. Most companies customize their levels to match their individual needs.

What design choices did we make with these levels?

• I prefer systems that have job titles that map to what people think about rather than arbitrary numbers. So these levels use titles like “Software Engineer”, rather than “L2”.

• I like having about $US10K bumps in salary for every level. This leads to more frequent promotions, which makes the promotions less high-stake. I’ve seen some evidence from an analysis at a previous company that suggests that high-stakes promotions go more poorly for underrepresented minorities (but don’t have the reference handy, unfortunately). Having more frequent promotions can help eliminate that. I’ve also heard many horror stories from big tech companies with high-stakes promotions. These have shaped my thinking. I now believe you should optimize for more promotions, with smaller bumps. But you want the raise to feel meaningful, so there is a minimum amount.

• I have a lot of experience with and prefer fair pay systems — where your pay is more dependent on your impact than your ability to negotiate.

• These leveling systems can be used with both geographically adjusted compensation and without.

When should you introduce engineering levels

The conventional wisdom (which means a source I can’t remember) is that you should wait for product-market fit before introducing levels.

I think that’s generally pretty good advice. After product market fit, you’re hopefully doing more hiring and growing the organization. Having engineering levels helps you hire and retain your people better.

Introducing engineering levels can have downsides. It’s time-intensive, and it can shift the focus of every 1-1 towards getting promoted for a while. In the early days of a startup, you haven’t proven your company can survive, so it can seem premature to introduce levels before you’ve demonstrated product market fit.

How to roll out engineering levels

1. Choose the engineering levels you want to start from. I offer my preferred version below.
2. Make any customizations you think necessary to match your company. When doing so, consider what you want to incentivize.
3. Do a sanity-checking exercise. Go through a representative sample of your team, and rate where each person is with the criteria. I like to take the criteria, make a copy for each person, and highlight the criteria that apply to each person. Make a spreadsheet that compares where people are leveled today versus the new system, and think about how you feel about that.
4. Do a very rough estimate of salaries for each level. Do this by just looking at current salaries for people and where you’re leveling them. You want to get an idea of how large the bumps will be, and how many steps there are.
5. Work with HR to develop salary bands. You can read more about this in my post on implementing pay equity, even if you decide not to implement pay equity.
6. Make alterations until you feel like you’ve got a good system in place.
7. Then, you can start using it privately. Look for people that might be underleveled. You can also use the new levels with hiring. Keep improving the levels until you’re happy with them.
8. Think about your promotion rate. What type of budget will you have for promotions? With your leveling system, how often will that mean people will be promoted, on average? This is something you can usually work out with finance, but the sophistication of finance will vary greatly by company.
9. Publish the levels. This involves some deliberate change management. You’ll want to talk through the criteria and philosophy behind it. And take care with people who might be sensitive to anything you’re introducing.
10. Now use them!

A few suggestions

• I wouldn’t include titles you’re not using unless you think there will soon be a need for them. Many places won’t need Principal Engineer levels, for example.

• When customizing engineering levels, be sure to only choose things that vary depending on the level of experience. Sometimes people want to add items that are baseline expectations. For example, the values of the company. This is a mistake unless it is something that scales with the level of experience and impact the person has.

Note the thank yous

• The work below is the result of the work of a lot of people. See the thank you section below for the credits. The text portion especially owes a debt to the Carta blog post on their engineering levels.

---

Our titles

We have four engineering titles:

• Software Engineer
• Senior Engineer
• Staff Engineer
• Principal Engineer

There are no standard titles for levels used in our industry. Every company’s system is different. This makes comparisons between companies fraught. A senior level at one company is not the same as a senior level at another place. It’s worth understanding our levels and the way we assess them, as you think about your career.

It is difficult to prescribe the requirements for performing at a certain level. If the criteria are too broad, employees may not know what they need to do to advance. If the requirements are too specific, employees may become focused on checking boxes. We aim to incentivize a focus on areas that grow your skills.

The single most important thing for your leveling is your impact on the company. We can sum up the entire system by describing the impact we expect employees to have as they progress.

• Software Engineers have an impact on tasks and features. An example would be shipping features effectively.
• Senior Engineers have an impact on problems and teams. An example would be helping make a few teams work more effectively together, or making sure a set of features have a better impact on customers.
• Staff Engineers have a sustained impact on the whole engineering and product development organization. An example would be substantially impacting the roadmap for the company, or mapping out the technical plans that will guide a large part of the engineering effort for the next year.
• Principal engineers have a sustained company and industry level of impact.

When we talk about impact, we’re talking about making a difference in that area that we would reasonably mention to an outside observer. So having an impact at the company level means something you could mention at a board meeting. Having an impact on the engineering organization is something you would bring up in an executive meeting.

You’ll note that this is not a linear progression, especially at the top of the range; moving the trajectory of our field (on the broader industry) is exponentially harder than moving the trajectory of the product development organization. This is why our levels aren’t linear, and neither is compensation.

Fairness

Leveling decisions can sometimes seem unfair, and we aim to create a fair promotion process. One important thing to understand is that levels are conservative by default. Once we put someone in a level, there isn’t a practical way to “take it back”. It can cause an otherwise excellent employee to look like they are underperforming at their level, which in some cases can only be remedied by managing them out of the company. So when we promote someone, we try to be sure that it’s the right decision. It’s better for everyone to have you perform solidly at a Senior 3 level than to struggle at a Staff 1 level.

Because levels are conservative, you’ll often hear managers say that promotions are a lagging indicator of performance: You have to demonstrate that you’re performing at the next level, consistently, over a period of time. This can feel unfair. You might ask, “why am I delivering value at a Senior 1 level and only getting paid at a Software Engineer 3 level”. But remember that promoting you is a risk for the company, and since the company doesn’t want to make a mistake and lose you, they’re risk-averse. You might be certain that you have all the skills of a senior engineer, but the more obvious that is, the more likely the promotion is to occur.

However, there is also a risk in not promoting people that are performing at a high level. So the way we account for this during our review period is that we evaluate your performance over the entire review period and weigh the amount of time we’ve seen your performance at that level. So if the review period is for six months, and we’ve seen exceptional performance over the last two months, that only gets about a third of the weighting it would get if you had performed that way over the whole period. Similarly, if you’ve had a rough period, we’ll do the same weighting in your favor.

One of the more common mistakes engineers make is they evaluate themselves based on their skills. This is a part of the way you’re assessed, and the code you deliver is part of the value you create. But you’re judged much more by the sum of your impact on the organization and the business.

There will be times when the situation is unfair. You will have done good work, but some “bad luck” affects your project and it isn’t seen as successful. Or your part of the work is excellent but something else causes it to fail. The further up you go on the ladder, the less fair it may seem. The reason for this is that the more senior you are, the more impact you’re having on the organization. And the more you’re expected to fix the issues of how your work integrates with other people. That also means you’re likely doing work that is riskier, or more challenging. More experienced people tend to take this as part of the job, and know that their efforts will tend to be rewarded over time. We can only reward the impact you have, while trying to account for the amount of risk you’re taking, and the difficulty of the situation. This is one of the areas our managers have to take particular care while they evaluate people, because it can also be the most prone to bias.

Another important thing to understand is that the way people are leveled in the organization won’t always feel “pairwise fair.” Sometimes you may think that you’re performing better than someone else in the organization who is at a higher level. And sometimes you may be right. But it’s crucial to realize that making these kinds of comparisons won’t necessarily help convince your manager to put you up for promotion. First, your assessment of your coworker is likely to be incomplete: you have full knowledge of your work, but only a tiny window into that of your peers. But even if you’re right, someone else’s performance problem isn’t grounds for your promotion—imagine what would happen over time if we let the worst-performing employee in a level set the standard. Keep your focus on your accomplishments and the impact you’re driving for the company; don’t waste time and energy worrying about your coworkers.

Compensation and pay equity

We have three levels within each title: 1, 2, and 3. These correspond to three standard salary levels within each engineering title. The three levels have these meanings:

1. Establishing. You’re demonstrating behavior at this level, but it’s not completely uniform or consistent.
2. Solidly executing. You routinely demonstrate this behavior.
3. Mastered. Your behavior at this level sets the standard for that level.

We use structured compensation in engineering, which means salary is dependent on your level. We do this to make compensation fair, so you don’t have to guess if you’re getting paid fairly. Everyone at the same level should get paid the same amount.

There are some caveats here. We haven’t always had this system, so it will take some time for it to evolve to that point. When we promote people, we’ll move them to the standard pay for their level.

We also provide equity at a standard amount per level. We use a system called the implied value method, which ensures that employees not only get a standard amount, but that we correct for prior mistakes in equity grants. This is to ensure our employees get treated fairly so that people who are better negotiators don’t get paid more than people that have more impact. Note that people who join a company earlier will get more equity in the company. They incur more risk by joining a less mature company, so the equity is valued less, and they get more of it. As we get additional rounds of funding, we offer less equity to new employees, because it’s worth more and it’s lower risk. But we also strive to ensure that equity becomes a more regular part of your compensation.

To set compensation, we use [XXX] to benchmark our salary rates. And we target the XX% rate for the market. [also include something on whether you use geo-based compensation or not]

Promotions

The natural question most people have when looking at levels is, how do I prioritize my efforts to get promoted?

This leveling system is a way of measuring your impact on the organization. The more impact you have, and the more you improve things for the company, the more you should be promoted.

The purpose of this document is to serve as a proxy for impact. We spell out the types of impact we value, and help you reason about what to focus on to have more impact. It will never be a perfect reflection of impact, so we expect it to evolve. It’s a bad sign if these criteria do not change every year.

You should work with your manager to review these levels, and assess both how you think you are doing against the aspects of the levels, and how they view how you are doing. Discuss the differences in how you both perceive things, and come to an agreement on where you should spend your time building skills, both technical and with how you work with the people around you. Ideally, your manager’s reviews should reflect what you both agree will make you more valuable to the company, and if you improve in those dimensions you should see career growth.

It is a common trap to get into that your manager will identify something to work on. You’ll work on that, make progress, and then they’ll point out something else to work on to get promoted. This can feel like moving the goalposts. There _will _often be a couple of things to improve to get promoted. Your manager might not always recognize everything at the beginning. They also might realize additional areas when they try to get you promoted. But they should make a good effort to use the leveling system to identify where to focus your efforts. You should work together to create a shared understanding of the progress you’re working towards, and how you’re developing towards those goals.

Manager versus individual contributor

“Engineering manager” and “individual contributor” are parallel tracks. Management is never a promotion from being an engineer, it’s a lateral move.

Since you can’t manage engineers if you don’t deeply understand the work they do, we expect most people who make the transition to management to reach at least Senior Engineer. Many people who decide to become engineering managers stick with it once they’ve made the transition, but some managers eventually decide they’d be happier and more productive as ICs. Both of these transitions are perfectly okay. And some people go between the two types of roles.

If you do decide to transition between tracks, your compensation won’t go down, but your title will change, and you might have a “lower” level. This isn’t an insult: it’s a reflection of the fact that management and software engineering are different jobs that require different skills. Being good at one doesn’t automatically make you good at the other. In fact, it may feel like you’re starting over. If this happens to you, your manager will keep a close eye on your progress toward your next promotion. If your pay is higher than the standard for your level, you should expect smaller compensation increases when you are promoted.

Definitions

• Technical Impact: What qualities do we expect from the solutions you deliver?
• Business Alignment: How do you use your understanding of the company’s strategy to deliver better outcomes? How do you improve the outcomes your team provides to your team’s customers?
• Interacting with Others: To what extent do you coordinate with others effectively to deliver your work? Who is acting on the feedback you provide regularly as a part of your work?
• Autonomy & Ambiguity: What kinds of direction do you need to deliver your work? How do you contribute to project and roadmap planning? What degree of uncertainty are you expected to navigate regularly and successfully?
• Problem-Solving: How complex are the problems you solve? When something unexpected happens, how do you handle the situation?
• Process Improvement: What kinds of organizational processes do you improve, and how do you improve them?

Engineering levels

Title

Software Engineer

Senior Engineer

Staff Engineer

Principal Engineer

Impact

Tasks and features

Problems and team

Organization and Product development

Company and industry

Level

1: Establishing

2: Solidly Executing

3: Mastered

1: Establishing

2: Solidly Executing

3: Mastered

1: Establishing

2: Solidly Executing

3: Mastered

1: Establishing

2: Solidly Executing

3: Mastered

Technical Impact

Solutions solve immediate needs, but may need refinement to scale.

Solutions are efficient, maintainable, and pragmatic.

Solutions improve the speed of future work & preserve optionality without unnecessary complication.

Solutions are exemplary in terms of scalability and cost-effectiveness. Makes trade-offs between opportunity vs. complexity.

Business Alignment

Understands the objectives of the projects that their tasks support. Familiar with the value their team delivers to their internal or external customers.

Understands the objectives of the project and uses that to clarify and improve project plans. Identifies ways the team could provide better value for their customers, especially where value overlaps with their own work. Suggests and delivers improvements based on these observations.

Understands the corporate direction and uses it to improve the definition for teams’ projects. Identifies ways the team could provide better value for their customers across everything that their team owns. Suggests and delivers improvements based on these observations, even when this requires work on areas outside of their team’s area of ownership.

Clarifies strategic outcomes and influences roadmaps and projects. Identifies improvements in the entire end-to-end experience their customers go through, even for parts of the experience that other teams own. Suggests and drives improvements based on those observations (either directly or through others).

Interacting with Others

Work does not require them to coordinate with others (and their tasks) to deliver. Work does not require them to influence others. Advises peers on their team.

Work requires coordination with people on their team, including product and design. Influences improvements for their team and the projects they work on. Advises peers on their team, their direct manager.

Work requires coordination with people outside their team, including product and design leadership. Influences the roadmaps of other teams, especially to get work prioritized that’s required for their own team. Advises people across their VP-level org.

Work requires coordination across the entire company. Influences the entire org to make changes to support their work. Advises teams across the company, outside of their VP’s reporting chain.

Autonomy & Ambiguity

Implements non-ambiguous tasks with limited direction. Can break down their portion of a project. May need oversight to validate the approach.

Requires no direction on tasks. With limited direction, defines and breaks down ambiguous projects or projects with non-obvious solutions. Breakdown is incremental and cross-functional. Clarifies requirements. Contributes to task estimation. Capable of negotiating and working out solutions to ambiguity that are effective for the company. Simplifies.

Requires no direction on project plans. Requires limited direction on designing to support a long-term roadmap. Effective at considering how work breakdown will be effective across the team. Considers and plans around cross-team dependencies. Defines & breaks down challenging projects (e.g. projects that are hard to derive the benefits until the end of the project, projects that are very large, or projects that have a lot of uncertainty or require novel solutions).

Requires no direction on designing to support a long-term roadmap. Translates customer & business needs and strategic direction into projects. Consistently simplifies high complexity situations.

Problem-Solving

Solves straight-forward problems. Learning planning approaches. Plans their own work. Contributes to team decomposition and estimation. Escalates when projects hit roadblocks. Troubleshoots issues and addresses immediate causes.

Solves difficult problems. Removes bottlenecks. Can sometimes find a way forward without escalating, but still provides visibility into risks. Escalates in difficult situations. Is able to identify trade-offs and make recommendations. Identifies and addresses root causes.

Makes trade-offs between short-term and long-term solutions. Evaluates (and is accountable for) trade-offs others are making. Independently finds a way forward in difficult situations. Effective at recognizing/mitigating risk and removing roadblocks. Anticipates future risks and removes them before they become a problem.

Decomposes strategic direction into projects. Plans, communicates, and executes on the most challenging problems in the company. Anticipates most risks. Drives simplification to mitigate risks ahead of time. Helps the rest of the organization reason about risk.

Process Improvement

Works within defined team processes. Raises concerns when it breaks down or fails. Improves team documentation.

Identifies issues with their team’s processes, communicates the cause, and proposes improvements. Automates manual tasks to improve speed of delivery. Influences & implements best practices.

Owns projects to streamline team processes. Work often speeds or simplifies the work for people on other teams and is accepted as broader standards.

Proposes new organization-level processes to improve key areas such as team throughput, employee happiness, or product engagement. Drives best practices across the organization.

Want help?

I’ve done this many times before, and I’m available to help guide your organization through it.

Future improvements

• Jade likes the simplicity, visualization, and mental model proposed by Amy Chanta here.
• Honeycomb has some interesting elements of their engineering ladder Jade might want to steal from.

Terms of use

• You can modify this for your company’s purposes as you like.
• If you make big improvements to this document for your own purposes, please share them with Jade. He’d like to improve the original over time. This is a request, not a requirement.

Thank you

• The original version of this was developed by Shaun Yelle, Alexa Stefanko, and Jade Rubick at Gremlin. It has since been modified and improved as it’s been used at a couple of companies.
• I’d like to thank Gremlin, and in particular Matthew Fornaciari, for granting permission to share these levels outside of Gremlin.
• The inspiration for this format was developed at New Relic, after a couple of iterations. Jade Rubick did a lot of the work on those versions.
• Carta’s excellent post on their engineering levels had some really well done language. I adopted some of that language and have modified it for use here.
• Image by stokpic from Pixabay