You’re reading an excerpt of The Holloway Guide to Technical Recruiting and Hiring, a book by Osman (Ozzie) Osman and over 45 other contributors. It is the most authoritative resource on growing software engineering teams effectively, written by and for hiring managers, recruiters, interviewers, and candidates. Purchase the book to support the author and the ad-free Holloway reading experience. You get instant digital access, over 800 links and references, commentary and future updates, and a high-quality PDF download.
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.
Table: General Levels Structure
Developing professional and technical expertise. Able to resolve routine issues and problems.
Well developed professional and technical expertise. Affects quality and timeline of part of product or service.
Seasoned professional with competence, creativity in wide range of technical areas. Resolves most issues and problems effectively.
Extremely seasoned professional. Able to solve most issues and problems. Uses skills to drive company objectives and achieve goals.
Wide range of experience, and is looked to as a thought leader and technical guru. Affects design, quality and timeline of entire product or service.
Superstar. Critically important to growth and product development. Only a handful at this level throughout the company. Develops department objectives from company strategies.
Levels.fyi has collected data from thousands of software professionals about their level, title, and associated compensation. You can see a sample of levels for a variety of companies on their site. Below are a few representative companies plus a “Standard” set of levels that they’ve abstracted from all the self-reported data they’ve collected.
Recruiting veteran Jose Guardado suggests that startups generally 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 that 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.
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. For instance, 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 management ladder for more senior employees.
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 (across Starting, Individual Contributor, and Management tracks):
Table: Starting Track
Has engineering and programming foundation. Expected to spend majority of time learning about code and development best practices. Understands scope of small features. Has a basic understanding of what all components in their product are.
Has a basic understanding of development best practices and comfortable writing code. Uses and understands tools needed to debug and diagnose issues in a test and/or simple production environment. Understands the scope of medium features. Has a basic understanding of all their product components.
Has in-depth understanding of development best practices. Has mastered the tools needed to debug and diagnose issues in any type of environment. Understands the scope and relationships of large features and production stack for their area. Has subject matter expertise in at least one component. Has a good understanding of all components of their product.
Performs basic programming tasks. Contributes to functional specifications and participates in code reviews. Writes and executes test plans.
Performs standard programming tasks. Contributes to functional specifications and participates in code reviews. Writes and executes test plans.
Performs complex programming tasks. Participates in code reviews and can sign off on small features. Writes and executes test plans. Can write functional specifications for small features.
Given an introduction to a small task from a more senior engineer, can drive a task to completion independently. (Can fill in the blanks)
Given an introduction to the context in which a task fits, can design and complete a small to medium sized task independently. (Can create some blanks)
Given a medium to large understood problem, can design and implement a solution.
Shows initiative and is motivated to learn. Provides guidance to interns.
Shows initiative and offers assistance when needed without being asked. Provides guidance to entry-level engineers. Constructively escalates problems and issues.
Shows initiative and offers assistance when needed without being asked. Delivers feedback in a constructive manner. Provides guidance to entry-level engineers. Works well with technical leads, incorporating feedback as needed. Helps focus discussion on important aspects.
Source: Sequoia Capital*
Table: Individual Contributor Track
Has mastered development best practices. Understands the limits of our tools and when a problem that exceeds those limits deserves the effort of producing a new tool. Understands the scope and relationships of large features and production stack for their area. Has subject matter expertise on multiple components. Has a strong understanding of all products relevant to own areas of expertise.
Has deep knowledge of entire system, and can jump into code in any component and fire fight and contribute. Makes decisions on product direction and internals based on deep subject matter knowledge.
Performs expert programming tasks. Handles large-scale technical debt and refactoring. Shapes coding methodologies and best practices. Participates in code reviews and can sign-off on large features. Can sign off on test plans. Participates in requirements gathering with a customer.
Sets product direction and has ownership over large components. Thinks both strategically and tactically, keeping in mind both technical goals and company goals.
Given a large, poorly understood problem, can explore the solution space (possibly with numerous POCs) to determine correct course of action. Participates in and supports initiatives outside of main area of responsibility. Provides technical leadership for projects including 1–2 individuals.
Given long term strategic goals, can lay out a path across many versions. Participates in and supports initiatives outside of main area of responsibility. Provides technical leadership for projects including 3–4 individuals.
An approachable mentor who is viewed as an expert and acts like one. Constructively challenges assumptions. Guides more junior engineers to correct solutions while encouraging collaboration.
Builds strong relationships in their own team and across the company. Understands multiple points of view and drives a process to conclusions in a timely and respectful manner.
Source: Sequoia Capital*
Table: Management Track
Leads team and/or projects
A senior engineer, who in addition has very broad knowledge of the entire product, and can help with any component, or type of issues. Strong awareness of the state of the product and team at all times.
A great lead engineer, who knows how to allocate resources among projects and understands how company priorities map to their tasks.
Knows the entire product, how customers use it, what they want, and where it should go.
Contributes to code at a Senior engineer level (or above). Prioritizes work across projects and people. An expert firefighter who is often called in to make things right. Shows great ability to direct project and/or people.
Balances strategic and tactical goals, distributes work across team. Shapes coding methodologies and best practices. Participates in requirements gathering with a customer.
Owns a product, the team, and is responsible for both.
Leads projects and/or small teams. Participates in and supports initiatives outside of main area of responsibility.
Manages multiple teams and projects. Responsible for team retention and hiring.
Is a great leader, sets direction for product. Understands vision, drives it forward.
Takes responsibility for their team/project. Communicates effectively and respectfully to all members of the organization. Keeps team morale high. Supports and motivates team members.
Takes personal accountability for failure, while praising team for accomplishments. Communicates effectively and respectfully to all members of the organization. Keeps team morale high. Mentors team members.
Works exceptionally well with their own team, other engineering teams, and the company at large. Takes responsibility for their team and product.
Source: Sequoia Capital*
You’ll notice that both the Radford and Sequoia 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:
contribute If you’re aware of other companies’ published engineering ladders, please let us know!
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.
Systems Engineer; Systems Architect; Systems Analyst; Software Architect
Product Engineer; Full Stack Engineer; Backend Engineer; Frontend Engineer; Web Developer; Application Engineer; Application Architect; Enterprise Architect; Information Architect
Machine Learning Engineer; Data Scientist; Data Architect; Data Analyst; Data Engineer
DevOps Engineer; Site Reliability Engineer; System Administrator; Cloud Architect; Infrastructure Engineer
Quality Assurance (QA)
QA Engineer; SDE in test (SDET); Test Engineer; Quality Engineer; Automation Engineer
Solutions or Sales
Solutions Engineer; Customer Support Engineer; Solutions Architect; Sales Engineer; Professional Services Engineer
IT Administrator; System Administrator; Network Administrator; Database Administrator
Security and Compliance
Security Engineer; Security Architect; Information Security Analyst; Information Security Architect
Engineering Manager; Development Manager; Software Engineering Lead; Senior Software Engineering Lead; Director of Engineering; Senior Director of Engineering; VP of Engineering; Senior VP of Engineering; CTO; CISO; CIO
contributeIf 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:
It isn’t easy to build pay systems that inspire, guide, and energize people without at the same time damaging your organization and people… Don’t try to solve every problem with financial incentives.Jeffrey Pfeffer and Robert Sutton, co-authors and professors, Stanford*
DefinitionCompensation is any remuneration to a person—including employees, contractors, advisors, founders, and board members—for services performed or rendered to a company. Compensation may be in any combination of cash (salary and any bonuses); equity in the company; and non-cash pay, such as health insurance or other benefits, family-related protections, perks, and retirement plans.
Some companies underestimate the importance of compensation, perhaps by not understanding a candidate’s financial needs or by overlooking what compensation can signal. Compensation can be intertwined with other things candidates care about. For instance, a candidate might implicitly correlate the impact of their role with their level of compensation and thus interpret compensation as a signal for whether their company cares about them and the work they do. Candidates might consider an increase in compensation as a signifier of progression in their career. They may derive their self-esteem from that number, or compare it against what’s earned by peers, friends, or family. Or, they might use compensation as a proxy to judge how “elite” a team is. These correlations may not always be valid—a company with high salaries may be packed with all-stars, or it could just be overpaying to compensate for something else, like poor work-life balance or a toxic culture.
You’re reading a preview of an online book. Buy it now for lifetime access to expert knowledge, including future updates.