Job Titles and Levels: What Every Software Engineer Needs to Know

Photo by Ales Krivec on Unsplash.

This post is excerpted from Holloway’s Guide to Technical Recruiting and Hiring.

Typically, everyone on a software team has a job title and knows it. It could be Software Engineer, Senior Staff Software Engineer, Full-Stack Engineer, Director of Engineering, or something less common or quirky, like Software Evangelist or Director of Spam Research.

But job titles are actually pretty confusing. In startups, titles are often chosen quickly and without much careful thinking.* And in large companies, conventions on titles vary widely, and while we notice them, we often don’t think about what purpose they really serve.

Is a person’s title related to how much experience they have? Are titles standardized within a company? Are they a reward for performance, or do they reflect what you do, or show how much you’re paid?

In general, a title is just words on a business card (and few software engineers even need those). But it’s the level of your job that really reflects scope of responsibility. We’ll talk about roles and levels and how they relate to job titles.

This in-depth guide based reflects expertise from over a dozen hiring managers, engineering leaders, and recruiters. If you’re an employee hoping to understand how your title or level fits into an organization, a hiring manager creating a job description for an open role, or a founder who wants to create a leveling rubric, this post can help you think about the fundamentals and best practices.

You’ll find more information on how roles are created and how to define an open role at your company in the complete Guide to Technical Recruiting and Hiring.

What Are Roles, Titles, and Levels?5 minutes, 4 links

What’s your job? You probably know what you do every day. But answering that question succinctly in a way that is accurate and comparable to others isn’t as simple. In fact, especially early in their career, employees may think about “getting a promotion” but not really understand what that means in terms of a company’s roles, titles, and levels. So let’s define our terms up front.

A role (or position) is the part an employee plays within a team and company, including the set of formal and informal expectations that define the employee’s responsibilities. A role also situates an employee within an organization, and it may correspond to the job level into which they fall.

The impact a person has within a company arises from the outcomes of their role—the tangible value to the company, such as revenue, technology, product, or customers, that is uniquely attributable to that person’s work. Roles require a combination of ability, autonomy, influence, and accountability. Many companies choose to include a level and title as parameters or expressions of a role. Both levels and titles help to situate the role within the context of the company and make the role more translatable to those outside the company.

A job title is the name assigned to a particular position at a company. Job titles provide a brief description of the position, and can vary in that descriptiveness, ranging from the general—Software Engineer or Web Developer—to the specific—Senior Staff ML Engineer. Job titles are usually public facing and may only loosely reflect the true scope and impact of a job, which is conveyed more formally and internally by the job level.

​confusion​ Informally, people often talk about the seniority of a role. But informally, “seniority” can be used to mean three different things:

• Responsibility and authority of the role they hold (a “senior manager”)
• Total experience in their past career (a “senior candidate”)
• Actual time with the company (an employee “with seniority”)

Is an individual contributor with the title Senior Software Engineer, who has been with the company for ten years “more senior” than a Director of Engineering who was recently hired? To avoid confusion, it’s usually best to talk about job levels.

Job levels (or job grades) are formal categories of increasing responsibility and authority in a company. In general, the higher level the role, the more autonomy and the greater skill, independence, accountability, and leadership the company expects. Companies can also draw on job levels for such classification tasks as determining compensation, codifying role-appropriate expectations for employees, or supporting internal lateral movement.

Levels have widely varying names and subdivisions. For instance, Google has eight levels in its standard engineering track, and Microsoft has thirteen. Levels and titles often (but not always) interact here, applying additional details to titles like I, II, III, and moving up to more detailed seniority classifications like Staff, Principal, Distinguished, and Fellow. Levels.fyi does a nice job tracking these for some big companies. As companies grow, their incentive systems often become more complex and granular. Established, mature companies have well-codified levels that may or may not look similar to other companies of the same size.

But whatever they are called, levels can be aligned with fairly standard designations, such as the ones set by compensation survey companies like Radford, Connery, and RHR.

Ultimately, levels reflect the employee’s value to the company based on the impact they’re expected to deliver. For this reason, compensation is typically tied directly to clearly established, standardized levels. This helps demonstrate career progression for candidates and employees, and reduces bias in setting pay levels and determining promotion and other performance rewards.

​candidate​ As a job candidate, it’s rare to be able to negotiate on your level, title, and compensation. Before negotiating an offer, reflect on what motivates you; if you’re asking for a better title, an up-leveled position with greater responsibility, or more cash or equity, it’s critical to have a clear personal rationale for why. Determine your must-haves and your nice-to-haves, including whether a specific title is important to you.

Industry tactics for establishing roles, titles, levels, and compensation can be helpful, and can also serve as a basis for creating effective hiring plans and writing compelling job descriptions.

Setting Levels and Titles11 minutes, 32 links

Leveling is a discussion, not a homework exercise. It is a significant change in your culture and your way of doing things.Ashish Raina, compensation consultant*

Levels help to support meaningful growth for engineers, unify expectations across engineering, map compensation fairly, and allow for consistent and ideally unbiased evaluation of candidates. Employees at the most junior levels are typically those without much industry experience, like interns or recent graduates. At the highest levels are employees who may have broad and deep enough impact to significantly change the trajectory of your team or company.

​startup​ Smaller companies without much structure—and where engineers cover a wide variety of responsibilities—may have very simple titles without any levels, or some very simple levels (for instance, junior and senior software engineer). Hiringplan.io provides a helpful general structure to start thinking about levels:

Sample levels and descriptions from hiringplan.io

Levels.fyi has collected data from thousands of software professionals about their level, title, and associated compensation. Here’s a few representative companies plus a “standard” set of levels that they’ve abstracted from all the self-reported data they’ve collected:

Source: Levels.fyi

Formalizing Levels

​startup​ Recruiting veteran Jose Guardado suggests that startups generally want to be post-product-market fit with defensible revenue and enough size and complexity in their engineering organization—typically around 100 people—before they consider implementing levels. Series C funding appears to be a common inflection point for this, which also often coincides with when the startup begins considering creating an HR role. “Many companies don’t really start doing this, though, until they’re feeling some significant pain,” he notes.

Companies wishing to establish more formal levels typically use leveling rubrics from companies like Radford, Connery, or RHR. These companies establish a set of levels based on extensive survey data, including salary information which can be used to set compensation for each level. (At some point, likely when you get into the high hundreds to thousands of employees, you may find that the complexity of your organization merits a little extra help. Salary survey consulting groups specialize in helping companies do just this.) Here’s a sample level rubric from Radford, which specializes in technology and life science companies:

The Professional designations roughly correlate to engineering levels, and you can use this as a baseline to customize the specific impact details for each level to your needs.

Ladders

Companies often create career ladders or career lattices that illustrate the job levels at the company, explain what is expected of employees at each level, and clarify the different growth paths an employee can take. A career ladder shows only vertical progression through job levels, while a career lattice shows possible lateral movement as well. A common pattern at tech companies is to provide a dual-ladder approach, in which there is a technical ladder for individual contributors and a separate management ladder.

There are both benefits and risks to having more structure around levels. On one hand, without levels, engineers may be unsure about how to progress in their career and have more impact, and the company might end up making arbitrary decisions around promotions and performance management. Clearly delineated levels in a career ladder help mitigate bias and provide fairness and transparency. On the other hand, these systems add complexity. They also risk undermining employees’ intrinsic motivations, and many companies find that people can become fixated on their level or title and lose a focus on teamwork and collaboration. A dual-ladder approach in particular can introduce concerns about fairness between individual contributors’ and managers’ career prospects.*

For the purposes of hiring, it’s important to have some sort of structure, with the appropriate level of complexity based on your company’s stage. This structure will help ensure that your hiring assessments and your expectations of future employees are aligned. It will also help you decide what role (and corresponding level, title, and compensation) a new hire should receive.

You can browse a collection of ladders and rubrics made public by their respective companies at progression.fyi. It’s a good exercise to read through a few of them and understand the reasoning and philosophies behind them.

Sequoia Capital shared an anonymized example leveling rubric for one of their portfolio companies; it shows how they map knowledge/skills, complexity, independence, and character (traits and values) to similar levels:

Starting Track

Individual Contributor Track

Management Track

Source: Sequoia Capital*

You’ll notice that both of these rubrics split the levels between individual contributors (ICs) and managers. The tech industry has moved away from viewing management as the de facto progression in an engineer’s career, with an increasing number of companies providing separate management and IC tracks that can support both paths without forcing engineers into management. While levels alone indicate some degree of advancement and progression, most companies that have formal levels eventually establish ladders to further clarify how employees can progress up levels, either on IC or management tracks.

Further Reading on Ladders

Here are some additional resources and a few public examples of ladders that aren’t on progression.fyi:

• Engineering director Chuck Groom highlights key differences people might see between ladders, including:

  • How many individual-contributor levels should there be? (Three? Six?) What do you do with your super-senior folks?

  • How detailed should your job ladder be? (This runs the gamut of complex point systems, spreadsheet matrix, paragraphs of text, or just a few general guideline bullet points.)

  • What are the specific roles and responsibilities for a “tech lead”?

• “How to implement an engineering ladder at your organization,” by Lisa van Gelder

• Axelerant

• Buffer

• Foursquare

• Glossier

​contribute​ If you’re aware of other companies’ published engineering ladders, please let us know!

Job Titles

Something as seemingly simple as a job title can contain and convey a complex range of information—the nature and scope of work someone is responsible for; how senior they are; and potentially whether they report to or manage other people.

Titles can be confusing. Systems Engineer could mean very different things to different teams or companies depending on the degree of specialization. Someone who works on applications could be an Application Engineer or a Fullstack Engineer or a Frontend Developer. And yes, you’ll even see Programmer thrown around as an actual title. Any titles might also be combined with seniority designations such as Junior, Senior, Manager, Director, and more. This can make it hard to determine meaningful relative comparison across organizations—an Engineering Manager at a startup compared to one at Google likely have very different responsibilities.

Larger companies typically develop specialized titles based on the functional area, as shown in the table below.

​contribute​ If you know of other titles or categories we’re missing here, please let us know!

Some companies take a philosophical stance against job titles. For example, Gusto had no job titles, even at 800 employees and including its executives. Stripe* and CloudFlare* have similar approaches. Others allow anyone to choose their own job titles. But typically, smaller companies start with a simple approach, like dividing roles into really broad categories like Developer or Software Engineer, and maybe Frontend and Backend, depending on the role. For comparison, see how Basecamp (50 employees) handles their developer titles.

Ideally, titles also map to levels, but this isn’t always possible or necessary. The role (and its own associated level, responsibilities, and outcomes) conveys much more about what the candidate’s experience will be, should they join your company.

No matter what, as you think about titles for roles you intend to fill, consider the candidate perspective. For many companies, titles are merely perfunctory words that describe a role; but the title you choose for a role is often the first thing that a candidate sees. And to candidates, titles can reflect a complex interplay of self-worth, social status and influence, and potential advantages or pitfalls when they look to get promoted or find another job.

Tips for Writing Effective Job Titles

The most effective titles are specific, descriptive, and concise. This post from Recruiting Intelligence on writing effective job titles covers a few key guidelines, including specificity and clarity about the role (details like seniority, backend vs. frontend engineer); avoiding abbreviations or acronyms and quirky descriptions (Sr. Happiness Mgr); and skipping superlative or idiomatic descriptions (because terms like “rockstar” or “guru” may deter qualified applicants from applying).

Job titles are a form of marketing. Most inbound candidates will find a job listing via some form of online search. With that in mind, it helps to consider some search engine optimization (SEO) tactics that will help your job show up and stand out. (These principles will apply to the content of your job descriptions as well.) Here are a few resources for factoring in SEO when deciding on titles:

• “How to Write SEO-Friendly Job Titles and Descriptions,” from Recruiting.com

• “Search engine optimized job descriptions: dos and don’ts,” from Workable

• “8 Ways to Make your Job Title SEO-Friendly,” from TMP Worldwide

• Keyword planner from Google

• Keywordtool.io