Careers Pt 1 - Levels

I’ve been doing this for a while. And like the Farmers Insurance guys says, I know a thing or two because I’ve seen a thing or two. I’ve written a little about it before, but I figured it’s time to add a little more detail to how I think about things and what I’ve learned. About what levels are and aren’t, and what they’re a proxy for (hint: it’s influence, not ability).

Some background. First, this is based on what I’ve seen and experienced at small startups (you’ve never heard of them), game dev companies (Microprose), mature, large tech companies (Microsoft, Amazon), and hypergrowth startups (Uber), and mid-sized startups (Aurora) as well as discussions I’ve had with folks at other tech companies, large and small.

Second, your mileage may vary. While many companies have standardized processes, your experience is very much dependent on your direct manager and the managers 2-3 levels up. At larger companies the experiences in one area can be very different from the experiences in another part of the company.

Third, the environment now is different than it was when I started. Pandemics. Work from home. The great resignation/reshuffling. Today’s cell phones have more compute/graphics power than any single computer (or cluster) you could buy.

With all that said though, at the core, things haven’t changed that much. Your job, and what makes a difference, is the business value you provide. The business problems you solve. Not the code itself. Which means the way to look at it hasn’t changed much either.

Let’s start with some basic facts about levels

• They’re just numbers. Typically about 8 of them. They might start at 1, they might start at 59. But the important part is that they’re just numbers.
• They do
  • Set expectations
  • Usually based on some written rubric, but it might be implied (especially at smaller companies)
  • How others see you. Coworkers expect more from a senior engineer than from a new hire
  • Often defines your title.
  • Often inform compensation. Typically there’s a compensation band for each level and there is overlap
• They don’t
  • Define what you do. People at a given level can work on lots of different things.
  • Define your role. At a given level you could be a software engineer, a hardware engineer, a PM, or a manager
  • Define how you do things. Different people do things in different ways. As your level and role changes, the way you do things changes. What and how much design, implementation, coordination, problem solving, and problem identification you do are not defined by your level.
• They are (generally) given in recognition, not aspirationally. You get the level after you’ve been consistently demonstrating that you are working at that level. Not as a reward for working hard or to help you reach the level.

You’ll notice that since level doesn’t define what you do or how you do it there are people with wildly varying roles at the same level. Which means there needs to be a way to compare people at a given level. To keep things simple I’ll focus on individual contributors (IC) and managers in software engineering, but the same idea applies when comparing PMs, designers, engineers, etc.

In software engineering, breaking things down into really broad strokes, there are two major categories:

• Technical Impact
  • What things you know about
  • How much you know about them
  • Defining/Selecting Work Product
• People Impact
  • Building/Maintaining Relationships
  • Building/Growing People/Teams
  • Defining/Selecting Work Product

For your typical IC, plotting those two areas vs. Level will give you something like these two charts. What this shows is that as your level increases (career growth) the typical IC will continue to grow technically, but the people management side levels off. I’ve left off years of experience (YoE) and any units on the vertical scale on purpose. It takes as a long as it takes, regardless of YoE. This is a unitless Y axis because it’s relative, not absolute.

For your typical manager though it looks a little different. They start the same since lower levels managers are typically ICs and follow the same growth. After that they differ though, almost reversed. The technical breadth/depth stays the same, but the people side grows.

Once you’ve got those graphs it’s easy to compare them, right? Just overlay them and you know. Or not. What you end up with is a graph of diverging lines that doesn’t really help at all. Like this.

But when you think about it a little deeper, you realize that there is one thing that grows with level, regardless of your what you do or how you do it. That one thing is Scope Of Influence.

It’s Scope of Influence that grows with level and how you can compare the impact of people at a given level, regardless of role or title. As a new IC engineer, whether fresh out of school or self-taught, your scope is yourself. You mostly implement things. A little internal design, but how the thing you’re building interacts with other components of the system is defined for you. You don’t have a lot of impact on how other people do their work. As you grow and your level increases that changes. First it’s another person or two on your team working on a feature and how it will be used. Then it might be how the whole team works to solve a specific business problem. As you get to “senior” levels you’re influencing how things are done across multiple teams. At the “staff+ (IC)/Director (Mgr)” levels your influence is across organizations or business units or products, depending on how things are organized where you are. It doesn’t matter if you’re an IC or a manger.

Understanding how levels and scope of influence relate to each other is critical to deciding on your path and managing your career. But it’s just the framework for doing it. More on the deciding and doing are topics for future posts.