Engineering

Writing a brief that gets you the right shortlist

Writing a brief that gets you the right shortlist

A good brief reads like a sentence you would say out loud. The bad ones read like a job ad.

Published

Ask a hiring manager what they need and you get a good answer in about fifteen seconds. Ask the same person to write it down and it comes back as a job ad: a paragraph about the company, five bullets of requirements, and a line about being a self-starter. Something is lost between the saying and the typing, and it is the part a shortlist needs most.

A brief is not an advertisement. Nobody is being persuaded by it. It is a description of the person you are looking for, written for a reader who takes it literally.

A job ad and a brief are different documents

The job ad is written for candidates. It sells, and it hedges, because it has to appeal to a range of people and because someone in legal has read it. It says "experience with modern backend technologies" when the team means Go.

The brief is written for whatever does the searching, and for the colleague who will argue with the result afterwards. It can be blunt. It can say the thing the ad is not allowed to.

Before:

We are seeking a talented backend engineer to join our growing platform team. The ideal candidate is passionate about scalable systems and thrives in a fast-paced environment.

After:

Senior backend engineer, Go and Postgres. Must have carried an on-call rotation. Payments or billing experience matters more to us than years in the seat.

The second one is shorter and says more. It also gives you something to disagree with, which is the useful part. A brief you can argue with is a brief that can be corrected.

Say it out loud first

The quickest test is a spoken one. Describe the role to a colleague who does not work in your team, then write down what you actually said.

People are precise when they speak and vague when they type, because typing feels official. Spoken briefs also carry the ranking. "Go and Postgres, and honestly the on-call bit is the one I would not move on" tells you what matters most. A list of five bullets gives all five the same weight, and even weighting produces an even, uninteresting shortlist where everybody clears the same bar and nobody stands out for the right reason.

Write down the trade-off, not only the requirements

Every role has one. You will take less depth in one area in exchange for more in another, and nobody reading your brief can guess which way you would go.

Before:

Site lead for our Chicago facility. Requirements: 5+ years management experience, lean manufacturing background, fluent Spanish, engineering degree or similar.

After:

Site lead in Chicago, roughly 60 people across two shifts. The hard part is that the site is mid-turnaround, so we want someone who has run a floor through a change the floor did not want. Spanish is needed day to day. A degree is not needed at all.

Those two briefs return different sets of names. Some of the people in the second set will not have five years of management on paper, and that is the point. You described the job instead of the CV, so the search can find people who have done that job under a different title.

Decide what should not count

Bias controls in Yardstick are set per role, and the brief is where you decide what they are. Written down, they read as the deliberate choices they are, rather than being settled quietly by whoever happens to screen first.

Three things are worth separating when you write them:

  • Attributes that must not weigh on the ranking at all

  • Signals you know are proxies: the university, the name of a previous employer, a gap in a CV

  • Requirements that are genuinely non-negotiable because a regulator says so

A clinical nurse manager brief shows the difference. Registration is a legal requirement and belongs in the brief as one. "Worked at a large teaching hospital" is a proxy for competence, and it is the kind of line that narrows a shortlist without anyone deciding it should.

Expect to rewrite it after the first shortlist

The first brief is a draft. That is not a failure of the brief; it is how the thing works. You read ten names, notice that four of them are wrong in the same way, and now you know something you did not know an hour ago.

This is why every name on a Yardstick shortlist arrives with the case for it written out, and every claim in that case links back to where it came from: the repo, the case study, the reference, the answer given in screening. When a candidate is ranked highly for a reason you did not intend, you can see the sentence responsible. Then you change that sentence in the brief.

A second pass usually sounds like this: "Cut the payments line, it is pulling in fintech people who have never been on call. Keep the on-call requirement and make it explicit that it was production, not best effort." Ten minutes, and the next shortlist is about something closer to the job.

What a good brief actually looks like

Short. Specific about two or three things and quiet about the rest. Honest about the trade-off. Clear about what must not count. Written in the voice you would use with a colleague, not the voice you would use with a candidate.

None of this guarantees anything about who you hire. A person still decides that, and a person still has to do the interview. What a better brief changes is the set of names you are choosing between, and how much of it you can explain when someone asks why.

Planning a rollout like this?

Elin Ahlberg, Sales lead

Planning a rollout like this?

Elin Ahlberg, Sales lead

Start with one open role

Create a free website with Framer, the website builder loved by startups, designers and agencies.