The quality of a shortlist is mostly decided before anyone starts searching. A clear brief lets a recruiter find and screen the right people quickly. A vague one produces either a long list of loosely matching CVs or a short list of the wrong people, and a second round of searching that costs another week.
A contract brief is not the same as a permanent job advert. It is written for the people doing the search and the screen, and it needs to answer different questions. This is what we ask hiring managers to settle, and how to write it down.
Start with the work, not the title
Job titles mean different things at different companies. "Senior engineer" or "business analyst" tells a recruiter very little on its own. Begin instead with a plain description of the work:
- What will this person own? A service, a workstream, a test suite, a set of integrations.
- What will they deliver by the end of the term? Be as concrete as you can.
- What does the first month look like? This is often the most revealing question, because it forces a picture of the actual work.
A sentence such as "Take over the payments integration from a departing contractor, stabilise the error handling and hand it to the permanent team by month four" tells a recruiter more than a page of responsibilities.
Separate essential skills from nice-to-haves
This is where most briefs go wrong. A list of fifteen required technologies usually means three that matter and twelve that someone added. Every extra requirement shrinks the pool, and a screen that tests all fifteen will reject strong candidates for the wrong reasons.
Split the skills into two short lists:
| Essential | Nice to have |
|---|---|
| Without this, the person cannot do the work in the first month | Helpful, but could be learned on the job or is rarely used |
| Tested in the technical screen | Noted if present, not screened for |
| Usually three to five items | As many as you like |
A useful test for each essential item: would you reject an otherwise excellent candidate who lacked it? If not, it belongs on the other list.
Describe the team and the environment
Contractors join existing teams, and the fit matters as much as the skills. Include:
- Team size and shape. Who they will work with day to day, and who they report to.
- How the team works. Methodology, release cadence, how code review or sign-off happens.
- The state of the system. A new build and a ten-year-old platform attract different people. Be honest about technical debt; the right contractor will not be put off by it.
- Why the role is open. Backfill, new project, extra capacity. It helps candidates judge the assignment.
Settle the practical terms before the search
Nothing wastes more time than a strong shortlist that turns out not to match the practical terms. Agree these before the search starts:
- Engagement model. Contract, contract-to-hire, or part of a project team. If you are unsure, see choosing between the models.
- Term. Initial length and whether an extension is likely.
- Rate band. The range the budget allows. A rate that does not match the skill level is the single most common reason a role goes unfilled.
- Start date. And how firm it is.
- Location and working pattern. Onsite, hybrid or remote, with specifics, and the working hours, especially across time zones.
- Work authorisation. Any requirements, stated plainly.
- Checks. Background, security or industry-specific checks the role requires, since these affect the start date.
Define how you will decide
Tell the recruiter how the client-side process will run:
- Who interviews, and in what format. Number of stages, and whether there is a technical task.
- How quickly you can give feedback. Strong contractors are often talking to more than one client. A shortlist that waits a week for feedback often loses its best candidate.
- What would make you say yes. In one or two sentences.
Common mistakes
- Copying the permanent job description. It is written to attract applicants, not to guide a search, and usually lacks the practical terms.
- Inflating seniority. Asking for a principal-level person for work a mid-level contractor could do raises the rate and shrinks the pool.
- Leaving the rate open. "Depends on the candidate" makes it impossible to screen for fit.
- Hidden requirements. A preference that only appears at the interview, such as a specific industry background, should be in the brief.
- Too many decision-makers. A brief signed off by one person and interviewed by four with different ideas of the role produces rejections nobody can explain.
A simple template
- Summary. Two or three sentences on the work and why it matters.
- What they will own and deliver. Including the first month.
- Essential skills. Three to five.
- Nice-to-have skills.
- Team and environment.
- Terms. Model, term, rate band, start date, location, hours, authorisation, checks.
- Process. Interview stages, feedback turnaround, what a yes looks like.
It rarely runs to more than a page and a half.
How we use it
We start every search with a role briefing call of about thirty minutes, and turn it into a written brief for the hiring manager to sign off before we search. The essential skills become the basis of the technical screen, which is run by someone who does the work. The shortlist, usually three candidates, comes back with written notes against the same brief, so the hiring manager can see exactly why each person was sent.
If you have a contract role to fill, send us the details and we will set up the briefing.