How do you hire your first employee at a startup?

Your first hire is one of the highest-leverage decisions you'll make as a founder — and one of the easiest to get wrong by moving too fast. The core principle: hire only when a specific, proven bottleneck is costing you users or revenue, not to signal that you're a 'real' company. Choose someone who will do extraordinary work on the one thing that matters most right now, not someone who fills an org-chart slot.

Don't hire to feel like a startup

There is a powerful temptation in the early stages to hire people because it makes the company feel legitimate — a real office, real employees, real momentum. Paul Graham's observation about young founders is sharp here: many go through the motions of building a company by raising money, renting space, and staffing up, while neglecting the only thing that actually matters — making something people want. Hiring is the most seductive of these motions because it feels productive without requiring you to face the hard truth about whether your product is working.

Every person you add before product-market fit is a financial clock that starts ticking and a coordination cost that slows you down. Two founders who can move in tight, daily feedback loops with their earliest users will almost always outlearn a four-person team where half the time goes to internal communication. Delay the first hire as long as the work genuinely permits. If you find yourself saying 'we need someone to handle X,' ask first whether X actually needs to be done right now, or whether you're just uncomfortable doing it yourself.

Identify the real bottleneck before you write a job description

The right way to think about your first hire is to audit where your time goes over the course of a week and find the single most valuable thing you cannot do because something else is consuming your attention. That constraint — not a vague sense that the team is 'stretched' — is what justifies an offer. If you're a technical founder spending twelve hours a week on customer support tickets, that might be the bottleneck. If you're a non-technical founder and the product is barely functional, an engineer who can own the codebase entirely is the constraint.

Be specific enough that you could write down in one sentence what success looks like for this person in ninety days. 'We ship X, users do Y, and we learn Z.' If you cannot write that sentence, you are not ready to hire. Vague roles attract vague candidates and produce vague outcomes. The job description is a forcing function for your own thinking about what the company actually needs.

Hire for exceptional ability in the one thing, not general competence

Paul Graham has written about the enormous variance between competent people and exceptional ones, particularly in technical fields — the difference is not a matter of degree but of kind. This applies beyond engineering. A first hire who is genuinely world-class at the specific skill you need will have more impact than two or three people who are merely good. At the early stage, you cannot afford averaged-out performance across multiple roles.

This means you should be patient and interview more people than feels comfortable. Most founders hire their first employee too quickly from a small pool — a friend of a friend, someone they liked in a first conversation. Run the process more seriously than you think you need to. Work with candidates on a real problem before you make an offer. Paid trial projects or short contract engagements are entirely normal and reveal things that no interview will. You are not just testing skills; you are testing how someone thinks under uncertainty, how they communicate when they're stuck, and whether their standards for their own work match yours.

On the character side, Paul Graham's point about meanness is directly practical for hiring: people who are unkind, dismissive, or territorial will poison a small team faster than any product problem. In a company of two or three people, one toxic person can end the company. You have more flexibility on experience than you do on character.

The mechanics of actually making the hire

Once you've identified the right person, move quickly. Slow processes lose good candidates, and good candidates are rare. Have your equity and compensation structure thought through before you start conversations — know your option pool, have a standard offer template ready, and understand enough about employee agreements to sign them without a week of legal back-and-forth. You do not need to become an expert in startup legal mechanics ahead of time, but you should not be learning the basics during an active offer negotiation.

Set expectations explicitly on day one. Your first employee will shape every hire after them. Tell them directly what you know, what you don't know, what success looks like this quarter, and how you plan to give feedback. The culture of the company is not a document you write later — it is the sum of how you and your first employee treat each other and the work during the first few months. That behavior becomes the template. Treat this person as a genuine partner in the problem, give them real ownership of their area, and hold weekly one-on-ones where the conversation is honest enough to surface problems before they become crises.

What to look for beyond the resume

The qualities that matter most in a first employee are hard to see on paper. You want someone who is genuinely curious about your users' problem, not just competent at executing tasks. You want someone who will tell you when something is a bad idea, not someone who wants to please you. And you want someone who can operate well in an environment where the process, the tools, and sometimes the strategy will change every few weeks.

The best signal you can get is watching how someone responds when a project doesn't go the way they planned. Do they diagnose the failure honestly and adjust, or do they deflect? Specifically design your trial project to include at least one ambiguous requirement or one unexpected obstacle, and pay attention to that moment more than any other. A first employee who can navigate uncertainty with both confidence and intellectual honesty is one of the most valuable early-stage assets a company can have.

“The next step after rent a cool office and hire a bunch of people is: gradually realize how completely fucked they are.”

— Paul Graham, source

The one thing to do

Before you post a job or reach out to anyone, write one sentence describing exactly what your first employee will accomplish in 90 days — if you can't write it, you're not ready to hire.

Frequently asked questions

When is too early to make your first hire?

If you have not yet talked to at least 20 to 30 real users and seen clear evidence that people will pay for or repeatedly use what you're building, adding headcount almost always creates noise before you have signal. Hire after you have a defined problem for that person to solve, not before.

Should your first hire be a generalist or a specialist?

Identify your single most critical bottleneck first, then hire the best specialist you can find for exactly that constraint. Generalists are valuable later when you need coverage; early on, exceptional focus on one high-leverage area creates more value than broad competence across several.

How much equity should you give your first employee?

Typical early employee equity at seed stage ranges from 0.5% to 2%, varying by role, seniority, market, and how early the person joins. Use a four-year vest with a one-year cliff as the standard structure. Do not make equity decisions under time pressure — know your range before you open conversations.

What is the biggest mistake founders make in their first hire?

Hiring someone they already know and like rather than running a real process to find the best person for the specific role. Familiarity reduces hiring anxiety but often produces a mismatch between what the company needs and what the person is actually exceptional at.

Sources

More playbook answers · Growth Prophet home