How to Hire for a Role You Have Never Hired Before

Define the outcome rather than the requirements, evaluate reasoning rather than answers, and price against the outside option rather than the title. All three substitute for the pattern-matching you would normally rely on and cannot use here, because for an emerging role there is no reliable pattern to match against yet.

This applies to every role in this cluster. Forward deployed engineer, GTM engineer and applied AI engineer are all titles where two companies using the same words mean materially different jobs.

Do not copy another company's version

The instinctive first move is to find a well-known company hiring for the title and adapt their job description. It is also the most reliable way to run a failed search.

A forward deployed engineer at Anthropic and one at a twelve-person startup share a title and little else. One works inside a mature product with a platform team behind them; the other is the platform team. Borrowing the description imports constraints you do not have, and you end up interviewing for a job that does not exist at your company.

Write yours from your own constraint. What is currently blocked, what would unblock it, and what would be observably true in six months if this worked.

Outcomes are checkable, requirements are guesses

For an established role, a requirements list is a reasonable shorthand. Everyone roughly agrees what a senior backend engineer needs. For an emerging role nobody agrees, so the list is either borrowed or invented.

An outcome survives that problem because both sides can evaluate it. "In six months, enterprise customers can be onboarded without core engineering involvement" tells a candidate what the job is and tells you whether they can do it. "Five years of experience with distributed systems" tells neither of you anything about this particular role.

It also produces a better applicant pool. Strong people self-select toward well-defined problems and away from requirement lists that read as generic.

Evaluate reasoning when you cannot evaluate answers

The uncomfortable part of hiring for a role you have not done is that you cannot judge the output directly. That is survivable, because you can judge the reasoning.

Take a real problem from your business, not a puzzle, and ask the candidate to work through it. What do they ask before starting? How do they decompose it? What do they explicitly decide not to do, and why? You do not need to know the correct approach to tell whether someone is reasoning well about your specific constraints, and reasoning quality transfers across the parts of the job you cannot foresee.

The single most useful question remains what they got wrong previously. Genuine experience produces specific failures with specific lessons. People who are early to a title rather than experienced in the work tend to answer at the level of principles, because that is what they have read.

Price against the alternative

Salary surveys lag emerging titles by a year or more, which means the band you derive from them will lose candidates at offer stage after the search has already cost you weeks.

Name the two or three jobs a strong candidate would realistically take instead, and benchmark against those. For most roles in this cluster the alternative is an engineering job, which is why pricing them against the function they sit in produces offers that get declined. This is covered in more detail in what to pay AI-era engineering roles.

The Revenue per Employee Planner covers the step before this one: whether the constraint needs a person at all.

Or borrow the judgment you do not have

Everything above is a way of coping with not having done the job. There is a more direct option that founders routinely overlook: put someone who is doing the job into the process, before the interview loop starts.

A practitioner currently working in the role can read a CV in a way you cannot. They know which of the claimed responsibilities are load-bearing and which are decoration, which tools imply real depth and which appear on every profile, and which combination of experience is common versus genuinely rare. That assessment takes them twenty minutes and would take you two months of pattern-building to approximate.

It is most valuable exactly where it is hardest to arrange: on roles so new that your own team has no reference point. For an established backend role you have internal calibration. For a GTM engineer or a forward deployed engineer you have a title, a salary band, and a guess.

This is the part of our own process worth naming plainly. We put people currently working in the role in front of candidates before you interview them, so the shortlist you see has already been filtered by someone who does the work rather than by someone matching keywords.

Decide honestly between hiring and training

For several of these roles the underlying skill is one you already have in the building. Most applied AI work is software engineering; most GTM engineering is systems and data work. A strong engineer who is curious about the domain closes that gap in months.

Hire externally when you need someone to establish a practice from nothing rather than execute within one. Evaluation discipline, deployment methodology, a repeatable enterprise implementation: those benefit from having been done before, and they are exactly what teams skip when they learn as they go.

Common questions

How do I write a job description for a role that has no standard definition?

Describe the outcome and the first ninety days instead of the requirements. For emerging titles nobody agrees what the requirements are, so a requirements list either copies another company’s interpretation or invents one. An outcome is checkable by both sides.

How do I evaluate candidates when I have never done the job myself?

Evaluate the reasoning rather than the answer. Give a real problem from your business and assess how they decompose it, what they ask, and what they choose not to do. You do not need to know the right answer to tell whether someone is reasoning well about your constraints.

How do I know if a candidate is genuinely experienced in a new field or just early to the title?

Ask what they got wrong and what they would do differently. Genuine experience produces specific failures with specific lessons. People early to a title have usually read more than they have shipped, and their answers stay at the level of principles.

Should I hire a specialist for an emerging role or train someone internally?

Train when the underlying skill is one you already have and the novelty is context: most applied AI work is software engineering, so a strong engineer closes that gap quickly. Hire externally when you need someone to establish a practice from nothing, which is the part teams reliably skip when learning as they go.

How do I benchmark compensation for a role with no salary data?

Price against the outside option. Identify the two or three jobs a strong candidate would realistically take instead and benchmark against those. Survey data lags emerging titles by a year or more and will produce a band that loses candidates at offer stage.

What is the biggest mistake when hiring for a new role?

Copying another company’s version of it. Anthropic’s forward deployed engineer and a twelve-person startup’s are different jobs with the same title. Borrowing the description imports their constraints, and you interview for a role you do not have.

How can I assess a candidate for a role nobody on my team has done?

Bring in someone who currently does it. A practitioner can judge in twenty minutes what would take you months of pattern-building to approximate: which claimed responsibilities are load-bearing, which tools imply real depth, and which combinations of experience are genuinely rare. It is the one shortcut that does not trade away rigour.