What I got wrong hiring my first engineer, twice

The first one lasted eleven weeks

Eleven weeks, £14,200 in salary and equipment, and about 900 lines of code that survived him. He was, on paper and in person, better than me. Distributed systems background, ex-Amazon, could talk convincingly about consistency models while I was still drawing boxes on a whiteboard. I hired him in nine days from first email to signed contract because I was terrified he would take another offer.

What I got wrong was not his ability. It was that I hired for a company that did not exist yet. We had 40 paying customers, one Postgres box, and a product whose shape changed roughly every ten days. I hired somebody whose entire professional instinct was to make things not change. He wanted a design doc before touching the billing code. He was right, in the abstract. He was wrong for a team of two where the billing code got rewritten twice that quarter because we still did not know what we were charging for.

He left. He was polite about it. The line I remember was: "I don't think you actually want an engineer, I think you want a second you." That was accurate and it took me another eighteen months to understand why it was not a compliment.

The second one lasted two years and nearly broke the product

So I over-corrected. The second time I hired for velocity. Scrappy, fast, shipped a working prototype during the interview, no ceremony, allergic to process. Exactly the person I thought the first hire should have been.

For eight months she was the best hire I have ever made. Feature throughput roughly doubled. Then we crossed about 600 customers and the thing I had optimised for became the thing that hurt. There were no tests worth the name. Deploys were manual. There were three different ways to read a user's subscription state in the codebase and they disagreed with each other in edge cases involving trial extensions, which is how we ended up billing 31 people twice in one March.

None of that was her failure. I asked for speed, and I got speed, and I never once said "stop, we now need something else." A first engineer will faithfully do the job you actually incentivise, which is not the job in the job ad. It is the job you praise in Slack.

The mistake underneath both mistakes

Both times I was hiring a personality type rather than a phase.

The useful frame I eventually stole from a friend who has done this five times: your first engineer is not a permanent appointment, they are a bet on the next 18 months of the company's technical risk. So the first question is not "is this person good" but "what is the thing most likely to kill us technically in the next 18 months."

For the first company it was that we did not know what we were building. The correct hire was somebody comfortable throwing work away. For the second it was that we did know, and the risk had moved to reliability and correctness under load. The correct hire was somebody who cared about invariants. In both cases I hired the person suited to the previous answer.

Hire against the risk you have now, not the risk that just embarrassed you.

What I do differently, concretely

These are the four changes that stuck. They are cheap and I would run all of them again.

Write the eighteen-month technical risk on one page before you write the job ad. Not architecture. Risk. Sentences of the form "if X happens we cannot serve customers" or "if we are wrong about Y we rewrite Z." I keep it to five items. If you cannot write it, you are not ready to hire, you are ready to talk to five customers.

Pay for two days of real work. I pay £1,000 for two days on an actual ticket from the actual backlog, on the actual codebase, with an NDA. Roughly a third of candidates decline, which is fine and informative. What you learn in two days that no interview surfaces: how they behave when the spec is ambiguous, whether they ask before or after building, and whether their commits are legible. I have twice ended a process on day two, and both times the interview panel had loved the person.

Ask the throw-away question. "Tell me about the largest amount of your own work you have deleted, and why." Candidates who have never deleted anything substantial have either never worked somewhere uncertain or cannot let go. Both matter for a first hire. The best answer I ever got was a man who described killing his own six-week feature after watching four user sessions.

State the phase out loud, in writing, in the offer. Mine now reads something like: for the next two quarters we optimise for learning speed over durability; we expect to rewrite the pricing and onboarding surfaces at least once; we will tell you when this changes. Then actually tell them when it changes. I now do that in a scheduled conversation, not by osmosis. In the second company the phase changed and I told nobody, including myself.

The onboarding thing nobody does

One more, smaller, and it has had the best return per hour of anything on this list.

In week one, the new engineer ships something to production on day one or day two. Not a doc. Not a setup ticket. A change a customer could notice. This means you have to have already made that possible, which is the real point — it forces you to fix the deploy path before there is a person waiting on it. At the second company our first-deploy time for a new hire was six days. That is six days of a salaried person learning that shipping here is hard, which is a lesson they will not unlearn.

And in week two, they take a support conversation. Directly, with a real customer, with you watching. Every engineer I have hired since has changed at least one technical priority within a fortnight of doing this. It is the cheapest correction mechanism available and it costs an hour.

What it actually cost

Rough numbers, because I think people are vague about this on purpose. First failed hire: about £22,000 all-in including my time, recruiter fee, and the two months of my own attention I spent managing somebody I had mis-hired. Second hire: no direct cost, she was excellent, but the correctness debt took two engineers roughly five months to unwind and cost about £4,800 in refunds and goodwill credits after the double-billing.

The expensive part was never the salary. It was the eleven months in each case between the moment the mismatch was visible and the moment I acted on it. I could see both coming. I did not want to have the conversation.

Do this today

Open a blank page. Write the five sentences describing what could kill you technically by this time next year. Not what you want to build. What could kill you. Then read your open engineering job ad, if you have one, next to that page and ask whether the ad would attract the person who solves item one.

If you cannot honestly say yes, do not post it yet. Fifteen minutes now is worth eleven weeks later.