Three engineers in six weeks. That was the target my co-founder wrote on the whiteboard the morning we closed our seed round. We hit it in fourteen weeks, burned through an extra $47,000 in contractor fees to cover the gap, and shipped our first enterprise feature a full quarter late. The plan on the whiteboard wasn't a hiring plan. It was a wish.
If you're building a hiring plan for a tech startup, the difference between a wish and a plan comes down to one brutal exercise: deciding who you won't hire, and when you won't hire them. The rest—the job descriptions, the salary bands, the interview loops—is execution detail. Important, but downstream.
I've built hiring plans at three startups across two funding cycles, and I've watched every one of them get revised the moment reality showed up. What follows is the version I wish someone had handed me before that whiteboard.
Key Takeaways
- A hiring plan starts with a revenue or product milestone, never with a role.
- Model hires against runway in months, not against your ambition in quarters.
- Sequence technical roles deliberately—your first five hires set the technical culture permanently.
- Budget 15–20% above base salary for tools, recruiter fees, and ramp time.
- Write the "don't hire" list before the "hire" list. It saves more money than any negotiation.
- Review the plan monthly. A plan that never changes is a plan nobody reads.
How to create a hiring plan for tech startups: start with the milestone, not the role
Most plans I've seen begin with a spreadsheet of job titles. CTO, two backend engineers, a designer, a customer success lead. It feels productive. It's backwards.
The trigger for a hire should always be a business condition, not a feeling of being overwhelmed. A feature that's blocked. A support queue that's breached its response time for three weeks running. A sales pipeline where a single founder can no longer personally run every demo without dropping deals.
Write the trigger sentence
For every role on your list, write one sentence in this shape: "We hire a [role] when [specific measurable condition] happens, and not before."
- "We hire a second backend engineer when API p99 latency exceeds our SLA during business hours for two consecutive weeks."
- "We hire a first salesperson when our founder-led pipeline has closed five deals from the same channel with the same script."
- "We hire a designer when engineering is blocked on design decisions more than two days per sprint."
- We don't hire a head of people until we're past 25 employees. Before that, a founder handles it badly but adequately.
That last one matters as much as the others. Notice how the fourth item doesn't have a metric—it has a hard rule. Those rules are the cheapest part of your plan.
When I built the plan for my second startup, I wrote twelve hire triggers and nine explicit "not yet" rules. Over the following eighteen months, we executed seven of the twelve and broke exactly one of the nine. The broken rule cost us a $140,000 salary for a role that had no defined work for its first four months. That's a real invoice, not a hypothetical.
Model every hire against runway in months
Here's the arithmetic that changed how I plan. A fully-loaded engineer in a mid-cost European or North American market runs roughly 1.3 to 1.4 times their base salary once you add employer taxes, equipment, software seats, and a recruiter fee of 15–20% of first-year salary. So a $130,000 base is really $175,000 in year one. Divided by twelve, that's nearly $15,000 of burn every month, forever—or until that person generates revenue or unblocks someone who does.
The question isn't "can we afford this hire?" It's "how many months of runway does this hire consume, and what has to be true for that trade to be worth it?"
Run that math on a twelve-month runway and it gets uncomfortable fast. A team of eight at an average fully-loaded cost of $150,000 consumes $1.2 million a year in people alone, before cloud bills, tools, or legal. That's most of a seed round. So the plan has to specify not just headcount but the month each hire lands, and the hiring manager has to defend that month against the board.
A staged headcount table you can adapt
Ranges below are what I've seen work across pre-seed to Series A companies; treat them as starting points for your own model, not benchmarks to hit.
| Stage | Typical team size | Sequencing priority | Share of spend on people |
|---|---|---|---|
| Pre-seed | 2–4 people, mostly founders | One generalist engineer who can ship end to end; nothing else until product exists | Very high—60–80% of total spend |
| Seed | 6–12 people | Second and third engineer, first designer (contract first), one go-to-market hire | 50–65% |
| Series A | 15–30 people | Engineering lead, first manager, two-person sales pod, first CS hire | 55–70% |
| Post-A | 30+ | Specialists, people ops, first director-level roles | 60–75% |
Two things surprise founders in this table. First, how few people you actually need at pre-seed to reach a fundable product—most teams over-hire here and use headcount as a proxy for progress. Second, how early go-to-market enters the picture. At seed, one person who can sell is usually worth more than a fourth engineer, and almost no plan I've reviewed reflects that.
Sequence technical roles with intention
Your first five technical hires will define how your company builds software for years. Not metaphorically. Literally—whoever joins first writes the conventions everyone else inherits.
What to hire first, and why
If you're a technical founder, the best second engineer is usually a senior generalist who has shipped something to production before, not a specialist. Specialists are cheaper to justify on paper and more expensive in practice, because in a five-person team everyone touches everything. A distributed-systems expert who can't debug a flaky CSS build will frustrate both of you.
My mistake on the first startup: I hired for depth on a technology we'd picked for a prototype and abandoned within a year. The hire was excellent. The role was obsolete. Twelve months of salary went into a skill set we no longer used, and the person (rightly) left.
Sequence technical hires roughly like this:
- Senior generalist engineer—can architect, ship, and unblock without supervision
- Second engineer with a complementary strength (frontend if the first is backend, or vice versa)
- First designer, initially on contract, converted once the design backlog is stable
- An engineering lead once the team passes five—this is a management hire, not a super-senior engineer
- Specialists (infrastructure, data, security) once the product's shape is stable enough to know what you actually need
That fourth item is where plans usually break. The person who best leads engineers is rarely the person who best writes code, and promoting your strongest engineer into a lead role can lose you a great engineer and gain you a mediocre manager. Plan for that transition deliberately, with training, before it happens.
What does a hiring plan actually cost beyond salaries?
Budget 15–20% above fully-loaded salary in year one for the overhead nobody models: recruiter fees, equipment, licenses, onboarding time, and the productivity dip while a new hire ramps. A senior engineer typically takes two to three months to reach full output; a senior salesperson can take four to six to build a pipeline.
Two line items I overlooked for years:
- Interview cost. Every hour a founder spends interviewing is an hour not spent on the product. At three hundred hours of interviewing across a year, that's real—and it's the reason a structured process beats an unstructured one.
- The cost of the role staying open. An open engineering role that blocks a feature launch for nine weeks is often more expensive than the salary it represents. That's why the trigger sentence matters: it tells you when the vacancy has become a liability.
How do you build a hiring plan investors will trust?
Investors rarely read your plan closely on the first pass. They look for three things: whether the headcount matches the milestones you raised against, whether the total payroll is consistent with the runway you claimed, and whether you know what you'd cut if the round came in smaller.
So show them the version for 100%, 75%, and 50% of the raise. Three columns, one page. That single page signals more operating maturity than any slide of org charts. When I first did this, our lead investor said it was the first hiring plan they'd actually believed—not because it was clever, but because it had a plan B written into it.
How far ahead should a hiring plan go?
Twelve to eighteen months, reviewed monthly. Anything longer than eighteen months at an early-stage company is fiction, and anything shorter can't align with a fundraising cycle. The monthly review matters more than the horizon: it's the ritual that forces you to ask, every time, whether the next trigger has actually fired.
The part that kept me honest
Put a number on every open role and revisit it out loud. Not the salary—the months of runway it consumes. When you say "this hire costs us two months of runway" in a planning meeting, the conversation changes. People stop arguing about whether the role is nice to have and start arguing about what it produces.
The whiteboard in that first office stayed up for months after we hit the target. Someone eventually erased it. What I remember isn't the number. It's that nobody had ever asked what we'd stop doing to afford it—and that question, asked early and monthly, is most of a hiring plan already.
