Hiring the first engineer or the first non-engineer
~8 min read
Why it matters
The first hire sets the standard for everyone after them and spends real runway. Hire too early and you buy a salary instead of learning. Hire the wrong shape — a big-company specialist, or a friend you can’t manage — and you will spend the next quarter managing them instead of users. Hire too late, once you are the bottleneck on a job that clearly repeats, and the company stalls behind your calendar.
If you are the person being hired, the second half of the checklist is the diligence. Joining early is a hiring decision made from the other chair.
Core concepts
- Hire when a job is repeating and only you can do it. Not when you are tired, and not when an investor said “you need a team.” If the repeating job is still “figure out what to build,” that is a cofounder problem, not a hiring problem. See Equity.
- First engineer: a generalist who has shipped, not a résumé. You need someone who can take a fuzzy bug from a user and land a fix in your actual stack, talk to that user, and live with ugly code. Prestige of their last employer is a weak signal. “I want a former staff engineer from a giant company to make us legitimate” is how you get a high salary and a rewrite. Build vs buy already warned you about rewrites.
- First non-engineer: the job you are visibly failing. Often that is sales or support — someone who will run the weekly conversation quota in Distribution — not a “head of marketing” with a brand plan. Title it by the work (founding account person, founding operator), and sit with them the first weeks. Do not throw a quota over the wall.
- Sourcing order: people you have seen work, then their intros, then strangers. The first few hires almost always come from classmates, former teammates, and people those people vouch for. A job post is a supplement, not the strategy. A recruiter this early is usually a way to spend money to avoid asking.
- The interview is a work sample plus a sell. Have them do a small piece of the real job (a bug in your repo, a mock customer email) with you in the room. Separately, tell the truth about runway, the wedge, and how unglamorous the week is. You are selling, and you are screening for people who want this mess.
- Pay is cash plus equity, and cash has to fit runway. Know the months of burn after this salary before you make the offer. Equity for a first hire is meaningful and vested; it is not cofounder-equal unless they are a cofounder. Get the offer in writing from the company. Don’t invent the percent in DMs — use counsel and the option plan.
- If you are joining as that first hire: you are underwriting the founders, not the perk list. You want to see users, a shipping cadence, a number for runway, and a clean answer on your equity. “We’re about to raise” is not runway. See Fundraising map.
What to do next
- Write the job in four lines: the repeating work, what “good in 30 days” looks like, what you will still do yourself, and what you will not ask them to do (usually: be a cofounder without cofounder equity).
- Check runway with the salary included. If the date you hit zero moves inside a semester, do not hire — cut scope or charge more. See Runway.
- Make a list of ten people you have actually worked with. Email five this week. Ask who they would bet on, not “do you know anyone.”
- Run one paid (or clearly scoped) work session before an offer. Debrief the same day: would you trust them with a user?
- Write the offer with a lawyer or your standard equity docs: cash, percent, vesting, start date. Walk them through the cap table in plain language.
- If you are considering an offer yourself: sit in on a user call, read the weekly metrics, and ask what shipped in the last two weeks. Decide from that, not from the vision alone.
Mental model
are you the bottleneck on a job that already repeats?
|
no --> don't hire; find users or a cofounder
|
yes
|
v
someone you've seen do the work
|
v
a real work sample + an honest sell
|
v
offer the company can afford (cash) and explain (equity)
|
v
you still own users and quality for the first month
The first hire amplifies the company’s habits. If the habit is “no users,” you have hired a spectator.
Common failure modes
- Hiring a friend you cannot fire. If you would not give them feedback, don’t give them the seat. Equity and friendship get tangled fast.
- The fantasy senior hire. A famous résumé that needs a process, a team, and a salary you don’t have. You need output in this codebase.
- Abdicating users. The founder disappears into “strategy” the week the hire starts. Early hires should see you do the job, then take pieces of it.
- Joining on vibes. A pitch night is not diligence. If they will not show you a user and a bank-account-based runway, believe that.
Watch
- The Startup Playbook for Hiring Your First Engineers and AEs — David Paffenholz and Harj Taggar, Y Combinator Startup School. Sourcing, outreach, and why early hiring is mostly selling a specific job to a specific person.
- Building an Engineering Team by Ammon Bartram and Harj Taggar — Y Combinator. The funnel, why personal networks dominate the first hires, and how not to run a random interview.
- Lecture 11 - Hiring and Culture, Part 2 (Patrick and John Collison, Ben Silbermann) — YC Root Access. What very early teams optimized for when they hired, from people who did it. Steal the standards, not the headcount.
Further reading
- How to hire your first engineer — Harj Taggar, Y Combinator. The written version of “exhaust your network first.”
- Lecture 2 - Team and Execution (Sam Altman) — YC Root Access. Cofounder and early-team bar, if you are still unsure whether this person is a hire or a founder.