The first specialist you hire is the one you're least equipped to judge

The short version:

• Your first hire in any function you don't personally do, sales, finance, marketing, design, is the hardest to judge, because you can't assess the craft directly and fall back on proxies: titles, logos, years of experience. Those proxies are exactly what mislead you.
• Define the job by the problem in front of you, not the org chart you imagine. Founders reach for the senior version of a role ("a VP," "a Head of") when the first need is almost always a builder who can do the work and create the process, not a leader to sit above one.
• Hire for judgment in ambiguity over pedigree. Someone who ran a function inside a mature system may never have built one from nothing, which is the entire job at an early-stage startup. Prioritise trajectory and building over logos.
• When you can't assess the skill yourself, borrow judgment: use real-work simulations, hard backchannel references, and a trusted expert to sit in on the evaluation.

Every founder can confidently hire for the thing they're good at. A technical founder knows a strong engineer when they talk to one. A salesperson-founder can smell a real closer. The trouble starts with the first hire into a function the founder has never done: the first salesperson for the technical founder, the first finance lead, the first marketer, the first designer. This is the hire founders often get wrong, and the reason is structural: you cannot directly judge a craft you don't practise, so you reach for whatever looks like a signal from the outside.

From the outside, the signals are titles, brand-name employers, and years on a résumé. So founders hire the senior title from the impressive logo and assume competence will follow. Sometimes it does. Often the person was excellent inside a big, well-oiled machine and has no idea how to operate without one, which is precisely what your startup is asking them to do.

There's a better way to approach it, and it's the same shape regardless of the function. Define the real job, hire at the right altitude and moment, evaluate for judgment rather than pedigree, and set the person up to build. Here's each in turn.

Define the job by the problem, not the org chart

The first mistake happens before anyone is interviewed: founders describe the role by the title they imagine a "real" company would have, rather than the problem actually in front of them.

Almost every function is a stack of jobs, not one job: a doing layer, a making-it-reliable layer, and a strategy layer. Early on, the layer you're missing is nearly always the bottom of that stack: someone to do the work and build the repeatable process for it, not a leader to manage a team that doesn't exist yet. A "Head of Sales" with no reps to lead is just an expensive first rep who may not want to actually sell. A "Head of Finance" is often overkill for a company that mostly needs its books closed reliably. The senior title feels like progress, but it usually solves a problem you don't have yet while leaving the one you do have untouched.

So write the job description from the symptom. What, concretely, is broken or missing right now? What would this person do in their first ninety days that would obviously matter? If you can't name a set of hands-on deliverables, only a scope of "leadership," you're hiring at the wrong altitude.

Hire at the right moment, not when the title feels overdue

The pressure to make these hires is often social. Investors ask who owns growth, peer startups announce a Head of this or a VP of that, and the absence of the title starts to feel like a gap you're behind on.

Hire the function when the work demands it, not when the org chart looks thin. The honest triggers are concrete and specific to each function: enough inbound demand to need someone selling full-time, enough complexity to need someone owning it, a milestone (a raise, a launch, a new market) that creates real specialist work. "It feels like we should have one by now" isn't a trigger. It's a way to hire too early and too senior, then watch an overqualified person drift or churn. Match the seniority and the timing to the problem, and let the problem set the pace.

Evaluate for judgment when you can't judge the craft

This is the crux, and it deserves the most care, because it's where being outside your expertise hurts most. You can't fully evaluate skill you don't have, so stop pretending the interview is about assessing craft, and make it about assessing judgment, which you can read in any domain.

Start by discounting the proxies you'd otherwise lean on. A big-company logo isn't a signal unless the work behind it maps to your stage. Someone who operated inside an established system, with process and a team already in place, may never have built from zero, and building from zero, under ambiguity, is the job. Prioritise trajectory over tenure and building over maintaining: did they start something, clean up a mess, expand a territory, set up a function where none existed? That analogous experience beats a famous employer every time. 

Then screen for the traits that predict success in ambiguity, because they're legible even to a non-expert. Can they explain why they made a decision, not just what they did? Do they tell specific stories, real names, dates, numbers, rather than vague generalities? Are they comfortable saying "it depends," and can they then tell you what it depends on? Can they translate their specialty into plain language you understand, rather than hiding behind jargon? Specificity and clarity are strong signals of someone who actually did the work and thought about it. Fluent vagueness is a red flag.

And when you're genuinely out of your depth, borrow judgment rather than fake it. Three moves do most of the work. Use a real simulation instead of abstract questions: hand a salesperson a dormant pipeline to triage, a marketer your actual positioning to critique, a finance candidate a messy month to close, because doing the work in context reveals what a conversation can't. Backchannel references hard, going beyond the names offered to former managers and peers, and ask the questions that matter: would you rehire them, did they build or merely maintain, how did they operate when there was no structure? And bring in a trusted expert, an advisor, a board member, a founder who's made this hire, to sit in on a round and calibrate a decision you can't fully make alone.

Set them up to build, not just to arrive

The last step is enablement, and for a first specialist it's specifically about authorising them to build. You aren't hiring this person to slot into a machine. You're hiring them to make the machine. If you drop them into ambiguity with no context and no authority to change things, even a strong hire will fail politely.

Give them real concrete deliverables rather than vague "own the function" language, the context only you can provide about where the company is heading and why, and the explicit authority to fix broken process rather than tiptoe around it. And be honest with yourself that a first specialist hire will need more of your attention than a hire into your own domain, not less, because you'll be learning the function's language alongside them, and that translation is part of the job you can't delegate yet.

One more option worth holding open: sometimes the right first move into a function isn't a full-time hire at all. Fractional or outsourced specialists can carry a function through its early, low-volume phase for far less than a senior salary, and they let you learn what the role actually requires before you commit to it in-house. "Rent the expertise until the work justifies owning it" is often the more disciplined path, especially for functions like finance where the early need is reliability rather than leadership.

How this looks in practice

We see this pattern from one particular seat at Inkle, where we handle accounting, bookkeeping, tax, and compliance for US startups, often for technical, first-time founders. Finance is one of the clearest cases of the first-specialist problem: it's a function most founders have never run, so they tend to over-hire the title (a "CFO") and under-hire the actual need (reliable books and a trustworthy close), and they reach for it either too early or too late. 

For many of the companies we work with, the disciplined answer early on is to rent the function rather than hire it: to have the routine, reliable layers owned by someone else until volume and complexity make a dedicated hire genuinely worth it. It's the same logic that applies to any first specialist hire: get the work reliably done first, learn what the role really requires, and hire into clarity rather than guesswork.

The takeaway

The first person you hire into a function you don't understand is the one you're least equipped to judge, so change what you're judging. Define the job by the problem, not the title. Hire when the work demands it, not when the org chart feels thin. Evaluate for judgment and building rather than logos. And borrow expert judgment when your own runs out. Do that, and your first specialist hire stops being a gamble on a résumé and becomes a deliberate bet on someone who can build the thing you can't build yourself.

Frequently asked questions

How do you hire for a role you don't understand yourself? 

Stop trying to assess the craft directly and assess judgment instead, which is legible in any domain. Define the job by the concrete problem in front of you, then screen for whether the candidate can explain their reasoning, tell specific stories, and translate their specialty into plain language. Borrow expert judgment where yours runs out: use real-work simulations, hard backchannel references, and a trusted advisor to sit in on the evaluation.

Should a startup's first specialist hire be senior or junior? 

Usually a builder rather than a leader. Early on, the missing layer is someone who can do the work and create the repeatable process for it, not an executive to manage a team that doesn't exist yet. A senior title with no team beneath it often solves a problem you don't have while leaving the hands-on work undone. Match seniority to the actual problem, not to what a larger company's org chart would look like.

When should a founder hire their first specialist in a function?

 When the work genuinely demands it, not when the title feels overdue. Look for concrete triggers specific to the function: enough demand to need someone full-time, enough complexity to need a dedicated owner, or a milestone like a raise or launch that creates real specialist work. Hiring for optics tends to produce a hire that's too early and too senior, which leads to drift or churn.

How do you evaluate a candidate outside your area of expertise? 

Discount the proxies you'd otherwise trust, logos, titles, tenure, and prioritise trajectory and evidence of building something from scratch, since that maps to startup reality. Screen for specificity (real names, dates, outcomes) and the ability to explain trade-offs, both of which reveal genuine experience. Then use a role-specific simulation and rigorous backchannel references, and bring in an expert advisor to calibrate the final call.

Is it better to hire a full-time specialist or use a fractional/outsourced one first? 

For many functions, especially early, fractional or outsourced specialists carry the work through its low-volume phase for far less than a full-time senior salary, and they let you learn what the role actually requires before committing. Move the function in-house once the volume, complexity, or need for a dedicated decision-maker makes owning it cheaper than renting it. This is often the more disciplined path for functions like finance, where the early need is reliability rather than leadership.