Most job descriptions are written by copying the last one and adding a few lines. The result is a document full of credentials and time served, and very little about the work itself. That is a problem, because the description sets the filter for everything that follows: who applies, who gets screened out, and what interviewers end up asking about. Rewriting it around skills is one of the cheapest improvements available to a hiring team, and it can be done in an afternoon.
Start from the work, not the wish list
Before writing a single requirement, describe what the person will actually do in the first six to twelve months. Name the three or four outcomes the role exists to deliver, in plain language. If a hiring manager cannot articulate those outcomes, the search is not ready to open, and no amount of careful wording will rescue it later.
Once the outcomes are on paper, the skills follow naturally. Each outcome implies a capability the person must already have, and often a couple they can learn on the job. Separating those two groups is the whole exercise. A wish list is what happens when nobody makes that distinction, and it is why so many postings run to fifteen bullet points that no single person satisfies.
Turn every requirement into an observable signal
Take each line of the old description and ask a simple question: how would a candidate show me they have this? If the honest answer is that you would look for a degree or a job title, the requirement is a proxy and not a skill. Replace it with the thing the proxy was standing in for. Instead of asking for a computer science degree, ask for the ability to design and ship a service that other teams depend on. Instead of asking for five years in the industry, ask for experience running a specific process end to end.
Years of experience deserve particular scrutiny. Time is a weak measure of capability, because two people with identical tenure can have wildly different exposure. Where a range is genuinely useful, keep it as guidance rather than a hard gate, and say so in the posting. Candidates read a firm number as a wall, and strong people who are slightly under it usually do not apply at all. The exception is the credential that law or safety actually requires. Clinical licences, professional accounting designations, safety certifications and regulated engineering sign-off belong at the top of the description, stated plainly. Require those, and stop requiring the rest out of habit.
What changes for contract and executive roles
For contract and contingent hiring, the description carries more weight than usual, because the engagement is short and there is no long ramp to absorb a mismatch. Write it as a statement of work rather than a career page: the deliverable, the systems and versions in use, who the person reports into, the duration, and the one or two skills they must already have on day one. Contract professionals read fast and apply fast, and a vague brief is the most common reason a specialist passes over an assignment they were well suited to.
Executive search runs the other way. At senior level the skills that matter are situational rather than technical, so the document should describe the situation: the stage the business is in, the decisions waiting to be made, the team being inherited, and what will count as success in eighteen months. Naming the hard parts openly attracts leaders who have handled that specific challenge, and it filters out the ones drawn only to the title. In both cases the test is the same. Read the description as the candidate would, and check that the right person recognizes their own work in it while the wrong person self-selects out.
Key takeaways
- Define the outcomes the role must deliver before listing any requirement.
- Replace proxies like degrees and years with signals a candidate can demonstrate, keeping only the credentials law or safety requires.
- Contract briefs should read as a statement of work; executive briefs should describe the situation the leader is walking into.