In short
A brief for a complex role has to explain the system, not list the stack. Describe what the thing does, what is hard about it, what the person will own in the first six months, the three or four capabilities that are genuinely non-negotiable, and what you would trade to get them. Everything else belongs in the "nice to have" column where it cannot quietly shrink your market.
Key facts
- Lead with
- The system and what is hard about it
- Must-haves
- Three or four, each with a reason
- State the trade
- What you would give up to get the must-haves
- Avoid
- Stack lists standing in for capability
Complex roles fail at the brief, not the search
When a hard technical search stalls, the cause is usually a brief that describes an ideal person rather than a real problem. Long requirement lists feel rigorous, but each additional must-have removes candidates without adding information.
The brief that works reads like a technical problem statement with a person attached to it.
Six sections that make a complex brief usable
1. The system
What it does, roughly how it is built, its scale or physical constraints, and where it is going next. A specialist decides whether to take the call on this section alone.
2. What is actually hard
Latency, safety, regulatory constraints, physics, data volume, legacy migration, uptime. Name it. This is the part strong candidates want to hear about.
3. Six-month ownership
What this person will have delivered or be accountable for by month six, in terms your existing team would recognise.
4. Genuine must-haves
Three or four capabilities, each with the reason it is non-negotiable. If you cannot give the reason, it is not a must-have.
5. Deliberate trade-offs
State what you would flex: domain background, seniority, language or framework experience, location. This is what makes a hard search solvable.
6. Practicalities
Salary range you would genuinely pay and the currency it is quoted in, location and working pattern, interview stages, who the assessor is and the decision timeline.
Rewriting requirements as capabilities
Illustrative rewrites, not a template to copy — the point is the shift from proxy to evidence.
| Common requirement line | What it should say |
|---|---|
| 5+ years of Rust | Has shipped and maintained production systems in a memory-safe systems language |
| PhD required | Can read current research in the field and turn it into something that ships — a PhD is one route to that, not the only one |
| Startup experience essential | Comfortable owning a problem end to end with no dedicated QA, platform or support function |
| Strong communicator | Can explain a technical trade-off to a non-technical stakeholder who has to fund it |
| Expert in our exact toolchain | Has solved this class of problem before; will need roughly a month to learn our tools |
Questions that expose a weak brief
Ask these of your own draft before sending it to anyone.
- If two people met every must-have, what would still make us choose one over the other?
- Which requirement would we drop first if the search took three months?
- Who exactly is assessing the deepest technical requirement, and are they available?
- What would a strong candidate find interesting here that our competitors cannot offer?
- Is the salary range one we would actually pay for someone meeting every must-have?
- Have we described a person, or a problem?
Common questions
- How long should a technical hiring brief be?
- Long enough to explain the system and the trade-offs, which is usually one to two pages. Length is not the problem; unexplained requirement lists are.
- Should we publish a salary range?
- For hard technical roles it usually helps, because specialists with options screen out ranges they cannot work with rather than asking. At minimum, agree a range internally before the search starts.
- What if we genuinely do not know what we need?
- Then the first task is scoping, not searching. Describe the problem and the constraints, and get the shape of the role challenged by someone credible before opening 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.