Hiring Strategy for Startups: Who to Hire and When
Build a startup hiring strategy by working backwards from the next milestone. Name what has to be true to reach it, identify the constraint that stops it being true today, and decide for each constraint whether the answer is a hire, an automation, a contractor, or a change in how existing people work. The roles that survive that test, sequenced by which constraint binds first, are the hiring plan. Everything else is a reaction.
This page is about the strategy: which roles, in what order, and why. It is not about how to run any one search, which is covered in the startup hiring framework. The two get confused constantly, and the confusion has a cost: a company with an excellent process and no strategy hires excellent people into roles that should not exist.
Why most startups do not have one
Hiring at most early-stage companies happens through a sequence that looks like this. Someone is overloaded. They ask for help. The founder agrees, because the person is valuable and the overload is real. A job description is written from the overloaded person's current task list. The hire is made, the task list is transferred, and the company has one more person doing work nobody examined.
Repeat that a dozen times and the org chart is a fossil record of who was busiest in each quarter. Nothing about it was decided. The headcount plan in the board deck was reverse-engineered from the requests, not the other way round.
The alternative is not more planning. It is a different starting point: the milestone, not the overload.
Start from the milestone
Every startup has a next milestone that changes what the company needs to be true. A seed company's is usually the evidence that raises an A: a revenue threshold, a retention figure, a number of paying customers of a certain size. A Series A company's is the repeatable motion that raises a B. A Series B company's is the efficient growth the B was priced on.
Write it down as a set of conditions. Not "reach $3M ARR" but "thirty customers paying $100K, with net retention above 110%, sold by someone other than the founder". Each condition points at work that has to happen, and the work points at the constraints.
Name the constraints, not the roles
For each condition, ask what stops it being true today. The answers are constraints, and they are specific: "we cannot onboard a new enterprise customer in under six weeks", "the founder is the only person who can run a technical sales call", "the product breaks at fifty concurrent users". A constraint is not a role. "We need a VP of Sales" is a role wearing a constraint's clothes, and the case where that goes wrong is the most common one we see.
Then, for each constraint, decide what removes it. Four answers are available, and hiring is only one of them.
| Answer | When it is right | Common mistake |
|---|---|---|
| Hire | The work needs judgment, is ongoing, and nobody on the team can do it or be taught it in time | Hiring for volume when the constraint is coordination |
| Automate | The work is repetitive, definable, and currently done by a person who could be doing something else | Hiring a coordinator to run a process that should be a workflow |
| Contract or fractional | The work is real but not permanent, or needs expertise the company will not need at full time for a year | Making a full-time hire for a six-month project |
| Redesign the work | The constraint is how existing people are arranged: handoffs, unclear ownership, a founder holding decisions that are not theirs | Adding headcount to a structure that will absorb it without producing more |
This is the hire, automate, or super IC decision applied across the whole plan rather than to one role. Run every proposed hire through it and the plan usually shrinks. The roles that remain are the ones the milestone actually needs.
Sequence by which constraint binds first
The remaining hires need an order, and the order is not the one in the generic advice. Sequences like "engineers, then sales, then marketing, then operations" describe an average company that does not exist. The right sequence for yours is the order in which the constraints bind: the one that stops progress soonest goes first.
Two rules help. Hire the role that unblocks other roles before the roles it unblocks: a first engineering leader before the three engineers they will need to onboard, a GTM engineer who builds the pipeline system before the account executives who will work it. And hire the role that makes the founder available before the role that assumes they are: if the founder is the constraint on sales, the hire that takes over product, not the hire that adds sales capacity, is what frees them.
The sequence should also respect what the company can absorb. Three senior hires landing in the same month at a twelve-person company will each spend their first quarter competing for the founder's attention. Space them, and put the one with the most dependencies first.
Budget from the sequence, not the other way round
Once the roles and the order exist, the budget follows: which quarter each hire lands, what they cost fully loaded, and what that does to runway. This is the point at which the plan meets reality, and it should. If the sequence does not fit the runway, the answer is to push the last hires past the milestone, not to make the early ones cheaper by hiring junior people into roles that needed senior ones.
It is also the point at which revenue per employee becomes a useful check. If the plan takes the company from twenty people to forty and revenue is expected to double, the ratio holds. If it takes the company to forty and revenue is expected to rise by half, the plan contains hires that will lower it, and each should be able to say why.
Review it against the milestone, not the calendar
A hiring strategy is a bet about constraints, and constraints move. The right time to revisit it is when the milestone changes or a constraint turns out to be different from what was assumed, which in practice means a quarterly look and an immediate one after any surprise. Reviewing it monthly means it was a list, not a strategy; never reviewing it means the fossil record is forming again, one overloaded person at a time.
Common questions
- What is the difference between a hiring strategy and a hiring process?
- A hiring process is how you fill one role: scorecard, sourcing, interviews, offer. A hiring strategy is which roles you fill, in what order, and why, over the next twelve to eighteen months. Most startups have a process and no strategy, which is why hiring happens in response to whoever complained loudest.
- How far ahead should a startup plan its hiring?
- To the next milestone that changes what the company needs to be true, which is usually the next funding round or the next revenue threshold. Twelve to eighteen months is typical. Beyond that the plan is fiction; shorter than two quarters and it is a reaction, not a strategy.
- What order should a startup hire in?
- In the order that removes the constraint on the next milestone, which is different for every company. The generic sequences on the internet, engineers first, then sales, then marketing, then operations, describe an average company that does not exist. Work backwards from the milestone, name the constraint, and the order falls out.
- How many hires should a seed-stage startup plan for?
- Fewer than the plan usually says. Seed-stage hiring plans routinely include roles that turn out to be automation, a contractor, or work a founder should keep for another year. A useful filter is to ask, for each planned role, what happens to the milestone if the hire is delayed six months. If the honest answer is nothing, it is not on the critical path.
- When should the hiring strategy change?
- Whenever the constraint changes. A strategy written before product-market fit is built around finding it. Once found, the constraint moves to delivering and selling, and the roles that mattered before become the roles that are now overstaffed. Reviewing the plan each quarter against the milestone is enough; rewriting it monthly means it was never a plan.
Building the hiring plan for your next milestone?
We pressure-test which roles should exist before any search opens, then run the technical searches that survive the test.
Startup recruiting and workforce architecture