How to think about levels at companies

Welcome to my newsletter! I'm Dave Anderson, an ex-Amazon Tech Director and GM. I write this newsletter I've called Scarlet Ink, which is a weekly newsletter on tech industry careers and tactical leadership advice.

Free members can read some amount of each article, while paid members can read the full article. For some, part of the article is plenty! But if you'd like to read more, I'd love you to consider becoming a paid member. All of my articles are intended to be evergreen (readable and valid forever). Some weeks I have fresh content; other weeks I'll update/rewrite something from 4+ years ago because I want to keep the quality of all articles high.

I think my favorite part of Amazon was getting people promoted. Part of that is because it's essentially equivalent to me grabbing a bag of Amazon money, and handing it to an employee.

Of course that's fun. It was sort of crazy that some of my peers didn't have as much fun promoting people as I did.

"Hey Dave, it feels like you're rushing this promotion a little? I think they'd be ok waiting 6 more months."

"Well yeah, they'd probably be ok waiting 6 more months. But they'd be super happy to be promoted now, wouldn't they?! And if they're ready, why the heck wouldn't I push for it?"

One key aspect of getting people on the road to promotion was helping them understand what the next level looks like. Because there's an incredible difference between doing your job well at your current level and doing the next level job.

I don't know how many times engineers (and, unfortunately, sometimes managers) were confused about how an employee could repeatedly get the top rating, but not be promoted.

"If they got the top-tier rating, how are they not promoted?!"

And the answer is simple. Because a level 6 engineer (for example), is not simply a really good level 5 engineer. There are different expectations in the job.

One clear example. A level 6 manager can be handed a list of approved projects, and they need to work with their team to build a roadmap for the year to achieve those projects. A level 7 manager has to participate in the long debates about which projects to approve.

I've worked with excellent level 6 managers who had zero interest in those debates about which projects to approve. Year after year they'd be told they were excelling at the level 6 position, but it brought them no closer to the level 7 job.

So that being said, I felt like some of the most valuable discussions I had with my teams was explaining the key points that differentiated each level. So that's what we're going to do today.

Levels at various companies

Thank you to levels.fyi for creating this great levels comparison chart. It can help you get an idea of what I'm talking about.

In this article I'm going to refer to Amazon levels for simplicity's sake, and you can just compare that level to your company to understand what I'm talking about.

Level 4 - Entry level

This is the level you're hired if you join with only a 4-year college degree. And with some exceptions, you'd be hired at this level with a master's degree as well. One more reason that master's degrees are pointless and a waste of money. Not that I'm opinionated on this matter.

In the diagram above, the cute level 4 engineer with the blue head has 5 peer engineers, and a manager leading their team.

A level 4 employee is in a learning position. You won't be expected to contribute serious amounts of value to the company because you're incompetent and new to working. The company's goal is to make you become useful. Your job is to prove that you will become useful soon, and you have the potential to grow into a valuable employee.

The assumption is that you come with some basic skills. For an engineer, you're expected to be able to write and read code, figure out how to use source control, read documentation, etc. Your skills will grow, but some amount of, "I can figure this out" is necessary.

You'll be expected to listen closely to feedback. A level 4 employee that doesn't listen to feedback won't last long. Far too many times I've heard a level 4 employee argue with a senior engineer on their team about some code review feedback. "I disagree. That doesn't need better variable naming. No one will be confused."

That's like a puppy saying that it prefers to just keep peeing on the carpet; it doesn't want to go outside, thank you very much.

Level 4 employees generally work on tasks, not projects. In other words, they're not asked to go solve a problem on their own. Instead, they're asked to help someone else with their project.

Their scope as it relates to their task is mainly a portion of one system. If a team owned 3 systems (diagram above example), the level 4 employee would typically be heads down learning the portion of the single system their task interacts with (see the blue part of System B). Of course it would be in their best interest to learn as much as possible outside the scope of their task.

Another more senior employee will be working on something and will carve off a portion of their project for the level 4 employee to work on. In the diagram above, you'll see that little arrow going from one employee over to the blue head level 4 employee. That's to signal the peer delegation going on.

Of course, this is a generalized situation. If the "project" is something small, a level 4 employee might work on it on their own once they've gained some experience.

The timeframe a level 4 employee is focused on is often a few weeks (or a single sprint). They work on a task, and when it's done, they look around and say, "What's next?".

The primary difference as an employee moves towards level 5 is that they begin to build independence. When we're sitting there talking about if a level 4 employee is ready to be promoted, the primary criteria is, "Can we assign them something of medium difficulty, and they could go off and solve it on their own?"