Defining Roles

34 minutes, 33 links


Updated August 24, 2022
Technical Recruiting and Hiring

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.

Understanding the role you need to fill is one of the most challenging parts of the hiring process. It is a bit of an art, but it will be a lot easier if you’ve seriously considered your company motivators and the potential needs of your candidates.

When defining the role you’ll be hiring for, it’s best to begin by identifying what you would consider to be successful outcomes for that role. The next step is to determine what strengths and competencies will predict a candidate’s success in the role. This will likely encompass some mix of technical skills, nontechnical skills, and a certain set of traits and values.

Outcomes and Responsibilities

It’s tempting to want to jump into specifying concrete things about the person you want to hire by describing their skills or experience. However, because you want someone who will succeed in the role, it’s helpful to specify the outcomes you want before attempting to describe candidates. Starting with individual requirements might cause you to lose perspective of what you actually want to accomplish later in the hiring process.

Answering the following questions will help determine successful outcomes for this role:

  • What will occur if you hire someone who is successful in this role?

  • What would be the impact on the team, the business, or the product?

Next, you can pick a time period—a year, five years, ten?—and then break that down into what would need to be accomplished in shorter periods to meet those outcomes:

[What would] a typical day or quarter [look like] for a person in this job? If someone executed perfectly in this day or quarter you designed, would it meaningfully and reliably drive impact for the company and business? Will executing at that level even be feasible and fulfilling for a single person?AnnE Deimer, Inclusion and Diversity Program Specialist, Stripe*

You’ll begin to see what responsibilities the role should entail to reach these desired outcomes. Note that responsibilities are activity-based (like “design, implement, and maintain software”) and outcomes are results-based (like “help rewrite our feed service to improve the experience of over 100M monthly users”). When aligning with your team, it is best to focus on outcomes. The responsibilities of the role may make more sense for a manager to determine.

caution One pitfall to avoid when thinking about outcomes is making them too temporal or short-term focused. If the immediate need is for a specific project, what will the role look like beyond that? If you can’t articulate how the role will evolve over time, you may not need to hire a new full-time employee.

Unlock expert knowledge.
Learn in depth. Get instant, lifetime access to the entire book. Plus online resources and future updates.

Desired Skills and Characteristics

Once you have clarity on what success looks like for the role, the next step is to come up with a set of competencies and characteristics that will make that success likely, including specific technical skills, nontechnical skills, and traits and values.

While seriously considering each of these buckets is important, it’s wise to be careful not to end up with a list of rigid (and uninspiring) check-the-box criteria. If your criteria are too rigid, you might overlook some of the most promising candidates, especially if the role itself is a little ambiguous or is expected to evolve in the future.

Desired Technical Skills

When compiling a list of competencies needed for an open role, an obvious starting point is to define what technical skills are needed for the job. Technical skills relevant to software engineering positions most commonly include familiarity with or mastery of a software-related domain (like machine learning or cloud infrastructure), a coding language (like C++), or a tool or framework (like Apache Kafka). Technical skills more broadly involve actionable knowledge related to math, science, finance, and project management, technical writing, and many other fields.

A list of desired technical skills also flows from the outcomes and responsibilities you determined for the role. What technical skills are necessary for success?

These skills may not be strict requirements, but the more concrete they are, the better you or your team can judge them from a candidate’s profile (for instance, when screening resumes) and assess them in interviews or work samples. A good list of skills will also help candidates better understand the role and whether they should apply.

It’s important to think about which technical skills are strict requirements and which are skills that can be easily picked up on the job. For instance, for an entry-level engineering role, you might expect a candidate to have good working knowledge of at least one programming language, and will likely want to assure yourself that they’ll be able to learn other programming languages on the job. It might be worth splitting out which skills the candidate must have to succeed in the role, and which skills would be nice to have—preferred, but not required. Google calls these minimum vs. preferred qualifications and uses them pretty consistently in its job descriptions. It’s tempting to think that all the skills you think you need are must-haves, so it’s helpful to list out all the skills and push yourself to prioritize them.

I believe that you should always hire people who are looking to ‘punch above their weight class,’ which means to hire people who want to be one league above where they are today.Mark Suster, Managing Partner, Upfront Ventures*

Generalist vs. Specialist Candidates

You need a balance between hiring an expert in the area and a great athlete who is flexible and can adapt to your domain.Vinod Khosla, founder, Khosla Ventures*

Typical wisdom says that earlier-stage startups (where teams are small and the nature of the work is ambiguous and variable) tend to hire generalists, while larger companies tend to need specialists. But there’s more to it than that. A small startup in a heavily technical space (like autonomous vehicles) may need specialists from the outset. Some large companies, like Google, try to hire as many smart generalists as possible because they’re better suited to handle the dynamic, changing conditions of the tech industry. Jonathan Rosenberg, former SVP of products at Google, refers to them as “learning animals.”

Of course, it’s not an either-or choice for each role. Indeed, the ideal skill set for many roles is a T-shaped skill set, with both depth in one area and a degree of breadth. For example, a backend engineer working on a critical analytics system may need depth in databases and quantitative skills as well as some basic proficiency in fullstack web engineering.

It’s useful to think about what level of flexibility and specialization your team and company need. Will your team’s needs—and the role—evolve over time? Do you value the ability to move people between roles and teams over time? Depending on your answers and your current needs, you might value generalists or specialists, but ultimately any company ends up with a mix of both.

startupIn addition to preferring to hire generalists at early-stage startups, Dharmesh Shah, founder and CTO at HubSpot, advocates for hiring for talent versus specific skills: “The best people are problem solvers and like to build elegant solutions and are not hung up on specific languages or technologies.”*

Considering “Step-up” Candidates

If you directly map a role’s required responsibilities into skills, you might end up trying to hire people who have performed that exact same role before. That might make sense since they’ve proven they can succeed in that role, and assessing their skills might be easier and more direct. In fact, they may have learned vital lessons doing this task before and may be able to perform even better the second (or third) time around. It sounds like a safe bet, but it might not always be the best approach.

When hiring it is tempting to employ someone who has done it before. You actually don’t want that person. You want someone who is about to do it. After all, if they’ve done it before, why would they do it again? Either they’re not ambitious, not growth-oriented, or weren’t that good in their previous role. No matter which it is, you don’t want ’em.Andy Dunn, co-founder, Bonobos*

No one wants to hire someone who’s clearly under-qualified. But the up-and-comer who wants a “stretch challenge” has something to prove. And in some cases, they might be ready for the role but just haven’t been promoted into it for various reasons—for instance, maybe their old employer doesn’t have room to promote them as long as their boss is around.

You should still be aware that this is a risky strategy. Make sure your stance on taking such risks with external candidates is consistent with your internal processes. If your internal promotion strategy is to only promote people to a new role after they have shown that they can perform it, but you’re taking risks on outsiders, your team will likely feel frustrated.

Common Engineering Roles by Skill


Which of the needs you and your team identified can be grouped together into a set of tasks and attributes that can be accomplished by a single person while keeping that person excited and fulfilled by their work? For example, can you actually make do with one fullstack engineer, or will you need both a frontend and a backend engineer? While the role you ultimately describe may not fit neatly into one of these categories—and the ideal person may not have a rigid or even focused area of expertise or experience—it’s helpful to know what are considered common engineering roles.

Desired Nontechnical Skills

Nontechnical skills (or soft skills) are cognitive, social, and personal abilities that contribute to an effective work environment but are not always easy to measure. They include communication, situational awareness, emotional intelligence and self-awareness, creativity, persistence, adaptability, teamwork, leadership, and time management.

caution It’s easy to focus primarily on technical skills, especially when engineers are hiring other engineers. In reality, it takes a lot more than technical skills alone to succeed in the modern workplace.

Here are some examples of nontechnical skills to consider when defining roles:

  • Internal communication skills, in meetings or calls, in written form, or as technical documentation. This can include both clarity and timeliness of communication.

  • External communication skills, such as for sales or support, including the ability to be professional with external parties and balance internal and customer needs. This is often essential for sales positions or solutions engineers.

  • Emotional intelligence (also known as EQ), which is largely a person’s ability to identify and manage their own emotions and empathize with others.

  • Teamwork and collaborative skills.

  • Creativity and product skills, such as the ability to reason about product priorities or make specific product choices.

  • Management of multiple responsibilities. Includes managing time well, project management, and structuring of tasks.

  • Persistence, including the discipline to tackle and solve large or complex problems over weeks or months.

  • Ability to learn quickly in an unstructured environment.

  • Ability and interest in mentoring others.

Well-defined nontechnical skills for a role will be:

  • Relevant to the role. To achieve the outcomes you listed for the role, would a new hire need to collaborate a lot with colleagues? Will they be expected to give presentations to the team or to other departments?

  • Compatible with your company’s stage and work style. Is this a high-growth startup that requires employees to be self-motivated? Do people need to learn new things quickly, and hopefully enjoy doing so?

  • Compatible with your company’s values. Do you expect this person to be empathetic to those around them? What does effective communication mean at your company—are directness and decisive action valued? Transparency and consensus?

Desired Traits and Values

In addition to skills, it helps to consider what traits and values could help a candidate succeed in their role. In a startup, you might need people who are highly adaptable to changing circumstances and are able to weather the volatility and ambiguity that come with building an early-stage company; or you might be looking for highly mission-aligned candidates who share your company’s vision.

I always made it a habit of talking to people that I knew de facto were world class, and then asking them specifically: ‘What are the key traits or characteristics that you look for? What are the questions that you ask, and how do you find them? And if you’re looking for the next person that’s as good as you, where is that person working right now?’Ben Silbermann, co-founder and CEO, Pinterest*

Traits are characteristics of a person that describe how they tend to feel, think, and behave, such as patience, adaptability, and being detail-oriented.

Values are fundamental ideas and beliefs that guide a person or organization’s motivations and decisions, such as honesty, transparency, and being helpful.

If your company does not yet have a clear set of values that will help you assess candidates on that dimension, visit Appendix B.

Many engineering leaders have very specific traits and values that they viewed as highly predictive of on-the-job success:*

  • Dave Story, who has built teams at Intuit, Adobe, and Tableau, always tests for “self-motivation,” or the desire and ability to perform well and work hard even without oversight or encouragement.

  • Jean-Denis Greze, head of engineering at Plaid, looks for a focus on impact—the desire and ability to perform even without oversight or encouragement—as a highly prized personality trait.

  • Ozzie Osman, Monarch co-founder and former Head of Product Engineering at Quora,* advocates for finding people who value conscientiousness.

Thoughtful leaders all have something they look for in hires—and it takes experience to know out how to find it. Ozzie Osman shares why he prizes one trait above all others, in “Hiring for Conscientiousness: Why startups should hire conscientiousness people—and how to find them,” on the Holloway blog.

caution Traits and values can be viewed as an extension of nontechnical skills, and many companies combine them into one bucket called “culture fit.” This can introduce dangerous biases that hinder diversity and downgrade your hiring standards.

Instead, we advocate splitting nontechnical skills—which are often more learnable (like communication skills)—from personality traits (like low ego and adaptability) and values (like honesty and transparency), and being very structured about what each quality is and why it matters. That said, the line between nontechnical skills and traits or values is not always clear. Other ways of considering these qualities include the following:

contribute Do you have a great resource to help candidates and companies think about traits, values, and nontechnical skills? Or would you like to write about the topic for Holloway? Let us know!

Mission-Driven Candidates

Hiring: values first, aptitude second, specific skills third.Sam Altman, chairman, Y Combinator*

Veteran venture capitalist John Doerr once said that he prefers to invest in entrepreneurs who are missionaries, not mercenaries. The same can be said for hiring, especially if your company has a strong mission.

Hiring for mission means that you seek out and hire candidates who resonate with and are motivated by the impact your company is working to have. When hiring for mission, you might seek a candidate with passion accompanied by qualities like intrinsic drive and raw intellectual power, and weight skills and experience much less critically. Note that this is stronger than just considering passion for the mission as one hiring criteria—it entails viewing passion for mission as the main hiring criteria. The underlying belief is that if you find someone who is motivated by your mission, is intelligent, and is highly motivated, these things will be better indicators of success in the role than previous experience or meeting a laundry list of hard skills. As Mark Suster suggests, “Choose attitude over aptitude.”*

Desired Experience

When defining a role, it’s crucial to consider its level—that is, what degree of experience and impact you need and expect from a candidate. Are you hiring a junior engineer, where they may require a significant amount of time to ramp up, or should they have enough experience to be able to hit the ground running? How independently can they operate? Are they going to be given well-defined tasks to execute, or will they have to proactively identify problems and break them down into solutions? How much of their role is individual work versus influencing and leading others?

In general, for higher job levels, less guidance is needed to achieve an outcome, and greater impact is expected of candidates. In a more senior candidate, this represents a mix of technical skills, soft skills, and experience or talent in technical leadership or management. Such candidates typically have more overall experience than junior employees, or have been at the company longer. A senior employee may be more involved in high-level planning and directing junior employees in the day-to-day work needed to meet an outcome, deadline, or goal.

GitLab distinguishes between increasing degrees of values alignment, technical competencies, and leadership competencies across their seniority levels, which they present in a career matrix. As an engineer progresses through levels of experience, they are expected to take on more capacity in each of those three domains. In particular, as the engineer’s level of seniority increases, they must handle a higher degree of ambiguity along with a greater scope of responsibility (The discussion on levels in the next section goes into further detail). GitLab captures this succinctly: “The most senior engineers may even be in a position where they know that something is wrong, but they are not exactly sure what it is—and they work to define the problem.”

When writing a role or job description, some translate skills or seniority into strict experience requirements, designating minimum amounts of time that candidates must have spent working on particular types of problems. For example, the requirement could be that a candidate should have “at least five years of experience developing Android applications.” After all, if someone has spent five years developing Android applications, a company can have some confidence that they have skill and interest in that area—enough confidence, at least, to interview and assess them.

confusionSeniority in a candidate is difficult to specify quantitatively. Concrete durations of experience, such as “five years in a systems engineering role” may be used, but durations are widely acknowledged to be poor and highly approximate proxies for actual seniority.

Aligning on the Role

Your team will most likely be involved in the interview process, they may bring in referral candidates, and they will be working with the new hire day in and day out. The team is a resource for defining and refining the role, at any stage.

The process of defining a role may end up being iterative. A hiring manager may have an initial set of criteria, but as you share them with your team, and as you test them out in practice, it’s best to incorporate what you learn back into your criteria. For instance, maybe a certain set of skills is rare and extremely difficult to find; or maybe that set doesn’t really correlate with what you discover you need to hire for. Listening to your team along the way will help you iterate.

Candidate Personas

Some teams fail to fill a role for months, only to realize they were all looking for different things or assessing candidates in different ways.

Finding agreement on certain questions at the role-defining stage will help your team avoid such situations. These may include:

  • Which of these skills are must-haves, and which are nice-to-haves?

  • Do candidates like this actually exist?

  • If so, how do we find and identify them?

  • Would they really want to join our company?

  • Do they have the skills and values needed to thrive in the role?

  • How do we assess each of these skills and values?

Creating candidate personas can help the team align on each of these.

A well-crafted candidate persona puts you in the shoes of your ideal candidate.Krysta Williams, Marketing Content Specialist, ZoomInfo*

A candidate persona is a description of the ideal candidate for a role. Preparing a candidate persona can help the team agree on the types of candidates to look for and how to identify and attract them (especially at the top of the funnel).

Like marketing personas, candidate personas are fictitious archetypes that represent the candidates that might go through your funnel. With a candidate persona in place, your team has a physical document that you can look at together to check for inconsistencies.

To create a representation of your candidate, here are a few areas to think through (if you haven’t already):

  • Background. What sort of work would an ideal candidate have done in the past and why? What kind of companies might they have worked for, and what roles would they have held?

  • Skills. What skills and experience might they have? Which ones would they list more prominently on their resume or profile and why?

  • Employment. Where might they work right now? An obvious place might be at your direct competitors, but you can get creative. Do you have any functional competitors (companies that employ people with transferable skills/interests)?

  • Job-search behavior. How do they find jobs, or how do employers find them? Would they check job boards? Do they work with recruiters? Do they mainly use their network?

  • Use of time outside work. Are they part of any groups or meetups? Do they spend time on certain sites? Do they contribute to open-source?

  • Long-term career goals. Do they want to specialize in a particular technology? Might they aspire to start their own company?

  • What excites them. Do they want to work on and solve hard problems? Do they want to be part of a company with a positive mission?

  • Decision-making. How else might this candidate make decisions about where to work? What would get them excited, and what would turn them off? Who would they consult with as they were making their decision? What would they research?

It’s important to involve your team, rather than doing this in a vacuum. You can interview top performers on your own team, recruiters, and other hiring managers. You can think back to other people you’ve worked with in your career and consider which of their attributes would make them a good (or bad) fit for your current role. If your team is small, you can use your network and talk to investors, advisors, or managers who have hired for similar roles.

Once you’ve answered these questions and consulted with your team, put what you’ve learned together into a format that is easy to read and use as a reference. You can find structured templates on the internet, but a shared document with a few sentences can be a lightweight method to achieve the same effect. Once you share that document with your team, you can incorporate their feedback to ensure you are all in agreement. If this is your first time doing this, it might be worth getting feedback from more experienced recruiters and engineering managers as well.

In addition to identifying inconsistencies, good personas will help you accomplish a number of essential recruiting tasks that we’ll cover later in this Guide:

  • Craft a role narrative that captures the imagination of your ideal candidate.

  • Select the types of candidates to screen for at the top of the funnel. Based on the personas, what attributes might a candidate exhibit in their application?

  • Identify the channels and messaging to use when reaching out to candidates. Where might you find candidates who are passive, and how can you best get their attention? How might you ensure that active candidates are able to find you, especially at the opportune time?

  • Be prepared to tailor your story and value proposition for each candidate, especially in the first conversation.

danger Personas, if taken too literally, can be overly restrictive and even lead to discriminatory hiring practices. Here are some pitfalls to avoid:

  • Over-generalized assumptions. For instance, a persona for a candidate for an early-stage startup might specify that they thrive under the pressures and urgency they encounter on the job. You might not typically find such candidates at larger, slower-paced companies, but there are always exceptions that you might not want to miss out on. People are unique, complex, and constantly evolving.

  • Sticking to your personas too literally. Hiring clones of your personas will create a homogenous team. Another way to avoid this is to have multiple personas per role. For example, let’s say you need to hire an engineer for a data-intensive early-stage startup, and their work will require both “scrappiness” but also the ability to work with large-scale data. For that position, you could hire someone with a startup background who has an interest in working with large-scale data, or you could hire someone who has experience with large-scale data at a large company but is interested in joining a startup (and has, for example, exhibited that through side projects or attendance of meetups). Those might be two different personas for the same position.

  • Discriminatory assumptions. Correlating attributes to personal details (like age, marital status, or gender) is unfair and illegal.

important Remember that personas are simply a tool for you to use. They are representative and illustrative, rather than prescriptive.

Further Reading on Creating Candidate Personas

Defining Unfamiliar Roles

There are things you may be unfamiliar with and therefore cannot appropriately judge. Not only will a knowledgeable person help you find better candidates (and maybe even candidates who can grow from the small five-person early-stage team to the very different manifestation of the same role when the team grows to fifty people…or five hundred), their knowledge may help integrate the new person more efficiently and help you better appreciate the role.Vinod Khosla, founder, Khosla Ventures*

In some cases, you might find it difficult to even begin defining a role if you or your company have never hired for it before. If you’re in that situation, one solution might be finding someone outside of your company (through friends, former colleagues or classmates, or investors) that you believe—and can validate—has been really successful in that role. Assuming you can’t hire that person, you can at least ask them what characteristics they believe make someone successful in this sort of role, and how they would determine whether someone has those characteristics.

Another potential solution is for you or someone on your team to try to act out the role yourself. That is, you can pretend for a day that you’re the person hired for the role in question. This will reveal any false assumptions you made about the role, specific skills needed that you overlooked, and much more. Wade Foster of Zapier suggests that by doing the role yourself, “you’ll also be able to write a more compelling job description and be better able to define how the role relates to the company and its success.”*

When it comes to an all-new position at the company, we like to try to do it first with the people we have so we really understand the work. If you don’t understand the work, it’s really hard to evaluate someone’s abilities.Jason Fried, co-founder and CEO, Basecamp*

important Depending on the role, your background, and the amount of time you have available, testing the role yourself may not always be feasible. But if there is someone on your team who can act out the role and share their insights, the results can be tremendously illuminating. In addition to helping you get clarity on your needs, the experience will allow you to write a more accurate job description and increase your empathy with the candidates and the person who ends up joining the team.

Setting Levels and Titles11 minutes, 29 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). provides a helpful general structure to start thinking about levels.

You’re reading a preview of an online book. Buy it now for lifetime access to expert knowledge, including future updates.
If you found this post worthwhile, please share!