Job Specification

Who writes the job specification?

The hiring manager supplies the substance, because they know what the work requires, and the recruiter edits it for realism and assessability. That second pass matters: recruiters see the market and can say when a combination of requirements does not exist at the offered level, or when an essential is really a preference. HR reviews criteria that carry compliance weight, such as qualifications, licensing, or anything that could function as an indirect filter.

How does a specification support a defensible selection decision?

When criteria are written before applications arrive, every subsequent decision has a reference point. Rejections can be recorded against a named requirement, shortlists can be explained, and an audit can trace why one person advanced and another did not. Criteria invented after seeing the pool are the opposite: they are unverifiable, they tend to describe whoever the team already liked, and they leave no defensible record.

What does a skills-first specification look like?

A skills-first version states the capability and the evidence that would satisfy it, rather than the credential presumed to prove it. Instead of naming a degree, it names the analysis a person must be able to perform and how that will be assessed. Formal qualifications remain where the law or a professional body requires them. The effect is a wider pool assessed against a clearer bar, which is why skills-based hiring usually begins by rewriting this document.

What belongs in a job specification and what does not?

A specification lists what a person must be able to demonstrate: technical skills, domain exposure, formal qualifications where they are genuinely required, and the behaviors the role depends on. Each line should be assessable. If a hiring team cannot say how it would test a requirement in a screen or an interview, that requirement is a preference written in the wrong place.

What does not belong is duties, reporting structure, or aspirational wish-lists borrowed from another company's advert. Duties sit in the role definition; the specification exists to state the bar. Mixing the two produces a document that reads well and cannot be used to make a selection decision.

How do you separate essential criteria from desirable ones?

The useful test for an essential criterion is whether a strong performer could do the job without it within a reasonable ramp-up. If the answer is yes, the criterion is desirable. Essentials should be few and defensible, because every essential is a hard filter that reduces the pool before anyone has looked at a person.

Desirable criteria still earn their place: they are what a scorecard uses to rank between people who all clear the bar. Marking them explicitly prevents the common failure where a nice-to-have quietly hardens into a rejection reason during screening because nobody wrote down which list it was on.

How does the specification become screening criteria and scorecards?

The specification is the source document for the rest of selection. Each essential criterion becomes a screening question or a knockout field on the application form, and each criterion that needs judgement becomes an interview scorecard line with a defined rating scale. Done properly, no interviewer is inventing their own bar on the day.

This mapping is also what makes structured interviewing practical. Because every question traces back to a written requirement, feedback is comparable across interviewers and across candidates, and an applicant tracking system can hold the ratings against the requisition rather than in scattered notes.

What are the risks of over-specifying a role?

Over-specification is the most common defect in this document. Long lists of essentials, inflated years-of-experience floors and degree requirements attached to work that does not need one all shrink the pool without improving the hire. They also lengthen time to fill, because the team spends weeks searching for a profile that was never necessary.

There is a fairness dimension too. Requirements that are not genuinely needed for the work can screen out capable people for reasons unrelated to performance, and in several jurisdictions an employer may be asked to justify why a criterion was applied. Writing only what the job demands is both a quality decision and a risk-reduction one.

How often should a specification be revalidated?

The natural checkpoint is each time the role is reopened. Tools change, the team around the role changes, and criteria copied forward from an old opening quietly become inaccurate. A short review with the hiring manager before publishing usually removes one or two requirements that no longer apply.

A second checkpoint is after the hire. Comparing what the specification demanded against what the person actually needed in their first months is the cheapest available feedback on whether the bar was set correctly, and it improves the next version of the document more than any external template will.