Why job descriptions fail before anyone applies

Ask a hiring manager what a role really needs and you get a story. It usually involves a team under pressure, something that keeps slipping, and a specific kind of person who could take it off their plate. Ask for the job description for the same role and you get a list of responsibilities and required skills.

The two documents are describing different things. Only one of them travels through the hiring process.

What a job description is actually good at

Job descriptions do a real job. They set expectations about scope and seniority, they satisfy compliance requirements, and they give a candidate enough to decide whether to apply. None of that is wasted effort.

The trouble starts when the job description becomes the primary reference for everything that follows. Sourcing works from it. Screening filters against it. Interviewers open it the morning of the interview and build their questions from whatever catches their eye. A document written to advertise a role ends up carrying the entire weight of defining it.

Six things the list leaves out

Look at almost any job description for a senior role and the same gaps appear.

The business problem is missing. The document records responsibilities but not why the position exists now, what has gone wrong without it, or what needs to be different in a year. That context is the thing the hiring manager described in conversation and never wrote down.

Everything is weighted equally. Ten bullet points sit in one list with no indication of which two would sink the hire if they were missing. A recruiter reading it has no way to tell a genuine requirement from a preference someone added because it seemed useful.

Success criteria stop at the technical. What the person needs to know is specified. What they need to have achieved by month six usually is not.

It goes stale. Business priorities move. The job description was written once, approved, and then left alone. By the time offers go out it can be describing a version of the role that no longer exists.

Everyone reads it differently. The hiring manager, the recruiter and three interviewers each form their own interpretation of the same document. Nobody notices, because those interpretations are never compared until the debrief, when it is too late to be useful.

Equivalent experience is excluded before anyone applies. A requirement written as a specific technology quietly rules out people who have done the same thing somewhere else under a different name. They are filtered out at the search stage, so nobody ever knows they were rejected.

Ambiguity at the definition stage does not stay at the definition stage. Every later step inherits it and adds its own.

How the cost compounds

None of those gaps is fatal on its own. What makes them expensive is that each stage amplifies the last.

Sourcing turns an unweighted list into search terms, so the search optimises for whatever happened to be written down rather than what matters. Screening turns those search results into a filter, and now the keywords are doing the deciding. Interviewers work from their own reading of the same ambiguous document, which means two candidates get assessed against different criteria at different depths, and the resulting scores cannot honestly be compared.

By the debrief nobody is discussing the business problem any more. They are comparing impressions, and the most confident voice in the room tends to win.

The visible cost is a longer hiring cycle. The real cost is that the team ends up less certain about the decision than they were at the start, and cannot say precisely why.

What to do about it

There is no better template. The fix is an hour of conversation before the search starts, on questions the job description never asks.

Write the problem before the requirements. One paragraph on why this role exists now and what changes once it is filled. Derive the requirements from that paragraph rather than the other way round. If nobody can write the paragraph, the role is not ready to advertise, and discovering that now is cheaper than discovering it after four rounds of interviews.

Name what would actually disqualify someone. Not the wish list. The two or three things that, if missing, mean this person cannot do the job. Everything else is a preference, and preferences need to be labelled as preferences so that a recruiter can tell the difference at four o'clock on a Friday.

Describe the capability, not the tool. "Five years of SAP PM experience" finds people who have used SAP. "Has run a delivery programme across finance and supply chain stakeholders in a business that could not afford to stop trading" finds people who can do the job. The first is far easier to search for, which is exactly why it keeps getting written.

Read it back out loud before sourcing begins. To the hiring manager and the interviewers, in the same room, at the same time. Disagreement at this point costs a conversation. The same disagreement at debrief costs the search.

This is not sophisticated work and it does not take long. It is simply work that happens before the part everyone recognises as hiring, which is why it is the first thing dropped when the requisition is already late.

Where this fits

Understanding the role properly is the first of four stages in how we run a search, and the one everything else depends on. If the definition is wrong, no amount of rigour later recovers it.

Read how the four stages work, or the fuller argument for why hiring loses information at every handoff.