The 9 Software Engineer Levels: Which Ones You Actually Need to Hire

Almost every guide to software engineer levels and titles is written for the engineer trying to climb them. This one is written for the person doing the hiring.

That’s a different job. If you’re a founder, a Chief Technology Officer (CTO), or a VP of Engineering, you don’t need a map of how to get promoted to Staff Engineer. You need to know which rungs belong on your team at all, who to hire next, and what each level costs you when you get it wrong. And before you even get to levels, it helps to settle software developer vs software engineer, a distinction AI is quietly erasing.

I’ve climbed the whole thing myself. I started as a software engineer, became a CTO, and now I’m a CEO, and I’ve hired at every rung along the way. If you’re sorting out the very top of that ladder, CEO vs. CTO is its own comparison.

So let me start with the thing nobody selling you a leveling framework will say out loud.

You are not Google, and you don’t need Google’s ladder.

Big companies run nine or ten engineering levels because they employ tens of thousands of engineers and need that many gates to hand out promotions and raises. A team of six does not. Most growing companies need four or five real levels, not nine. Copying a big-tech ladder onto a small team is one of the most common and most expensive mistakes I see leaders make.

I’ll walk all of the levels so you have the whole map. Then I’ll tell you which ones you actually need.

The support rep who became a co-founder

Years ago at VinSolutions, the software company I co-founded for car dealerships, we hired a guy named Brian Kellogg onto our support team. He was one of the best people we ever had at digging into weird technical problems and figuring out what was actually broken.

He didn’t stay on support. He moved up to level-two support, then became a junior developer, then a senior developer. There’s a line in my book, Product Driven, that fits him perfectly: nothing makes you understand the real pain points of your software like being level-two support. Brian lived that, and it made him a sharper engineer than plenty of people who started with a computer science degree and never once talked to a customer.

Then he went and co-founded VinCue, an automotive software company. I was lucky enough to be one of his first investors. I think VinCue is going to end up being a bigger exit for him than VinSolutions was for me.

That story matters before we get into titles and rungs, because it shows what a level actually is.

Levels aren’t a chart. They’re a map of what someone can grow into when you give them the shot.

Brian climbed from answering support tickets to co-founding a company. The levels were real the whole way up. They just had nothing to do with how many years he’d been sitting in a chair.

Levels are about scope, not years

The biggest mistake in how companies define levels is tying them to years of experience. Junior is zero to two years, mid is two to four, senior is five-plus. It’s a tidy story, and it’s mostly wrong.

I’ve hired five-year engineers who still think like juniors, and two-year engineers who already think like seniors. The years are a rough shorthand and not much more. The real ladder is scope: how much of the problem a person can see and own without you holding their hand.

A junior can take a well-defined task and finish it. A senior can take a vague business problem, figure out what to build, and carry it end to end. That gap has very little to do with the calendar. I get into how each level actually thinks in our breakdown of the difference between junior, mid-level, and senior developers, which is worth reading when you’re sizing up a specific hire.

This matters more in 2026, not less. As AI takes over more of the mechanical coding, the thing you’re paying for at the higher levels is judgment: knowing what to build and why. That was always the real product.

One quick clarification before the ladder. People call this a software engineer hierarchy, an engineering career ladder, a set of software engineer job titles, or just software developer titles, but it all comes down to seniority. And seniority is different from the types of software engineers like frontend, backend, mobile, and DevOps, which are about specialization. A senior backend engineer and a senior mobile engineer are the same level doing different work.

The full software engineer ladder, level by level

Here’s the full hierarchy of software engineer titles, walked one level at a time. It’s the part every search result covers, so I’ll cover it too. But I’ll walk it through the one question you should be asking at every rung: do I need this level on my team, and what does it cost me if I get it wrong?

Modern ladders split into two tracks that branch off a shared Senior rung. One track keeps building software (the individual contributor, or IC, track). The other moves into leading people (the management track). Neither is higher than the other. They run in parallel, and a good Staff Engineer can out-earn a Director.

The individual contributor track

1. Junior / entry-level engineer. Roughly the first couple of years. They write code against well-defined tasks and need review and guidance. You hire juniors to grow them. They won’t rescue a team that’s already underwater. They’re an investment that pays off in two years if you have seniors to mentor them, and a liability if you don’t.

2. Software engineer (mid-level). Works on its own across moderate problems with less hand-holding. This is the workhorse rung where most of your shipping actually happens. For a lot of teams, a couple of solid mid-level engineers are better value than one expensive senior, as long as someone senior is setting direction.

3. Senior engineer. Owns complex work end to end, mentors the people below, and turns fuzzy requirements into a plan. levels.fyi calls this the “career level,” because it’s where most engineers spend the rest of their careers, and that’s the right way to think about it. This is the most important rung for most companies to get right. A real senior is the difference between a team that ships and a team that thrashes.

4. Staff engineer. Sits above senior, even though the name sounds smaller. Fewer than one in ten engineers reach it. A Staff Engineer leads technical work across several teams and sets direction instead of just executing it. Most companies under fifty engineers do not need this title yet, and handing it out early is how title inflation starts.

5. Principal engineer (and beyond). Sets technical strategy for a whole org and rarely writes day-to-day code. Above that sit Distinguished Engineer and Fellow, the rare top rungs at companies with thousands of engineers. If you have fewer than a hundred engineers and you’re writing a Principal job description, stop. You’re solving a problem you don’t have.

The management track

After Senior, some engineers move into leading people instead of code. The first step is often a Tech Lead, which is usually a hat someone wears rather than a true level. It helps to be clear on the difference between a tech lead and a team lead before you start handing out either title.

6. Engineering manager. Their job is the team itself. They run hiring, one-on-ones, performance, and the work of clearing roadblocks so the team can move. The moment you have more than five or six engineers and you’re the bottleneck on every decision, this is the role you’re missing.

7. Director of engineering. Manages managers, owns multiple teams, and translates company goals into engineering plans. This rung only makes sense once you have enough teams that one manager can’t hold them all.

8. VP of Engineering. Builds and runs the whole engineering org, sets hiring standards, and bridges the executive team and the engineers. In my book I tell the story of how, at VinSolutions, I was the visionary CTO but the company was missing a VP of Engineering, so I forced myself into that operations role and it drained me. Most small companies have that exact gap. If you want the full picture, we wrote about what a VP of Engineering actually does.

9. Chief Technology Officer (CTO). The executive who owns technology vision and the biggest technical bets. At a startup the CTO is usually the technical founder. The CTO role changes completely as the company grows, which is exactly why copying a big company’s structure rarely fits a small one. It also gets confused with the product side, which is why deciding between a CTO and a CPO trips up so many founders.

That’s your nine: five rungs on the IC side, with Distinguished and Fellow folded into Principal-and-beyond, and four on the management side from Engineering Manager up to CTO.

How the big companies do it, and why you shouldn’t copy them

The neat ladder above gets a lot longer at the giants. Here’s roughly how the standard rungs map to the big-tech systems, according to levels.fyi:

Standard rung	Google	Meta	Amazon
Entry-level	L3	E3	SDE I
Mid-level (Software Engineer)	L4	E4	SDE II
Senior	L5	E5	SDE III (Senior)
Staff	L6	E6	Principal (L7)
Senior Staff	L7	E7	n/a
Principal	L8	E8	Senior Principal (L8)
Distinguished / Fellow	L9 to L10	E9 to E10	Distinguished (L10)

The mappings don’t line up cleanly, and that’s part of the point. Google runs engineers from L3 all the way to L10. Meta reportedly has fewer than fifty engineers at E9 and above across the entire company. These ladders have seven to ten IC rungs plus a full management track because these companies need that many promotion gates for tens of thousands of engineers.

You don’t have that problem. You can’t afford a Google Principal Engineer, and you don’t need one. When most engineers will spend their careers at the Senior rung anyway, a small team that defines clear levels up through Senior, plus one or two technical or management rungs above it, has everything it needs. Our engineering competency matrix shows how to make those few levels concrete once you’ve picked them.

Which levels do you actually need to hire?

This is the question the title promised, and almost nobody writes about it. So here’s my answer.

Start with your seniors. The single most important hire for a small or growing team is a real senior engineer who can own problems without supervision. Get that wrong and nothing above or below it works. Real seniors are scarcer than the market makes them look, too. About one in three developers have four years of professional experience or less, according to the Stack Overflow Developer Survey, so the senior who can actually carry a problem end to end is the hard one to find.

Then resist two opposite temptations.

The first is stacking up juniors to save money. I’ll say this plainly: nothing will kill a startup faster than a team of entry-level developers. Juniors need seniors to mentor them and review their work. A team of all juniors doesn’t move fast and cheap, it ships fragile code with nobody to catch it. When cost is the only reason you’re hiring someone, you’ve fallen for what I call cheapshoring, and it ends the same way every time. I wrote a whole piece on cheapshoring and why the cheapest developer is almost always the most expensive one.

The second temptation is over-leveling. Hiring a Staff or Principal Engineer to do work a strong mid-level could handle is just as wasteful. You pay a premium for scope you don’t have and create a title structure your team can’t support. Title inflation feels generous in the moment and turns into a morale and budget problem later.

If I’m building a small team from scratch, I start with one or two real seniors who can own whole problems, add a couple of mid-level engineers to carry the volume of the work, and keep juniors to one or two that those seniors have time to actually mentor. I don’t add an engineering manager until I’m personally the bottleneck on every decision, and I don’t hire a Staff or Principal engineer until the team is big enough that someone has to set direction across multiple groups. For most companies under about thirty engineers, that’s the whole org: a few seniors, some mids, a junior or two, and one manager once you need one.

The real test for any hire isn’t years on a resume. It’s scope and judgment. In Product Driven I describe it as wanting chefs, not short-order cooks: people who own outcomes, not just tasks. A two-year engineer who thinks like an owner is worth more than a ten-year engineer who waits to be told what to do. (If you want the full breakdown of what each level costs and which level you should hire for a given role, that guide runs the numbers.)

For a rough cost anchor, the median software developer in the US made about $133,000 a year as of May 2024, according to the Bureau of Labor Statistics, and the field is projected to grow 15% through 2034. A real senior, once you add benefits and overhead, clears well past $200,000 all-in. Those numbers are why “which level do I need” stops being an HR question and becomes a budget question fast.

How levels work on a remote or offshore team

Levels don’t change when your team is distributed. A senior developer in Manila is a senior developer, full stop. The offshore cost difference is cost-of-living arbitrage. The skill and seniority are the same as anywhere else. Anyone who tells you offshore means a lower level is selling you the wrong thing.

What does change is the hard part of all this. Knowing which level you need is the easy half. Finding that person and keeping them is the half that breaks most teams. The best senior engineers already have jobs and won’t answer your job post, so they have to be recruited away. That’s the actual work.

It’s also what we do at Full Scale. We run staff augmentation, which means the developers we place join your team, your standups, and your Slack, and they’re accountable to you. We have full-time recruiters whose whole job is pulling passive senior talent away from their current employers, and we keep them: our developer retention runs at 93%. You decide what level you need. We go find it and make sure it sticks. If you’re scaling past the point where you can hire fast enough on your own, that’s the gap we fill, and we’ve written more about scaling an engineering team without scaling the chaos.

The bottom line

Software engineer levels aren’t a wall chart you copy from a bigger company. They’re a way to answer a real question: who do I need on this team, and what does each of them own?

Define the few levels you actually need. Hire for scope and judgment. Years on a resume tell you almost nothing. And remember that the levels are a real ladder a person can climb. Brian started on a support desk and ended up co-founding a company. Give people the right map and the room to grow, and some of them will climb further than you ever expected.