Mentoring and coaching engineers is a part of my role that I enjoy a lot. A topic that comes up often in conversations with mentees is career growth and promotions. Promotions are important for a number of reasons including increased compensation, expanded scope, accessing more challenging problems and perhaps even the validation that one is growing and performing better and better over time.
Being excellent in your current role is not always enough: The important question is knowing if you are ready for the next level and if not, what skills you should be working on to get to the next level. This is often confusing because transitioning between these levels is often a transition between roles. This means that in spite of getting high ratings at your current level, you may not be performing the job functions of the next level. While this post focuses on the major functional role requirements, it does not talk about a number of other essential aspects such as clear communication, community contributions, working well with others and so on. These are critical aspects as well and I have come across cases of unsuccessful promotions because their profile was not well rounded.
Mapping levels across companies: Software engineering levels do not map one to one across companies. I use as a reference in this post the levels used at Google (which is the one I am most familiar with). But I expect that these expectations map across companies within +/-1 level. levels.fyi maps SWE levels across different companies. Many early stage companies start with no levels at all, and only adopt a ladder much later on. For example Netflix is only adopting a software engineer ladder in 2022 - a full 25 years after starting operations.
Entry level software engineer: L3 is the level at which a new graduate typically joins at Google. In Amazon this is L4, and at Microsoft this starts at 69. At this level, an engineer is still learning the trade. The engineer would need lots of mentoring time and support from senior engineers in the team. An engineer at this level should expect to be assigned well defined tasks (for e.g., “Implement a module that generates corresponding RPC calls to the storage layer for each incoming write”), and should be able to execute these tasks with support from others.
An L3 engineer should be evaluating the L4 role once the engineer is able to execute the assigned tasks with little to no external support. The engineer should also be starting to write design docs with support from senior members of the team.
Junior software engineer: L4 at Google is a natural progression for engineer. It is important to note that some companies have a growth expectation for entry level engineers to grow in their career. Google used to expect that all engineers be able to grow into L5, but this changed a few years back to be L4. At this level, Engineers work on reasonably well-defined projects (for e.g., “Implement a high throughput module that accepts user writes and reads”) and break it up independently executable tasks. Specifically the engineer would be responsible for designing the solution with limited help, and delegating the tasks to L3 engineers in the team.
As the L4 engineer matures in the role, their independence should continue to improve (especially on system design skills) and require very limited support. A good sign of maturity is when the engineer is able to identify new projects without external support.
Senior software engineer: While the next level is Senior Software Engineer, this level figures as a mid-level role in the context of the software engineering ladder and often is also the band with the majority of the engineers in the company. At this level, the engineer transitions from projects to problems (for e.g., “The high latency of the system is causing customer dissatisfaction”) and is responsible for developing a roadmap of projects that can solve the problem. While leadership skills are important at each level, it is especially critical from this level. Leadership is often construed as managing other people - this could not be further than the truth. Leadership is the ability of the engineer to influence others - this could be influencing the work of their peers, or influencing their manager about the priority of different work items, or possibly influencing dependent teams to produce a feature that the engineer needs. The other major difference at this level is the need to internalize business requirements. At this level, an engineer might also have the title of a “tech lead”.
Once the engineer starts exhibiting “influencing without authority” and is able to consistently scale their impact through others, it a strong indication that they are getting ready for the next level.
Engineers make a choice at this level of their career if they want to continue down the independent contributor (IC) ladder, or want to start managing a team. This post focuses about the IC ladder, but this point in an engineer’s career is an ideal time to make the switch over. If you are thinking about become a manager, a book I highly recommend is the Manager’s Path.
Staff software engineer: The transition from L3 to L5 is a progression of handling increasing ambiguity and independent execution. However a “Staff Software Engineer” represents a different job profile. This is a highly selective role and most organizations will have fewer than 5% of their engineers in Staff+ roles. In this role, the engineer often owns an area and is responsible for identifying the problems worth solving in the area (for e.g., “capacity planning or monitoring or scalability”). This role is an extension of the execs in the org and they will often lean on the engineer for decision making. Leadership skills is the center focus of this role, and a staff engineer will need to influence across teams and product areas. Each subsequent level represents a fundamentally different role, but the expectations become more and more murky as it depends on the needs of the organization. A couple of books on the topic that I would highly recommend reading - “Staff Engineer” by Will Larson and The Staff Engineer’s path by Tanya Reilly. Even if you don’t read the books, I would highly recommend reading this excerpt about the Staff Engineer archetypes.
Senior staff software engineer: This level is an extension of the Staff engineer where the engineer is able to either scale their impact through expansive breath and scope or is able to execute multiple staff engineer leveled projects in parallel. At this level, the expectation of influence is cross company and the engineer would be the de factor expert on a business critical area. The engineer is also expected to work with leadership to define the areas that need investment and provide a roadmap for executing the initiatives.
(Sr) Principal engineer, Distinguished engineer and Technical Fellow: These levels are equivalent to executive positions. The engineers represent the creme de la creme of the engineering community. At these levels, the engineers play roles that are critical to changing the direction of the company. They develop product strategy, and partner widely across different roles (UX, PM, etc) to ensure long term business success.