Helping engineers perform and developing their careers is not easy. Startups tend to have very little structure to begin with, so managers and engineers often find themselves reinventing this wheel while pushing it uphill. But there’s a trick from established companies that can help: engineering levels.

Whether you are a first time tech exec tuning your engineering team, an engineering manager who wants to do right by their team, or an engineer who wants to grow professionally and look great doing it, read on. This one is for you.

A Brief Introduction

Engineering levels are one of the fundamental building blocks of finely tuned tech companies. You will find them in FAANGs, established companies and startups built or managed by experienced tech execs. I personally experienced them at Delivery Hero and Amazon, supported their launch at AutoScout24, and designed the framework from the ground up at multiple startups.

Engineering levels establish clear win criteria for engineers at different stages of their careers. This provides four key benefits:

• Performance management: managers can assess where contributors currently fall into their assessed level, set clear expectations ahead of time and help them close any gaps over a reasonable time frame (often a quarter).

• Career development: there is a clear path between a person’s current capabilities and the next step in their development journey. Managers and contributors can identify concrete development action items and track development progress over time.

• Fair compensation and promotions: having a well understood common measurement stick helps with providing fair, unbiased assessments to contributors of all backgrounds.

• Staff planning: knowing what you can expect from people at different career stages allows managers to reasonably plan their staffing needs based on capacity gaps and project needs.

These benefits are not limited to individual contributors (ICs). In fact, many tech companies have a levels structure (or “tracks”) for engineering management, product management, program management, and many other tracks.

Building an engineering levels framework and launching it is not trivial. The specifics on the engineering levels of these companies are not, usually, publicly available information. You can probably find a high level description of them, but anything more specific is hard to come by.

To solve this I created a foundational framework that you can adapt. You can use it to kickstart your engineering career program and evolve it as you gain more experience.

Note to individual contributors: keep reading as this will give you a deeper understanding of why your company might have a similar framework in place, how it works, and how you can use it to improve. If your company doesn’t have this system in place and you would like the benefits that this mechanism brings, send this post to your manager. We are usually pretty cool people.

Reference Engineering Levels Framework

Our reference framework is based on five distinct levels – Level 1 (L1) through Level 5 (L5). This model works well for organizations of a single team up to a few hundred engineers. After that point, you would need more levels (like Google’s Fellow), or finer grained levels (like “Senior Staff Engineer”).

We are going to focus on the Individual Contributor (IC) track. There is a distinct track for engineering managers, which I will cover separately.

The Five Levels

The five levels in this framework are:

• Associate Engineer (L1): the tech track’s entry point. Zero to minimal industry experience, but a mountain of willingness to learn.

• Engineer (L2): the foundation of most teams. Moderate amount of industry experience. Can do most jobs. Needs support for complex tasks.

• Senior Engineer (L3): the keystone of most teams. Lots of industry experience and a wide array of skillsets. Tends to be a subject matter expert in one or more areas. Enables teams to deliver on projects of any complexity by supporting L1s and L2s when needed.

• Staff Engineer (L4): fundamental to delivering on critical and/or cross team projects, often working closely with engineering managers, stakeholders and engineering teams. Excellent individual contributor skills. Leads by influence. Tends to be a subject matter expert in multiple areas, having served in many teams and solved many different problems. Coding starts to take a backseat to experimentation, coordination, planning and support. Helps create an engineering vision and strategy for the group.

• Principal Engineer (L5): critical to setting a medium and long term engineering strategy for the organization or division. Has a deep understanding of technical and business matters. Expected to interact often with directors and other executives, identify large scale problems and/or opportunities on their own (and address them) or own a critical project. Good communication, leadership and management skills. Codes little or not at all, and only on specific situations.

Definitions

The Title serves as a reference point and can vary from company to company. What company A looks for in a “Senior Engineer” can differ significantly from Company B’s version.

The Scope represents the degree of responsibility at the organizational, product or architecture level. In this framework, the target scopes are a single team, a group of teams, and an organization (major division or the entire company).

Scopes can be further categorized into normal and high stakes. High stake teams, groups and organizations are usually in charge of a core system or platform that many teams rely upon, a mission-critical function or even a very important project. Ex: Infrastructure, Payments, Authentication, etc.

Expectations can be divided into two main categories – Inputs and Outputs. Inputs represent the capabilities, skills and behaviors an engineer displays. These are good predictors of someone’s ability to deliver results and generate impact. That’s what we want at the end of the day.

Outputs represent the results and impact an engineer generates. Results (a.k.a. outcomes) are closely linked with how reliably and how well a person executes tasks and projects of increasing complexity.

Impact represents the net effect of everything a person does. This includes the impact of the projects they tackle, the problems they set out to solve, and even how positively (or negatively) they affect those around them. Think of impact as solving the problem vs doing the task.

Be careful when using impact in performance management. An individual’s impact is heavily influenced by circumstances outside of their control (ex: the team’s product roadmap). Ex: a senior engineer responsible for a major site reliability project must not only execute several complex tasks (results) but, also, interpret their results, iterate on the plan and coordinate at multiple levels to ultimately achieve the end goal of increasing reliability (impact).

Finally, each level also has a reference experience band, in total years of software engineering experience, that a person at that level typically has. This is not a hard and fast rule (more on this later)!

Diving Deeper

The degree of autonomy and impact increases the further up the ladder we go. The work also changes focus from from individual contribution to higher level design, coordination, coaching, strategy and communications.

Reality will not always line up perfectly with this framework. It should not be used as a substitute for good judgement. It’s important to understand the letter and the spirit behind these levels. Examples:

• high potentials: folks with strongly skewed skillsets (ex: strong tech skills, bad interpersonal skills).

• strong demand for a certain role: pushing someone underprepared into larger roles (ex: an L3 supporting a group like an L4, or an L2 tackling major tasks without L3 support).

• small organization size: not enough “room” to provide upwards mobility, increasing the risk of pushing high performers out of the organization.

I will cover these situations in the implementation and maintenance phases in more detail.

Associate Engineers (L1)

Associate Engineers are the entry point in the professional software engineering career. They often have 0-3 years of industry experience. Most are fresh out of college, but you might see a few older folks who are changing career tracks.

Scope

L1s do better in normal (i.e. non-high-stakes) teams.

L1s are expected to introduce production-breaking bugs from time to time. They seem to be able to do this despite sophisticated checks and balances and processes, so just expect that to happen every now and then.

Accept that things will break and place them in an environment where they can safely learn from their mistakes.

Capabilities, Skills & Behaviors

They should be curious, take feedback well, be humble and have a solid foundation of software engineering basics to build upon. This includes data structure fundamentals, basic algorithms, common system and design patterns, well known tools, etc.

Many L1s coming out of top universities or well known companies might have an overdeveloped ego. Look out for difficulties in taking feedback well, learning new things, an “I already know this” attitude or an over-eagerness to introduce new tools or practices without learning more about the status quo.

Results & Impact

They should be able to execute simple tasks without supervision, and tackle medium-level work with L2+ support. Look for clean, well tested code that is not necessarily optimized or well designed at the system level.

They should be able to handle basic on-call duties, but do not expect them to handle major incidents. If you can, schedule their on-call duties together with L2s and L3s. They can still help if an incident happens and they will have a valuable learning experience.

Finally, look for L1s who are growing fast into L2s. That should be their ultimate goal.

Engineers (L2)

Engineers (L2) – are the foundation of most teams. L2s tend to have 2-6 years of experience and a solid understanding of how to craft software in “the real world”. Good L2s will likely build & run the majority of your products – be it by themselves or with the support or L3+ folks.

Common names for L2s are “professional engineers”, “full engineers”, “competent engineers”, and others.

Scope

L2s can make up the bulk of normal teams and some can do well in high stakes ones. They should have a working knowledge of their team’s (technical) domain and how it fits within the group.

Good L2s will also have a basic understanding of who their customers are, which problems they are solving and how the business works. The best ones learn “why” they need to implement Feature A and use that knowledge to drive design and implementation decisions.

Capabilities, Skills & Behaviors

L2s should have a deeper and wider understanding of the fundamental skills they cultivated as L1s. The main difference, however, is knowing how they all come together in the real world and work in practice.

At this level they also should have a deeper understanding of tools and techniques required by your SDLC. This includes source control, releasing, deploying, CI/CD, monitoring, tech ops (in your stack), etc. This includes “business” tools too, like OKRs and KPIs.

Results & Impact

L2s can design and execute tasks up to medium complexity with little to no support, and tackle complex tasks or projects with L3+ support. A team with a good balance of L2s and L3s working together can be very effective.

L2s should also serve as Incident Commander of minor incidents. This will enable them to lead bigger ones in the future.

Senior Engineers (L3)

Senior Engineers (L3) tend to have 5-12+ years of experience and that shows in their degree of maturity. A hallmark of good L3s is that they are the most capable and reliable individual contributors in most organizations, requiring the least amount of support to get the job done.

L3 is the widest and most difficult level to clear in my opinion, with the second half band being much harder than the first. This is where supporting others starts to become a significant part of the job, and that requires developing a whole different skillset.

Scope

Most teams should have at least one L3. L3s can also serve as the foundation of high stakes teams.

Good L3s will have an excellent understanding of their team’s domain, a good knowledge of what other teams do and how the organization works.

Most L3s will be subject-matter experts in one or more non-trivial areas. Ex: you might have an L3 who knows everything about Payments.

Capabilities, Skills & Behaviors

L3s have an excellent command of software engineering and systems design skills in real world settings. They can choose the right design patterns for a given problem, identify operational and security concerns, take cost into consideration, etc.

L3s are effective communicators – they can write clean documentation, effectively align on requirements with stakeholders and implementation details with colleagues, know when to bring relevant facts into a discussion, etc. L3s should be particularly good at adjusting for the audience, leaving technical or non-relevant details out when desirable.

L3s should be able to lead by influence, not authority. They have many responsibilities in supporting and leading others, but not formal authority to compel action (which is not normally desirable anyway). They should be able to engage stakeholders and teammates constructively, have “strong opinions weakly held”, be able to disagree and commit, etc.

L3s are great at managing up, and have a deep enough understanding of how delivering software works that they can work effectively with engineering managers as partners. This, coupled with leading by influence, often makes L3s serve as “tech leads” of their teams. Many Engineering Managers come from an L3 background.

Great tech companies can develop an “L3 Mafia”. Their L3s understand really well what each team does and build a good rapport between themselves. They usually know who to DM when they need some information, a minor change, help during an incident, or anything else that crosses team boundaries – often without needing the support from managers. Good managers would do well to encourage and help build such networks.

Finally, L3s should be good at asking for feedback regularly and responding to it in a mature way.

Results & Impact

L3s can design and implement tasks of all sizes as individual contributors or as leaders of a small task force of L1-L3s with minimal to no support. They are as close to “fire and forget” as you can get.

L3s should also be able to onboard L1-L3s and mentor L1s and L2s. In fact, mentoring, supporting and leading others effectively are some of the most critical skills an L3 needs to master before becoming an L4.

Good L3s can serve as Incident Commanders of critical incidents. They also tend to be “pulled in” into incidents as subject matter experts.

Staff Engineers (L4) and Principal Engineers (L5)

Staff Engineers (L4) and Principal Engineers (L5) are roles where the degree of autonomy, responsibility, and ownership increase significantly, making these levels quite different from the L1-L3 range.

L4s and L5s share many characteristics with the Management track – so much so that, in many companies, the Individual Contributor and Management tracks converge at one point.

As these levels have significantly different mechanics from the previous ones, I will cover them separately in future posts.

What’s Next

This simple framework should be enough to get started in most organizations. Naturally, you should adapt it to the reality of your company. Implementing it and using it to drive hiring, career development, promotions, and other key processes can be challenging in reality, so I will write about these topics in future posts.

I will also cover the Engineering Management and Product Management tracks in the next posts.

In the meantime, happy leveling!