9 December 20257 min read
The quality of the people you get proposed is set largely before anyone is proposed, by the brief you sent. Send two paragraphs asking for a senior full-stack developer and you will receive whoever is currently unallocated, described in the language of your two paragraphs. This is not usually cynicism on the provider's side. It is that you gave them nothing to match against.
A good brief is not longer. It is different in kind from a job description, and it takes about ninety minutes to write once.
A brief is not a job description
A job description is written to attract, so it describes the company, the mission and the perks, and keeps the requirements broad enough not to deter anyone. A brief is written to match, so it describes the work in enough detail that a provider can rule people out.
The test is whether your document would let someone reject a candidate. If every engineer with the right stack on their CV passes, it is a job advert, and it will produce a shortlist assembled by availability.
What to put in
- The first ninety days of work, concretely: the actual tickets or projects, not the mission
- The stack as it really is, including the parts you are embarrassed about and the version numbers you are behind on
- Who they work with day to day, who reviews their output, and who unblocks them
- What they decide alone and what needs sign-off, because that is what seniority means in practice
- The overlap hours you need and what happens inside them: stand-up, pairing, review turnaround
- How you will judge whether this worked at ninety days
The last one changes the conversation more than any other line. Providers who read it either propose someone plausible against it or start negotiating the definition, and both reactions are informative.
Say what is bad about your setup
Everyone omits this and it is the highest-value paragraph in the document. No tests on the payments module. A deployment process that takes forty minutes and sometimes fails. A front end that two people rewrote halfway. An undocumented service nobody wants to touch.
Writing this down does two things. It lets a provider propose someone who has survived that before, which is a real distinction between candidates. And it prevents the version of the story where a strong hire arrives, discovers the reality in week two, and quietly decides they were mis-sold, which is one of the more common causes of an early departure.
Describe seniority as behaviour
Years of experience is the weakest possible specification and the one everyone uses. Describe instead what the person must be able to do without help: take a vague request from a non-technical stakeholder and turn it into a plan, or work through an unfamiliar third-party integration alone, or review someone else's work and say no.
This matters more across a border than locally, because the informal support that carries a junior through, the overheard conversation, the quick desk-side question, is exactly what does not survive the distance. A brief that says senior gets you a CV with the word senior on it. A brief that says works unsupervised through an undocumented API gets you a conversation about whether the candidate has done that.
Staff augmentation and managed delivery need different briefs
If you are adding people to your own team, the brief is about the person: the skills, the working hours, the review process they will join, how they fit your existing team's shape.
If you are handing over an outcome, the brief is about the work: the scope, the definition of done, the acceptance criteria, what is explicitly excluded, and who on your side answers questions and how fast. Writing the first when you mean the second is a reliable way to end up managing a team you thought you had delegated, and the disappointment usually gets blamed on the provider.
Keep it as a living document
The brief becomes the onboarding document, then the basis for the ninety-day review, then the starting point for the next role. Keep it in a place both sides can read, update it when the work changes, and refer to it explicitly when something is drifting out of scope.
That is also the practical answer to scope disputes. Arguments about whether something was included are unwinnable from memory and short when there is a document, and the version you wrote before anyone was hired is the least self-serving one either side will produce.