Engineering Levels

Engineering levels are weird. They vary from company to company and often there’s little mechanism for organisations to verify or “enforce” them.

Titles are important, you can’t ignore them altogether, but given their variance across and within companies - and the inevitable competing interests involved in successfully being awarded them - you’re often better off setting your own skill and career goals irrespective of your current organisation’s decision whether or not to pin a badge on you.

I’ve worked in companies with people titled Junior Engineer with 20+ years’ experience… and the title was accurate. I’ve worked in companies with people titled Senior Engineer with less than 2 years’ experience and only 1 job on their resume… and the title was ridiculously inaccurate.

In my own journey, and in my coaching, I’ve met many people who were underappreciated and deserving of promotion. I’ve also met many who, like me, were promoted too early and suffered for it. I think both situations are problematic, obviously, but honestly I think the latter situation - being promoted too early - can cause more damage in the long run if it is not corrected carefully and thoughtfully by a good manager or coach.

Through my own coaching work I’ve identified roughly four levels that define my internal model for leveling of engineers. They relate primarily to the practical outcomes for me, as an engineering manager, in terms of who I can assign to what projects and how much of my time they will need¹ to achieve success in those projects.

These levels, I call in my head:

Junior
Mid
Senior
Beyond

These levels are just a rough guide, and there are many things to consider when evaluating engineers. I have just found these levels incredibly useful in my work, and in coaching engineers toward higher levels, so I thought I’d share.

Each level is usually defined by a “dominant force” that often predicts how the engineer will spend their time. The goal at each level is relatively clear. Despite this, achieving that goal still takes a lot of time, practice, and often good coaching.

Junior

Dominant force: learning
Primary goal: independence

The junior engineer is still getting their bearings. They are learning tools, they are developing their process. They require a certain amount of hand holding, and may need help not just in solving problems, but also in the basic mechanics of the job - shipping code safely, writing tests, etc.

Junior engineers may have learned how to code, but have normally not been exposed to the realities of software engineering in a business setting. So typically they need to be taught operations: release processes, testing, observability, monitoring, and so on.

Typically there are many other things that need to be learned too like communication, stakeholder management, time management, prioritisation - I like to leave these to the side during the junior phase, I think it’s more important to get the “hard skills” down first.

Quite often they will also need to work on their problem solving techniques, like how to quickly and accurately find the point of failure in a system, how to use logging to debug production systems, and so on.

Typically, it is not expected that a junior engineer should complete anything other than small, well-defined tasks on their own - no ambiguity and nothing that will take more than a week or two. They likely need their work broken down for them into tasks with clear goals and boundaries.

This stage usually lasts about a year, depending on the person, their place of work, and how they’ve been coached or managed. However, that’s not to say it can’t last much longer - I mentioned earlier a rather extreme case, but I’ve seen half a dozen engineers in the 3-6 year range still struggling with the basics. It’s almost never their own fault, it’s usually because they’ve just been left to their own devices without appropriate coaching, management and feedback - as soon as that is given these people often thrive very quickly.

In practice, I’d say if an engineer isn’t coming out of this phase after 2 years, there’s probably something wrong - they’re not being coached effectively, or they’re not listening.

The goal of a junior is to find independence. When a junior is making work disappear from the backlog largely without requiring input, that’s usually a good sign they’re ready to move up.

I don’t think there’s too much concern at this stage about promoting a little early, so depending on your organisational cadence it can be a good one to offer maybe just a few months (no more than 6) before you’d be absolutely certain they’ve cleared Junior. It can be a really good motivator given at the right time under the right circumstances if you’re confident the engineer is working hard and headed in the right direction.

Mid

Dominant force: competence
Primary goal: temperance

The mid level engineer has attained competence, and is now able to work independently. It is exactly this competence that defines the growth challenge of the mid level engineer, which is why their goal is often temperance.

Mid level engineers should be able to work independently, even on smaller projects (up to a few months). They still aren’t ready to tolerate much ambiguity, though, so may still be required to help break down work. Coaches and managers will want to ensure that less and less of this happens over time, though, to ensure their growth.

Mid level engineers can cause themselves (and others) problems usually in two main ways:

A hyperfocus on “good” code (can show up as an inability to finish work)
Overworking to the point of exhaustion (and preventing their own growth)

This, often, is a product of their personality - confident people will usually be type 1, where self-doubting folks will usually be type 2. They are not mutually exclusive and not exhaustive, either, they’re just common patterns I’ve seen.

Type 1 - Confident

Those engineers in the first category usually end up there due to a great deal of intrinsic confidence. This is a big danger zone for early promotions - a very competent, confident mid level engineer who’s turning out good code can seem very much like a good candidate for promotion to senior level. But we have to be certain they have the ability to temper themselves before going further, or they will often only wreak havoc with greater titular authority and less oversight.

Mid level engineers often need to be taught how to connect their skillset to value. Often a good way to do this is put them in direct contact with their user. The scope still needs to be kept fairly small - ownership over one or two non-critical systems is usually my go-to, and I give them complete autonomy within that scope.

If it’s possible make them talk to the user. Make them understand the problem, break it down, solve it, and keep it running. Let them crash it, and let them explain their mistake, and let them feel the disappointment or frustration of their user.

Let them build something they’re going to regret in 6 months’ time - if possible. Without a visceral, direct connection to the consequences of their work, many mid level engineers will struggle to develop the instincts they need to temper themselves so they can apply their skills effectively in the service of value - rather than just building things because they can, or “fixing” things that aren’t broken.

This engineer is only going to learn through failure - so give them a safe space to do that for as long as they need to learn.

You might find that suddenly given the weight of responsibility the immense confidence wanes - funny how accountablity can do that! It’s important you keep on top of them and make sure they’re actually completing and delivering solid value within the scope of this ownership you’ve given them. The pressure of ownership often leads to behaviours like “continuous refactoring” and nothing actually practically gets delivered; and no value created for a user.

Type 2 - Self Doubt

Mid level engineers who are very competent but are lacking in confidence can be very hard to coach. Confidence issues can be tied up in very tricky aspects of a person’s psychology, and so their coach or manager may not be the right person to help them move past this, but there’s still work that can be done here.

The way the dominant force of competence shows up in these engineers is overwork - they know how to do their jobs well, but they’re worried they’re not smart or good enough to do the really “hard” stuff that more senior engineers do. Often, they will compensate for this by doing lots of work. They’ll take all the small stuff and grind out work in order to feel they are making an impact within the team. This behaviour all but ensures they will never reach the next level because their time is capped and they’re too exhausted to learn and grow.

This problem needs to be approached carefully - really this engineer might need to be forced into doing harder work; something they can’t solve just by throwing hours at it. The trick is, they may still try, and burn themselves out with frustration trying to grind against a problem that’s asking for a different approach from them.

The key to helping them build their confidence is by selecting projects that challenge them, just a bit - not enough to trigger huge overtime, but enough that they actually have to flex their (usually perfectly capable) skills. Perhaps they have to sit down and design something from scratch, or crack a unique problem, or break down and plan a large project. Obviously it will need to be tailored based on what they want to achieve in their careers, and what work is available, but this is the key.

Demand a solution from them, refuse to do any of it for them, and encourage them consistently with a (well-founded) belief that they can do it. Recall examples of problems they’ve solved, or projects they’ve participated in, as proof they are worthy of that belief.

After one or two projects are put away successfully by themselves, they now have undeniable evidence that they are perfectly capable of achieving that next level - they don’t have to just grind away at simple bugs and tasks just to earn their keep. They can take a smarter approach and they can contribute at a higher level - they just did it. Twice! In a row!

Overall the goal of the mid level engineer is to temper their newfound competence: either way their confidence goes, they’re probably writing too much code.

Senior

Dominant force: experience
Primary goal: breadth or depth

Once an engineer has mastered their skillset and has the discipline to both properly apply that skillset in service of their user I think they are ready to be called senior. They’ve long since mastered the how, and now have also mastered the why. They take risk seriously, they know how to mitigate and prevent it, and they know what works and what doesn’t, and their first instinct is rarely to “rewrite all this legacy code”. They can be trusted to take on large projects (6+ months), break the work down, properly define and test it, and they will likely be capable of delegating this work, too, if there are other engineers on the team working with them.

There still needs to be an eye kept on the work they are scoping. Even at this level, especially if the engineers don’t have great “visibility” of the users or the organisational context, senior engineers can be prone to overengineering - usually in service of mitigating perceived (sometimes imagined) risk. Engineers, because we are human, have a tendency toward solving our own problems instead of those of users, and even very senior engineers are still prone to this (we’re all just people!).

The senior’s experience defines their work here. And by that, I mean, their specific experience. For example, if they’ve worked in a lot of startups, they might be lacking long-term planning skills because they’ve always been on a runway. If they’ve worked in a lot of large corporations - or in the public sector, say - places that are typically more risk-averse they may struggle in a high growth company that prioritises action over stability. If they’ve come from a small or medium business, they may struggle with the politics, impersonality and bureaucracy of a larger organisation, and so on.

The coaching here becomes extremely tailored and diverse, and it’s much harder to generalise at this level - but there are still some common archetypes that present here. I might discuss these in a future article.

The biggest risk with senior engineers is that they are actually still mid level engineers who’ve been promoted too early. This can manifest in a number of ways, so identifying it is important, as there may be some groundwork to do in reframing their understanding. Perhaps they still think there’s a “right way” to do things. Perhaps they still treat “management” or “business” as “other”. Perhaps they still think their job is the hardest one in the company (often shows up as a feeling of intellectual superiority over designers, in particular - especially if they’re unusually annoyed by design changes). Whatever poor ideas they may still cling to, they may need help to work these out before they can grow beyond this point.

These misconceptions are quite common, but don’t apply to all engineers, of course! Others may not have any such misconceptions, and may breeze through with a healthy, balanced view of things already. That’s the dream scenario!

Depending on the engineer’s experience, and their career aspirations, they need to either:

Broaden their experience
Deepen their experience

If the engineer knows exactly where they want to go deep, then let them as much as possible. Encourage that. This is how we get specialists and discover new expertise.

If they don’t know which one to choose, or confidently don’t care to specialise, then go with breadth - everyone will benefit from it and it may lead to an area they wish to dive deep into, anyway.

Breadth can mean a lot of things, by its nature, and again, depending on experience, they will either need to go broad technically (if their experience has been more one-note) or broad non-technically (if their technical expertise is already broad).

If they don’t know which to choose, go with non-technical breadth - again, everyone will benefit from this. Learn more about design, product management, business operations, legal, accounting, literally anything other than software. Learn how software is applied by users, how it’s marketed or sold, learn how to do user research or data analysis. All of this will help broaden their perspective and improve their ability to apply their masterful skillset to create value.

Beyond Senior

Dominant force: creating value
Primary goal: creating value

This is where we have specialists, thought leaders, great managers and coaches, architects, CTOs, entrepreneurs, you name it. This is where people go once they surpass the senior. They’ve mastered the how and why and now they have their own why.

The force and the goal converge here on one thing - creating value for other human beings. This is why I don’t think it’s useful to delineate levels at this point, it’s more about the specific role people are working in and what they’re trying to achieve, than the somewhat more “linear” growth from junior to senior engineer.

At this point these people should be all but managing themselves. The most they should need is a sounding board, as long as the organisation is regularly communicating appropriate context and strategy with them, of course.

The End

Anyway, that’s how I think of engineering levels. There is a somewhat linear journey for most engineers up to the “senior” badge, at which point full autonomy is generally expected. They should not be expected to manage a software organisation, or build and maintain a team, necessarily - but they should be expected to build and maintain one or more large products or systems without oversight (together with a team, usually, of course).

Many engineers get stuck for some time at the mid level, I think that’s the trickiest transition to navigate - especially without a good coach or manager.

Going beyond senior is also difficult, in its own right, but generally I think people who’ve achieved the maturity required of a solid senior can go beyond if they really want to - it just takes time and effort. The biggest barrier I see at this point is fear - but that’s a topic for another day.

Of course, I will give everyone as much time as I can. Perhaps it’s obvious, but I have my own work and other people to consider, so I have to be careful who and how I assign things. ↩