Skip to main content
Startup StaffingSUS

Free framework

The technical hiring playbook

Most difficult technical hires are difficult before anyone starts searching: the role has not been decided, and nobody has agreed what good evidence looks like. This is the framework we use to structure that thinking — outcomes first, evidence second, offer and risk last.

Build the briefArrange a conversation

Built for roles you cannot keyword-search

When the job title does not exist yet and the stack is not the point, a keyword search returns the wrong people confidently.

Thirteen questions, three stages

Define the problem, decide what counts as evidence, then commit to the offer and the risks you are accepting.

Ends in something usable

Seven of the questions map to optional fields in the hiring brief builder, so the thinking becomes a document.

No benchmarks invented

This is a structure for your own judgement. Nothing here supplies market data or tells you what to pay.

What the framework covers

  1. 01Role outcomes
  2. 02Problem and domain context
  3. 03Interfaces with hardware, software, science and product
  4. 04Day one versus learnable
  5. 05Must-have evidence
  6. 06Adjacent acceptable backgrounds
  7. 07Seniority signals
  8. 08Interview evidence
  9. 09Scorecard dimensions
  10. 10Compensation assumptions
  11. 11Location and working model
  12. 12Hiring risks
  13. 13What to give a recruiter

Stage 1

Define the problem

What the hire is actually for, what the work touches, and what genuinely has to be true on day one.

Role outcomes

What will be true in twelve months that is not true today?

Outcomes are the only part of a technical role that stays stable while the stack, the org chart and the roadmap all move. They also give a candidate something to react to, which a list of technologies never does.

How to answer it

  • Name three to five outcomes, each one a change in the product, the system or the team.
  • Write each as a finished state, not an activity: 'the pipeline runs unattended', not 'work on the pipeline'.
  • Say which outcome you would keep if you could only have one.

Watch out for

Outcomes that are really responsibilities. If it could be true on day one with no work done, it is not an outcome.

What you end up with

A short list of outcomes, ranked, that the first six months is judged against.

Capture this in the optional advanced section of the hiring brief builder.

Problem and domain context

What is genuinely hard about this problem, and how much of that is domain-specific?

Technically complex roles are usually hard for a specific reason — scale, physics, safety, latency, regulation, data scarcity, or simply that nobody has built it before. Naming the reason tells you whether you need domain experience or capable engineers who can learn the domain.

How to answer it

  • Describe the hard part in two or three sentences a non-specialist could follow.
  • Say whether the difficulty is the domain, the scale, the constraints, or the ambiguity.
  • Note the parts of the domain someone could pick up in a quarter.

Watch out for

Describing the industry instead of the problem. 'Robotics' is a sector; 'closed-loop control on hardware we are still revising' is a problem.

What you end up with

A plain-English statement of the hard part, and whether it is domain-bound.

Interfaces with hardware, software, science and product

What does this role sit between?

In early-stage deep-tech and complex systems work, most roles are defined by their boundaries: firmware and application, research and production, model and product, mechanical and control. The boundary usually determines who is actually a fit.

How to answer it

  • List the disciplines this person works across weekly.
  • Say who owns each side of the boundary today, and what breaks at it.
  • Note any handover that currently only works because a founder is in the middle of it.

Watch out for

Writing a single-discipline job description for a role that is really a translation job between two disciplines.

What you end up with

A map of the boundaries the role owns, and the people either side of each one.

Day one versus learnable

What must be true on day one, and what can be learned after joining?

This is the single most useful distinction in early-stage technical hiring, and the one that decides whether your pool is large enough to hire from at all. Every requirement moved from day one to learnable widens the pool; every one kept narrows it deliberately.

How to answer it

  • Put each requirement in one of two columns and be honest about which column it belongs in.
  • For anything in the learnable column, name who would teach it and roughly how long it takes.
  • For anything in the day-one column, say what would go wrong in month one without it.

Watch out for

A day-one list longer than three items. That usually means the role has not been decided, or two roles have been merged into one.

What you end up with

Two explicit lists, with a named owner for anything you expect to teach.

Capture this in the optional advanced section of the hiring brief builder.

Stage 2

Decide what counts as evidence

How you will recognise the right person: signals, proof, and the dimensions you will score.

Must-have evidence

What evidence would convince you someone can do the hard part?

'Five years of X' is a proxy, and a weak one for work that is genuinely novel. Evidence is specific: a system they built at a comparable scale, a paper they can defend, a migration they led, a device that shipped.

How to answer it

  • For each day-one requirement, write the evidence that would satisfy it.
  • Say where that evidence would show up: a CV line, a portfolio, a conversation, or a live exercise.
  • Note the evidence you would accept from an adjacent field.

Watch out for

Evidence only a handful of people in the world could produce. If that is genuinely the bar, say so — but plan the search and the timeline around it.

What you end up with

A requirement-to-evidence table you can hand to anyone screening applications.

Capture this in the optional advanced section of the hiring brief builder.

Adjacent acceptable backgrounds

Which other backgrounds solve a similar problem well enough to transfer?

Roles you cannot keyword-search are usually filled by someone from an adjacent field. Deciding which adjacencies you will accept — before the search starts — is what makes those candidates reachable rather than accidental.

How to answer it

  • List three fields where people solve a structurally similar problem.
  • For each, name what transfers and what does not.
  • Say what you would need to see to take an adjacent candidate seriously.

Watch out for

Agreeing to adjacencies in principle and then rejecting every adjacent candidate on the first screen. Write the transfer test down.

What you end up with

Two or three named adjacent backgrounds with an explicit transfer test each.

Capture this in the optional advanced section of the hiring brief builder.

Seniority signals

What does seniority mean in this specific role?

Titles do not travel between companies. In a small team, seniority is usually about judgement under ambiguity and the ability to work without scaffolding — not years, and not headcount managed.

How to answer it

  • Describe a decision this person should be able to make without you.
  • Say whether you need someone who builds, someone who leads, or someone who does both for a while.
  • Note what a level too junior would cost you, and what a level too senior would cost you.

Watch out for

Hiring a title to reassure a board. The level should follow the decisions the role owns.

What you end up with

A definition of the level in terms of decisions, not years or headcount.

Interview evidence

How will each requirement actually be tested?

Most interview processes test the same thing three times and never test the hardest requirement once. Mapping stages to requirements exposes that quickly, and shortens the process at the same time.

How to answer it

  • Put each stage next to the requirements it is responsible for proving.
  • Replace anything that tests general cleverness with something that resembles the real work.
  • Decide the total time you are asking of a candidate, and whether you would spend it.

Watch out for

Take-home exercises that are longer than the work they simulate. In a competitive market, they filter for availability, not ability.

What you end up with

A stage-by-stage process where every day-one requirement is proven exactly once.

Capture this in the optional advanced section of the hiring brief builder.

Scorecard dimensions

What are you scoring, and who scores it?

A short shared scorecard turns 'I liked them' into evidence that different interviewers can compare. Four to six dimensions is usually enough; more than that and people score the same impression repeatedly.

How to answer it

  • Choose four to six dimensions and define what a strong answer looks like for each.
  • Assign each dimension to the stage and the person best placed to judge it.
  • Agree in advance which dimensions you would not compromise on.

Watch out for

Culture scored as similarity. Define it as behaviour you can observe, or leave it off the scorecard.

What you end up with

A named scorecard, agreed before the first interview, used by every interviewer.

Capture this in the optional advanced section of the hiring brief builder.

Stage 3

Commit to the offer and the risks

The package, the working model, the risks you accept, and what a recruiter is given.

Compensation assumptions

What are you assuming about the package, and how firm is it?

Compensation is an assumption until it is tested against the people you actually want. Writing the assumption down — with its flexibility — means a mismatch surfaces in week one rather than at offer stage.

How to answer it

  • State the range you are working to and what it is based on.
  • Say what equity, bonus or other elements are genuinely available.
  • Note what you would do if the market answer comes back above your range.

Watch out for

Treating a range as a fact. It is your own planning assumption; nothing on this site benchmarks it for you.

What you end up with

A stated range, its basis, and a decision about what happens if it is wrong.

Location and working model

Where does the work physically have to happen, and why?

In hardware, lab and complex-systems work the answer is often genuinely constrained. In software it frequently is not, and an unexamined office requirement can remove most of the pool for no delivery benefit.

How to answer it

  • Separate what needs physical presence from what is habit or preference.
  • Say how often presence is needed, and whether that changes after onboarding.
  • Note the countries or regions you can actually employ or contract in.

Watch out for

A hybrid policy nobody has costed in candidate terms. Decide it deliberately, then hold it.

What you end up with

A working model you can defend in an interview, with its real constraints stated.

Hiring risks

What is most likely to go wrong with this hire, and what would you do about it?

Naming the risks early is what lets you design around them — a different sequence, an interim, a contractor, a narrower first scope, or simply accepting a longer search with your eyes open.

How to answer it

  • List the two or three most likely failure modes: pool too small, budget below market, scope too broad, onboarding capacity.
  • For each, write the mitigation you would actually take.
  • Decide the point at which you would change the plan rather than keep searching.

Watch out for

Treating a slow search as a supplier problem when the constraint is the role definition or the range.

What you end up with

A short risk list with mitigations and a review point.

Capture this in the optional advanced section of the hiring brief builder.

What to give a recruiter

What does someone outside your company need in order to search accurately?

A recruiter cannot infer the hard part, the acceptable adjacencies or the real dealbreakers. Giving them the same document you use internally removes a week of guesswork and a lot of irrelevant CVs.

How to answer it

  • Hand over the outcomes, the day-one list, the adjacencies and the evidence table.
  • Name two or three companies whose engineers would find this problem interesting, and say why.
  • Be explicit about what would get someone rejected, so nobody wastes their time.

Watch out for

Sending only a job advert. An advert is written to attract; a brief is written to search.

What you end up with

One document a recruiter can search from, and a named person to ask questions of.

A starting scorecard

Choose four to six of these, define what a strong answer looks like for each, and give every interviewer the same list. The same set is available in the brief builder.

  • Technical depth in the core area
  • Breadth across adjacent areas
  • Shipping and delivery track record
  • Working under ambiguity
  • Systems and trade-off thinking
  • Collaboration across disciplines
  • Explaining technical work to non-specialists
  • Ownership and follow-through
  • Mentoring and raising the bar
  • Commercial and product judgement
  • Speed of learning something new
  • Domain or regulatory knowledge

Where this framework applies

These are the kinds of roles it was written for, described by what makes them hard rather than by sector labels.

Software and platform

Backend, platform and infrastructure roles where the difficulty is scale, reliability or a migration nobody has time to run.

AI, ML and data

Roles that sit between research and production, where the model is only part of the problem and evaluation, data and deployment are the rest.

Cloud, security and infrastructure

Work defined by constraints — cost, compliance, uptime — and by the boundary between engineering and the rest of the business.

Robotics and embedded

Roles across firmware, control and application software, usually while the hardware underneath is still changing.

Complex and safety-related systems

Engineering where documentation, standards and verification are part of the job rather than an afterthought.

Applied science and advanced engineering

Roles where a scientific background is genuinely required, and where the transferable skill is method rather than stack.

Turn this into a brief

The brief builder covers the role, the company, success, requirements, practicalities and priorities — with an optional advanced section for seven of the questions above. It stays in your browser until you decide to send it.

Build your briefArrange a conversation

Related reading

Guides from the resource hub that cover the thinking behind this page. Each one is written by us and reviewed before publication.

Keep reading