I’ve been having a bunch of conversations with my team about our career ladder, and what it means to be “senior” in a software engineering context. It’s a little different in every company, but here is my view.

For a long time, I felt the gold standard for a career ladder was RentTheRunway’s, shared by Camille Fournier. Combined with something like levels.fyi, we can get a scope of what the “median average” software engineer looks like at each level.

I’m going to take a bit of an unconventional path and talk very little about technology. In an industrial programming environment, we should be hiring folks who can program.

However you check for that in your interview loop is your choice - I’m a fan of the work sample test. This, combined with a strong rubric, helps with levelling.

For the purposes of this article, I’m going to use Levels.fyi’s “standard” mapping for levelling to provide an easy comparison. I’m also going to be primarily talking about scope and impact.

I’ve worked at companies from ~20 employees through to ~80K employees, and at the time of writing I manage a team that covers everything from L1 through the top of L4.

We’re going to start at L1 and work our way up - the context of previous levels helps frame what “senior” means.

L1 - The Early Career Engineer

Scope

Congratulations on what is likely their first job as a software engineer! Their scope of responsibility is near zero - they are here to learn. That said, this is a real “sink or swim” test - I generally don’t expect folks to stay at L1 longer than one performance review.

At this stage, an L1 is expected to spend the majority of their time pairing with more senior engineers and making supervised changes to production code. I generally push with a “one week to meaningful PR” standard, even if “meaningful” here is a small bug fix or feature improvement.

The bulk of the time should be learning how software engineering works beyond the classroom and being a sponge. This is a great time to take advantage of any education bursaries / cert funding that the company may offer.

Impact

Minimal impact expected - the goal is going from being a net-negative addition to the team to break-even as fast as possible.

L2 - The Core

Scope

L2s are the core of any software engineering team. As per the “pyramid distribution”, this should be your widest step - L1s don’t really count as they should quickly graduate into becoming an L2.

An L2 should be considered a wholly independent engineer, able to take well-scoped, small items off the kanban/sprint backlog and deliver to the definition of done without much more supervision than code review. They should be encouraged to share responsibility of delivery of larger, more complex items with another L2 or a more senior engineer. They are generally not held accountable of delivery of larger OKR items, but may be held accountable of delivery of parts of those items.

Learning continues here, but primarily self-driven or through pairing with more senior engineers are on more complex problems. I expect L2s to start engaging in writing culture, and should generally be reading a lot of code and asking questions about why things are done a particular way.

Impact

As mentioned earlier, an L2 is generally about delivering small, well-scoped chunks of larger projects delivered by the immediate team. At this stage, I would expect them to start participating within a team’s/org’s culture of writing, if even only as a reviewer rather than instigator.

L3 - The Senior Engineer

Scope

L3s are your go-to executors, leading small groups of L2s to tackle larger, more complex projects - the ones that typically appear as key results in your OKRs (assuming you are a line manager/tech lead).

On top of the skills of L2, this is where I’d expect to start to see some level of specialisation - deep knowledge of a specific domain, and understanding how to apply that knowledge for the greatest effect. I also expect L3s to evolve beyond being an order-taker and start to generate work for themselves - improving the codebase, practices and so on. Similarly, I expect them to engage in writing culture, gathering consensus where decisions need to be made that impact the immediate team.

On top of that, I expect L3s to own delivery of small-medium projects from design through to delivery, with help from L4s and up. They should also ensure they are assisting in the growth of L2s into more L3s.

Impact

L3s are “get-it-done” folks - they are given a task and drive it to completion in a high quality way. Their contributions should always be beyond the immediate scope of the task they took on - becoming somewhat of a “1.1x” engineer.

Beyond that, this is where working only within the scope of the immediate team becomes a career limiting factor. To progress beyond that, scope and impact needs to exceed that of the immediate team boundaries.

Generally, I would expect an L3 and above to “go a little further” on everything - kind of like practising “5 Why’s” for each thing. This is especially true for things like requirements.

I would consider this a terminal level for some engineers.

L4 - The Staff Engineer

Scope

L4 gets in the murky world of “staff” engineering. At this level, scope expands beyond the immediate team and there is an expectation to own delivery of larger, complex projects that cut across many teams within a business function. L4s are likely wearing different hats different days of the week, and should generally be part of planning and longer term initiatives. “Planting trees they will not sit in” is a good mantra for the scope of work an L4 will be doing.

This is where it gets much harder to define what the appropriate scope is. In my experience, an L4 is generally owning design-through-delivery of projects that appear at the Senior Director/Vice President level. They are also where the buck typically stops for technical decision making within their team. For many, the scope is self-defining.

Impact

L4s should have outsized impact with most things they do - their job is making the whole team more effective and are essentially a right hand to the leaders of the team, if not a business unit leader. I would expect frequent contributions to writing culture, and ensuring that there is a focus on outcomes rather than output.

This is a terminal level for the majority of engineers.

L5+ - Architects, Principals, Etc

Beyond the L4, it gets harder to define the role according to of scope and impact so narrowly. Generally speaking, an L5 owns technical direction for a whole business unit or many business units, and are typically technical “faces” of an organisation at conferences and other industry events.

How an org defines this level is very org dependent, and so becomes hard to generalise. Ask your friendly neighbourhood architect what they see the role as - you’ll probably get different answers from different architects, even under the same org.

As this level rarely leaves time for day-to-day coding, many L4s are happy not stepping into it. There is also a level of politics at play at this level that is normally only exposed to the management track, which some engineers might also find unpalatable.

Wrap Up

So what is a senior engineer, anyway? It’s about scope and impact. Once an engineer takes on a wider scope of responsibility and is driving outcomes that are larger than they are, its safe to call them senior.

And how should we manage them? Generally by getting out of their way, by laying down track for them to follow to the next level, providing opportunities to own bigger things, and the support necessary to make them successful.