In short
A good technical brief describes the problem the hire will own, the environment they will work in, the bar they must clear, and the trade-offs you will accept. A job description lists requirements; a brief explains which of them are real. The difference decides whether a shortlist is genuinely a shortlist.
Key facts
- Most useful single line
- What this person owns in month one
- Most damaging omission
- The salary range you can actually pay
- Best signal of a real bar
- Two or three named must-haves, not twelve
- Always state
- Location, working pattern and visa position
The six sections of a workable brief
This is the same structure the hiring brief builder on this site walks you through.
Role
Title, level, the problem it exists to solve, and what success looks like in the first quarter.
Company
Stage, funding position, team size, what you build and why an engineer would find it interesting.
Success
What this person will have delivered or changed after six months. If you cannot answer, the role is not ready.
Technical
The stack and the domain, split into what they must already know and what they can learn on the job.
Practical
Salary range, equity, location, working pattern, visa position, interview process and timeline.
Priorities
The trade-offs. Depth or breadth. Domain knowledge or raw engineering. Speed or certainty.
Briefs that stall a search
These are the patterns that produce long searches and thin shortlists.
- A requirements list of twelve technologies with no indication of which three matter.
- No salary range, or a range set from last year's market rather than this one.
- Two different roles fused into one because the budget only allows one hire.
- A senior title attached to a junior scope, or the reverse.
- An interview process nobody has agreed, so it changes mid-search.
- Unstated dealbreakers — onsite days, on-call, security clearance, visa constraints.
Turning requirements into a bar
Sort every requirement into one of three columns before you brief anyone.
| Column | Meaning | How many |
|---|---|---|
| Must have on day one | Search fails without it | Two or three |
| Strongly preferred | Shortens ramp-up, not a filter | Three or four |
| Can learn here | Everything else | As many as you like |
Say what you will trade
Every startup search involves a compromise: salary against seniority, domain knowledge against engineering depth, speed against certainty. The brief that names its compromise up front gets a relevant shortlist quickly.
If the brief is unrealistic for the market or the budget, a good recruiter should tell you at the briefing stage rather than six weeks later. That conversation is more valuable than any candidate list.
Common questions
- Do we have to publish a salary range?
- You do not have to advertise it, but you must tell whoever is searching. Candidates in specialist technical markets are approached constantly and will not go through a process without knowing the range fits.
- How long should a brief be?
- Long enough to answer the six sections honestly — usually one to two pages. Length is not the point; specificity about the bar and the trade-offs is.
- Who should write it?
- The person the hire will report to, with input from whoever owns the budget. If those are different people and they disagree, resolve that before the search starts, not during it.
Turn this into a brief
Answer six short sections and you have a technical hiring brief you can share internally or send straight to us.
Open the hiring brief builderAny 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.