Hiring Your First Engineers

Define the six-month outcome before writing a job description, source through people who have seen the candidate work rather than through job boards, and evaluate with a realistic work sample. The first engineers set the technical culture, so how they explain decisions matters as much as what they build.

Write the outcome, not the role

A job description written from a title produces candidates who match the title. A description written from an outcome produces candidates who can achieve the outcome, and those are frequently different people.

The useful format is one sentence: in six months, this person will have made X true. "Shipped the integration layer so enterprise customers can onboard without engineering involvement" is evaluable. "Senior backend engineer, 5+ years" is not, and it will attract people optimising for a job rather than a problem.

This also gives you the interview. If the outcome is the integration layer, the assessment is about integration work, not about reversing a binary tree.

What actually predicts success at this stage

Pedigree predicts less than most founders expect early on, because the job is largely deciding what the job is. What predicts better is evidence of having operated without structure.

• They shipped something where nobody defined the scope
• They made a consequential call without a manager, and can explain the reasoning
• They built something that outlived their involvement
• They can name a decision they got wrong and what changed as a result

The last one is the strongest single signal and the most often skipped. Early-stage work produces frequent mistakes. Someone who cannot discuss their own will not surface problems while they are still cheap to fix.

The thirty-day question

One question separates candidates more reliably than the rest of an interview loop: what would you do in your first thirty days, given what you know right now?

Strong early-stage candidates produce a specific plan that is wrong in places. They commit to an interpretation with incomplete information, which is exactly the job. Weaker candidates produce a list of questions they would need answered first. That is reasonable behaviour in a structured company and a warning sign in a company with no structure to lean on.

Red flags worth taking seriously

Two patterns are worth more attention than they usually get.

The first is describing past work entirely in terms of what the team did. Collaborative framing is healthy, but if you cannot extract a single decision the candidate personally made across a whole interview, there may not be one.

The second is needing a defined process before starting. Asked how they would approach an ambiguous problem, they describe the process they would want to exist. In a company that has the process, this is competence. In yours, it is a dependency you cannot satisfy.

What a mis-hire actually costs

The direct cost is salary and recruiting, and that is the smallest part.

The real cost is founder attention spent managing a situation instead of building, a hiring bar that everyone hired afterwards calibrates against, and systems left behind that the next person has to unwind before they can start. Six to nine months of lost ground is a realistic estimate at seed stage, which is why moving slowly on the decision and quickly on the process is the right combination.

Common questions

What should I look for in early employees that predicts success?

Evidence of having operated without structure: shipped something where nobody defined the scope, made a call without a manager, built a process that outlived them. Pedigree predicts less at this stage than demonstrated comfort with ambiguity, because the job is largely deciding what the job is.

What red flags should I look for when hiring early employees?

Needing a defined process to start, describing past work entirely in terms of the team rather than their own decisions, and being unable to name something they got wrong. The last one matters most: early-stage work produces frequent mistakes, and someone who cannot discuss theirs will not surface problems early.

How do I know if a candidate is worth the risk?

Ask what they would do in the first thirty days with the information they have now. Strong early candidates produce a specific, wrong-in-places plan. Weak ones produce a list of questions they would ask, which signals they need the structure you do not have.

What's the cost of a bad early hire?

Larger than the salary, because the cost is mostly time and structure rather than money. An early mis-hire consumes founder attention, sets a hiring bar others calibrate against, and often leaves behind systems the next person has to unwind. Assume six to nine months of lost ground on top of the direct cost.

What's the biggest hiring mistake I can make at seed stage?

Hiring someone to define a function you have not run yourself. Bringing in a senior person to own something the founders have never done means nobody can evaluate whether it is going well until it obviously is not, usually two quarters later.

What hiring mistakes do founder-led teams make at seed stage?

Interviewing on affinity rather than evidence, moving too slowly on strong candidates while deliberating, and hiring for the role title rather than the specific outcome. All three come from the same source: no written definition of what the person must accomplish.

How do I hire my first engineer as a founder?

Define the six-month outcome before writing anything else, source through people who have seen the candidate work rather than through job boards, and use a paid or realistic work sample instead of a whiteboard. The first engineer sets the technical culture, so evaluate how they explain decisions as much as what they build.