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.
Hiring succeeds best when the hiring team clarifies both their needs and the parameters of the role required to meet those needs. Parameters may include the scope and impact of the role, the and title, day-to-day expectations, and what qualities and skills will help a candidate succeed in the role. Thinking seriously about roles will make every stage of hiring easier and less prone to bias—from , sourcing, and interviews, to making an offer and onboarding.
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 into which they fall.
Every role has certain responsibilities and authority. But more specifically, a person’s impact arises from outcomes—the tangible value to the company, such as revenue, technology, product, or customers, that is uniquely attributable to that person’s work. In practice, a role requires a combination of:
Ability. What skills, knowledge, and past experience are required?
Autonomy. To what degree will the person operate on their own? How much leadership, decision-making authority, and handling of ambiguity is required?
Influence. Will this person have softer ability or less formal agency to positively affect key decisions or people internally at the company?
Accountability. How well does the person carry responsibility? Do they have a reputation for owning responsibility for the outcomes of their work?
The better you can translate your company’s needs into a role, the better you’ll be able to refine the role’s appropriate level, title, and compensation, which inform a that will attract the right candidates.
confusionRoles are often conflated with titles, but they are not the same thing.
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 .
confusionInformally, people often talk about the seniority of a role. Seniority can mean one of three things: Responsibility and authority of the role they hold (a “senior manager”), total experience in their past career (a “senior candidate”), or 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 recently hired Director of Engineering? To avoid confusion, it’s usually best to talk about job levels when discussing roles.
Job levels (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 often have variations in nomenclature and associated scope and responsibilities, but nonetheless tend to align to fairly standard designations set by compensation survey companies like Radford, Connery, and RHR. As companies grow, their incentive systems often become more complex and granular. Established, mature companies have well-codified levels, though they still vary to some degree. 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.
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 It’s rare to be able to negotiate on your level, title, and compensation. As a candidate, reflect on what motivates you; if you’re asking for a better title, an upleveled position, or more cash or equity, it’s critical to have a clear personal rationale for why. Determining your must-haves and your nice-to-haves will better prepare you for negotiation.
Industry tactics for establishing roles, titles, levels, and compensation can be helpful, and can also serve as a basis for creating effective and writing compelling .