Job description: the document three different processes rely on

A job description sets out what a role exists to do, what the person will be responsible for, and what they need to be able to do it. It is written for recruitment, but it is used long afterwards — to set expectations in the first months, to assess performance, to grade the role for pay, and to explain decisions if they are ever challenged.

Most job descriptions are written for one of those uses and quietly fail the rest. A document assembled to attract applicants tends to list aspirations; a document that has to support a capability discussion two years later needs to state what the job actually requires.

What belongs in a job description

• Purpose: one or two sentences on why the role exists and what it is accountable for.
• Main responsibilities, grouped and specific — what the person does, not what the team does.
• Reporting line, and who reports to them if anyone.
• Essential requirements: what someone genuinely cannot do the job without.
• Desirable requirements, kept short and honestly desirable.
• Working arrangements: location, hours, travel, any physical or scheduling demands.
• How performance will be judged, at least in outline.

The essential-versus-desirable split is the part with legal weight. Requirements that are not genuinely necessary can exclude candidates without justification, and a list where everything is essential is both a discrimination risk and useless as a sifting tool.

Where job descriptions cause problems later

Two patterns recur. The first is the description that no longer matches the job: the role evolved, nobody updated it, and the mismatch surfaces during a performance discussion or a redundancy consultation where accuracy suddenly matters.

The second is the catch-all line — "and any other duties as required" — used as if it permits anything. It does not: a change substantial enough to alter the nature of the job is a contract variation regardless of what the description says, and relying on the clause to impose one is how disputes start.

Write requirements as capabilities rather than as proxies. "Able to analyse and present financial data" describes the job; "degree in finance" describes one route to it, and excludes people who arrived by another. Where a qualification genuinely is required — by law or by a regulator — say so and say why.

Keeping it useful

1. Draft it with the manager and someone doing the work, not from a template alone.
2. Review it when the role changes materially, and at least when it is next recruited for.
3. Keep it separate from the job advert: the advert sells, the description defines.
4. Version it, so the description that applied at a given time can be produced.
5. Reference it in objectives and reviews, so it stays connected to how the job is actually assessed.

Because the same description is reused for hiring, onboarding and assessment, it needs to be one maintained document rather than several near-copies in different folders. Ettex Docs keeps it with its revision history, so the version in force when someone was hired is retrievable when it matters — for example when a performance improvement plan has to be written against what the role actually requires.