An impact-based level system for engineering organizations

Defining L1-L6 for individual contributors and leads

Every software company eventually has to deal with the job title problem. Some organizations go with a “flat” system, but in absence of a title system, shadow hierarchies will appear, which are actually worse. Titles give a clear demarcation around the impact expectations of each role. For example, it is much easier to hold a Staff Engineer responsible for technical leadership when that role is clearly defined. Without role definitions, you’ll naturally see the loudest people rising to the top and the quiet/contemplative types getting buried.

The challenge with clearly defining your company roles is that people will naturally try to game the system (always arguing that they deserve the next title/pay bump). To counter this, I’ve seen organizations create longer and longer definitions to avoid edge cases. Eventually, the definitions take up multiple pages and can no longer be held in peoples’ heads. As the system’s complexity grows, people’s adherence to it wanes until they just stop following it. I believe there is a better way. Therefore, I propose the following.

Don’t pay people for the number of people they lead or the lines of code they write. Pay them for the results they generate.

The above philosophy is powerful and liberating. It doesn’t matter if you are an individual contributor (IC), a technical lead, or a team lead. What matters is how much your contributions affect the bottom line of the business.

This post proposes a tiered system that can apply to both ICs, tech leads, and team leads. This system is summarized below. There is a table later in this post that goes into deeper detail.

• Level 1 — Scoped Tasks
• Level 2 — Scoped Projects
• Level 3 — Unscoped Projects
• Level 4 — Team Force Multiplier
• Level 5 — Group Force Multiplier
• Level 6 — Company Force Multiplier

For the rest of this post, I’ll refer to the levels as L1 through L6. This proposed system has several basic governing rules, which are listed below.

Rule 1: As business impact increases, so should compensation (measured by level).

Rule 2: As the company grows and risk decreases, the compensation philosophy should change from equity-centric to cash-centric.

Rule 3: When companies are very small, titles shouldn’t matter, and when they grow very large, L2 through L6 will typically be expanded with senior titles.

Rule 4: As your company grows, you’ll need to periodically de-level people (Dunbar’s number can be your baseline).

Rule 5: ICs and leads are both on the same scale, as the business impact is how people are measured. L6 ICs are rare but not unheard of.

If you are at a startup leveraging equity-heavy compensation, people should be more motivated by the success of the company than by increasing their own levels. In other words, the individual’s best path to financial security should be to make decisions that maximize the success of the business rather than increase their own personal standing within the business. In this environment, it is more useful to think of the levels as a framework for measuring and discussing impact than as a compensation framework.

This system works well for organizations with 25–1,500 engineers (100 to 4,000 employees). Again, at the lower end of this scale, you should not be leaning hard into titles/levels, but it’s not a bad time to introduce the concept.

If you are interested in reading further, I think it’s important to build from the ground up. Therefore, the rest of this post will discuss

• my philosophy around compensation (including business impact and resource scarcity),
• a deeper explanation of the six levels, and
• down-leveling people as your company grows.

Compensation Philosophy

The philosophy is simple: compensation should be in the service of maximizing revenue, minimizing cost, or reducing risk to cash flow and profit-maximizing.

On a fundamental level, your business needs to produce a good or service that is worth more to your customers than it costs to build it. Employee compensation usually holds a disproportionate amount of those building costs. For some employees, you might think about their compensation in terms of return on investment (ROI) within the fiscal year, but for engineering, you tend to think about ROI in terms of compounding value over multiple years. For startups, that ROI might take 5–10 years to fully pay off, and your early employees would be the only reason you made it that far. Think of it this way:

Every role has an impact on company financials, even if measuring that impact is difficult. A for-profit company should always pay people less than the money they generate and strive to maximize the delta between those two numbers. The minimum compensation is based on the market rate (supply/demand) of that role. An ideal level and compensation plan should provide a framework to encourage the exiting of poor performers and the growth of medium to high performers, all in the service of maximizing the business fundamentals. This leads me to the following:

• Every role is revenue-generating or cost-reducing on a long enough timescale.
• A for-profit company should always pay people less than the money they generate (long term).
• Market compensation is directly related to the scarcity of resources.
• A for-profit company should strive to maximize the delta between an employee’s compensation and its positive impact on the financials.
• The best way to maximize the delta is to focus on increasing the value generated, not decreasing total compensation.

A deeper explanation of the six levels

The table below uses a bottom-up approach, talking through each compensation level by increasing impact. The idea is that the further you move down the table, the higher the impact on the company. As people increase in level, they begin to transition from dependent to independent and finally to interdependent (see Stephen Covey’s 7 habits). Simultaneously, they are held more responsible for the business outcome (and not the technical specifics).

Note that the information below reads much better in a table which I’ve included in this Google doc.

L1 — Scoped Tasks: interns and new hires

Dependent and not responsible for business outcomes

Responsibilities: An L1 executes tasks with little or no ambiguity that have already been scoped by a more senior engineer. Generally, there is an assigned, hands-on L3 mentor to help tasks flow and keep the L1 unblocked.

Performance flags: This state is only acceptable for less than 3 months, making it appropriate for interns and new hires. If the person doesn’t graduate in their first 90 days, this is a significant problem.

Ready to level up: The employee is able to unblock themselves on a technical level and can be trusted to find their own way from A→B on a project, and what they build is technically sound and supportable. They’ve experienced the full lifecycle of a project from creation to support.

L2 — Scoped Projects: software engineer

Dependent and not responsible for business outcomes

Responsibilities: An L2 depends on a more experienced engineer with more business context to make the final call on technical tradeoffs, feature prioritization, or the necessary quality bar. The expectation is that an L2 executes according to the plan and thus isn’t responsible for the plan itself being flawed. An L2 is trusted to be on the support queue.

Performance flags: The employee fails to deliver their work on time and fails to effectively communicate blockers in a timely manner. In addition, most L2s should be on a one-to-two-year path toward L3.

Ready to level up: The employee is taking responsibility for their projects, including inter-team communication and technical decisions. Trial them out with an unscoped, small project and see if they deliver features that arrive on time and on budget and delight the customer.

L3 — Unscoped Projects: senior engineers and team leads

Independent and situational responsible for business outcomes

Responsibilities: The key phrase for an L3 is “trust.” You trust that they will be successful on a variety of projects and with only light direction from an L4/L5. You trust that they will pump the breaks, pull in an L4/L5, and pivot as needed. This is an ideal place to be, and a team of all L3s is a force to be reckoned with. The majority (>50%) of software engineers will remain L3s throughout their careers.

An L3 can be a team lead or an IC. Team leads should be responsible for a squad/pod of two to three people. Their focus would be on execution and not career growth or direction. They operate within the feedback, structure, and direction (FSD) of the team prescribed by the Engineering Manager.

Performance flags: You lose faith in their ability to execute and begin second-guessing if you can trust their output. They always have an excuse for why a project failed, but it wasn’t their responsibility.

Ready to level up: The L3 begins going outside of their lane and pushing to modify the FSD of the team. For ICs, this comes in the form of pushing for team technical growth, proposing new architecture, taking on key technical debt initiatives, and becoming a center point for technical guidance. For leads, this comes in the form of pushing to be more deeply engaged in requirement gathering, planning, and career growth.

L4 — Team Force Multiplier: staff engineers and engineering managers

Interdependent and responsible for business outcomes

Responsibilities: Team force multipliers are people who increase the impact of a team far beyond the contributions of a single individual (use 3x as your mental model). This means that an engineer is consistently going outside of their own lane to push forward the entire team. Team leads and tech leads do this via systems of feedback, structure, and direction. Below is an illustrative example.

• A good code reviewer is an L3.
• A L4 starts reading groups on how to be a good code reviewer, pushes to install code quality analyzers on the code base, and creates training guides on team code review practices.

Other engineers are quick to recognize an L4 because their impact is felt viscerally throughout the team. It’s possible to be an IC and an L4, but it’s rare. It implies that their code is worth 3x that of an L3. This can happen, however, if the underlying code is specialized (aerodynamic algorithms, AI, hard schedulers, etc.).

Performance flags: When an L4 falls below their level, the entire team generally suffers a drop in both product quality and feature delivery. Usually, this is a result of bad judgment, lack of follow-through, or an inability to scale their practices with the ever-increasing complexity of their team.

Ready to level up: Like an L3, an L4 is ready to be an L5 when they are consistently going outside the lane of their local ecosystem (team) and thinking about the macro environment. You’ll see them helping other teams with their FSD and engaging deeply in their planning and direction. L4s that want to be L5s don’t need encouragement to get to the next level, and they strive for it.

L5 — Group Force Multiplier: principal engineers and directors

Interdependent and responsible for business outcomes

Responsibilities: A L5 is to an L4 what an L4 is to an L3. They are force multipliers for the force multipliers. This means that they act almost exclusively in a meta-engineering fashion. From the people side, these are your leads-of-leads, where each engineering manager is significantly more effective as a result of the direction from the L5. Technical L5s are much rarer, but they do exist. These are the people who either mentor the staff engineers or make architectural decisions that affect entire groups.

Performance flags: As with an L4, look at the entire product as a reflection of the capabilities of the leadership. If they have been provided adequate autonomy, an L5 has a significant ability to restructure their world as they see fit. They control hiring, team makeup, objectives, and responsibility delegation. If the combination of all these yields a bad product, I recommend looking to replace them.

Ready to level up: The comp and responsibility band for this level is quite large and highly dependent on the context of the business. Even between a director and a VP, there is a significant change in skills required.

L6 — Company Force Multiplier: VP or head of engineering

Interdependent and responsible for business outcomes

Responsibilities: L6s are heavy systems thinkers whose primary focus is aligning people toward worthy outcomes. Like a set of Russian nesting dolls, they are the next layer between the CSuite and the rest of the company. For engineering, a VP’s primary job is ensuring that the leadership team is free to focus on upside maximization because the scaling and day-to-day minutia within their organization has been well-handled.

Example: When the (new) head of infrastructure talked to Mark Z for the first time, he said, “I hope this is the last time we meet.” What he meant was that Mark Z should be free from thinking about infrastructure scalability and able to focus entirely on what to build next.

Performance flags: As hinted at above, a VP is failing if they are unable to keep up with the needs of the business and are preventing the CSuite from thinking about upside maximization.

How business initiatives are treated at each level

Another way to explain the levels is a top-down approach, which is what the tables below are trying to achieve. In this case, the idea is to show how key business initiatives trickle from top-level business initiatives down into specific tasks done by L1s. These examples are very specific, and in your organization, they might not make sense.

How ICs and Leads fit into the same level

This last table is meant to differentiate between team leads, tech leads, and ICs. The underlying thesis of this engineering-level system is that increased impact is the thing to be rewarded, not tenure or the number of direct reports. However, I’ve found the visualization useful to help ICs, tech leads, and team leads see that there are multiple paths they could take to achieve the same level.

How can an IC be an L6?

For an individual contributor to achieve L6, they need to be affecting the entire company with their individual contributions. This is like saying that they are a 100x engineer (you’d trade 100 engineers for this one person). It’s theoretically possible but highly situational. An example might be

• an engineer at AWS who single-handedly rewrites <fill in the blank>to be 30% more efficient (saving billions in hardware).

While this seems far-fetched, it is the reality in other fields like sports. Stephen Curry makes $45m annually, whereas the head coach only makes $5mm, making the coach the eighth-highest-paid person on the team. This is because Curry, as an individual, generates a disproportionate amount of the team’s success (and thus revenue via ticket sales and advertising). In engineering, tech leads and team leads tend to be the scarce resources, and few engineers are worth 9x their peers.

Down-leveling people as a company grows

It goes without saying that when an engineer is executing below their level, you have a problem. You can’t leave people in senior positions if they aren’t good examples for others. Everybody notices, and it erodes your ability to hold people accountable.

As companies grow in size (from 25 → 250 → 2,500), the technical and leadership challenges grow in size accordingly. Some of the people that you originally hired grow into these roles, but others get outpaced and need to either be down-leveled or exited. My belief is that you can make the process of down-leveling people much easier if you warn them about it ahead of time. But first, let’s talk about why down-leveling needs to happens.

• Complexity increases over time — The larger the code base, the more difficult it is to make substantive changes. Simple as that.
• Inertia increases over time — As much as you want to always remain a flexible company, the longer you stay in business, the more things fall into the category of “that’s what we do here.” Whether it’s your annual review process or your sprint planning, it becomes more and more difficult to shift certain ideas over time.
• Consequences increase over time — When a company is small and making $1mm/year in revenue, then doubling the revenue is worth $1mm. Doubling Google’s revenue is worth more than the entire GDP of Utah. At Walmart scale, there are 3 million people who depend on the decisions that Walmart leadership makes.

For these reasons, you can’t compare a staff engineer on Google Ads with a staff engineer at a 10-person startup. The requirements and consequences of the role are too different. So what do you do with the staff engineer you hired at 10 people when their skills haven’t grown to match your new company size of 250 people?

Now before we answer that question, let’s point out one more key difference: Google can afford to pay $750k per year for an engineer capable of making decisions that affect billions of dollars. A startup can’t (and shouldn’t). However, as a startup grows in value, its compensation bands grow with it. So, my recommendation is as follows.

As your startup reaches major growth milestones, conduct a change in compensation bands and re-title people.

The staff engineer who was good at making decisions that affected 10 people might be struggling to steer 50 people. The team lead who successfully led the engineering team in the early stages might need to take a different role at a later stage.

If you warn people ahead of time that their roles will increase in difficulty, it will be much easier to help the majority of them transition.

I’ve seen this handled in an ad-hoc manner, and the conversations were much more difficult. If, instead, you make it a company-wide event, then the re-titling isn’t nearly as big of a deal — especially if it’s coordinated with an increase in the compensation bands. By doing a coordinated event, you can make many adjustments at the same time and not drag it out.

Wrap-Up

Compensation philosophy is a complicated topic, and it’s very easy to over-engineer it. My belief is that focusing on impact-driven compensation is a simpler and more fair technique than trying to iterate through all possible responsibilities and behavior. In the end, it aligns the business incentives with the individual incentives: they are rewarded for their work product that improves the company’s topline metrics (revenue, cost reduction, or risk reduction in a key area).

The proposed level system is:

• L1 — Scoped Tasks
• L2 — Scoped Projects
• L3 — Unscoped Projects
• L4 — Team Force Multiplier
• L5 — Group Force Multiplier
• L6 — Company Force Multiplier

This system applies to individual contributors, technical leads, and team leads. You can use it with a team of 20 engineers, or a team of 500. Eventually, this system gets expanded with “senior” roles to provide a more rich career path for folks.

If you like this article, let me know by following me here or on LinkedIn

-Elliot