Skip to main content

Team planning

A first-ten-hires planning framework for technology startups

A practical framework for planning the first ten hires in a technology startup: constraint mapping, sequencing, interview capacity and cash shape.

In short

Plan the first ten hires as a sequence of constraints removed, not as an org chart filled in. For each proposed role, name the constraint it removes, the evidence that the constraint is real now, who will assess the candidates and what it costs in the month it starts. Roles that cannot answer all four are not ready, whatever the org chart says.

Key facts

Plan by
Constraints removed, in order
Each role needs
Constraint, evidence, assessor, month-one cost
Hardest limit
Interview and onboarding capacity
Deliberately absent
Stage-specific headcount benchmarks

Why we do not publish a stage-by-stage template

There are plenty of "first ten hires by funding stage" lists online. We do not publish one, because the right first ten depends on what you are building, what the founders already do well and where the delivery is genuinely stuck. A hardware company and a B2B SaaS company at the same stage need almost nothing in common.

What does transfer is the method: identify the constraint, prove it is real, decide who can assess for it, and sequence against cash and interview capacity.

The framework

  1. 1. List the constraints, not the roles

    Write the five things currently slowing the business down in plain language — "we cannot ship to enterprise customers without SSO" rather than "we need a backend engineer".

  2. 2. Test whether each constraint is real now

    What evidence exists that it is blocking something this quarter? A constraint that only appears in next year's plan does not justify a hire this quarter.

  3. 3. Ask what else removes it

    Process change, a contractor, a tool, or narrowing scope. If one of those genuinely removes the constraint, the hire can wait.

  4. 4. Translate the survivors into roles

    Write two sentences on what this person will have delivered in six months. If you cannot, the role is not defined enough to search for.

  5. 5. Name the assessor for each role

    Who is credible enough to judge depth? If nobody internally can, arrange a borrowed assessor before opening the role, not after the first shortlist.

  6. 6. Sequence by dependency

    Leaders and multipliers before the people they will lead, onboard or interview.

  7. 7. Cost the sequence month by month

    Fees, salaries, employer costs and equipment on one timeline. Look at the worst month, then adjust the sequence rather than the ambition.

  8. 8. Set review points

    Decide now what would pause hires six to ten: a missed milestone, a funding change, or ramp-up taking longer than planned.

The one-line test for every role in the plan

A role should be able to fill every column before a search starts.

Readiness test for each planned role
ColumnWhat good looks like
Constraint removedA specific thing that is blocked today
Evidence it is realSomething that has actually slipped or been turned down
Six-month successTwo sentences anyone in the team would recognise
AssessorA named person who can judge the depth required
Month-one costFee, salary, employer costs and equipment, in cash
What we do instead if we waitAn honest answer, even if it is "we go slower"

Sequencing patterns that tend to hold

  • Hire the person who removes the bottleneck before the person who scales output.
  • One strong senior hire early often beats two mid-level hires at the same cost.
  • Do not hire a manager before there is a team to manage.
  • Defer specialist roles until the problem they own genuinely exists.
  • Leave a gap between critical hires so onboarding does not collide.

Three companies, the same method, three different sequences

These are illustrations of the framework above, not templates to copy. Each starts from the same four questions and reaches a different first hire, because the binding constraint and the founders' own coverage differ. Read the reasoning, not the roles.

How the same method produces different sequences
The companyWhat is actually bindingWhat the sequence does firstWhy that differs from the obvious plan
B2B SaaS with technical founders. The product works and deals are being started, but larger customers stall in security review.A commercial and assurance constraint, not an engineering-capacity one. Deals are lost to questions nobody can answer with authority, not to a missing feature.The person who can own enterprise readiness end to end — the security questionnaires, the evidence, the buyer conversation — before any additional engineer.The instinct is to add engineers because the founders are engineers and that is the work they can scope. It adds throughput to a pipeline that is not throughput-limited.
Deep-tech or hardware, pre-revenue, founded by specialists in the underlying science.A development cycle measured in build-and-test iterations. No hire compresses it quickly, and the roles that shorten it are scarce and slow to secure.Whoever runs the programme — procurement, suppliers, test scheduling, the critical path — alongside starting the specialist search early, because time-to-hire is part of the constraint rather than a delay before work starts.A software-shaped plan would defer operations until there is something to operate. Here the operational role protects the iteration loop the whole company depends on, and the specialist search cannot be started when the need becomes urgent.
Commercially founded, product built by an agency or a contractor, now selling faster than the build can follow.The assessor gap in step 5. There is nobody internally who can judge technical depth, which blocks not just this hire but every technical hire after it.Solve the assessment problem first — a borrowed assessor, a trusted technical adviser, a paid work sample judged by someone credible — then hire the senior technical owner who becomes the assessor for everyone after them.The obvious plan opens the role and relies on interviews to sort it out. A panel that cannot evaluate depth cannot detect its absence, and the mistake compounds across the next several hires.

Function order is a consequence of the constraint, not a rule: technical, product, commercial and operations each come first in one of these three. The founders' own coverage is an input too — a gap the founders cannot personally assess for is itself a constraint, and usually the one worth removing first.

Interview capacity is the hidden ceiling

A ten-role plan sounds like a funding question and is usually a calendar question. Each open role consumes screening, interviews, debriefs and decisions from the small number of people who also build the product.

Count the panel hours a plan requires per month. If the answer exceeds what the panel can give without delivery suffering, the plan needs resequencing regardless of the budget.

Common questions

How many people should a startup hire in its first year?
There is no defensible general answer, and figures quoted as norms usually come from a specific sample that may not resemble your business. Hire in the order that removes real constraints, at the pace your panel can assess and your runway can absorb.
How many roles should an early hiring plan contain?
Only the ones you can name a reason for. A plan with three well-argued roles is more useful to a board than one with ten aspirational ones.
Should the first hires be generalists or specialists?
Generalists early tend to survive changes of plan better; specialists become necessary once a constraint is genuinely deep and permanent. Map it to your constraint list rather than to a rule.
When should we hire someone to run hiring?
When the founders' time spent on recruitment is measurably displacing product or customer work, and there is a steady flow of roles rather than an occasional one.

Open an editable starting plan

A suggested shape for early hires, loaded into the planner so you can rename, re-time or delete every line and see the recruitment cost of your own version.

Open a suggested first-hires plan

Any percentages or figures shown in this article are illustrative examples used to explain the model. They are not quoted rates, market benchmarks or salary data.