Job Analysis: Knowing What You Are Selecting For

You cannot assess for a role you have not described. Most organisations skip this and design an assessment from the job advertisement, which was written from the last job advertisement.

The principles in “Job Analysis: Knowing What You Are Selecting For” become easier to maintain when ownership and time spent are visible. Teams evaluating time management software can use it to coordinate the administrative work around assessment, identify stages that repeatedly expand and plan capacity, while keeping the hiring decision tied to job-relevant evidence instead of raw activity totals.

For an independent benchmark, compare the process with O*NET occupational information; the useful test is whether the local method remains job-related, proportionate and explainable.

What it produces

A list of the tasks that occupy most of the time.

A list of what distinguishes people who do the job well from people who do it adequately.

The constraints: what somebody must be able to do on day one, and what can be learned.

And the evidence you would accept for each. That last column is what turns an analysis into an assessment design.

Doing it in an afternoon

Talk to two or three people who do the job well, separately.

Ask what they actually did last week, in order, with rough proportions of time.

Ask what goes wrong when somebody is struggling in the role, specifically.

Ask what they wish they had known on day one.

Then talk to the manager and note where the accounts differ, which is itself informative.

The critical incident method

Ask for two specific stories: a time somebody handled a situation notably well, and a time somebody handled one badly.

Concrete incidents surface the judgement that matters and that nobody lists when asked abstractly.

Three or four incidents give you most of your structured interview questions.

Separating must-have from nice-to-have

For each requirement, ask: could somebody competent learn this in the first month?

If yes, it is not a selection criterion. It is an onboarding item.

Most requirement lists shrink by half under this question, and the shrinkage is what widens the candidate pool without lowering the bar.

What to write down

Five to eight things the role requires, in plain language.

For each: why it matters, and what evidence would demonstrate it.

One page.

That page is the specification for the assessment and the defence of it if anybody challenges a decision.

Updating it

When the role changes, which is more often than anybody revisits the document.

At minimum, before each hiring round: read it and ask whether it still describes the job.

Roles drift substantially in two years and assessments almost never follow.

What goes wrong without it

Assessment designed from the advertisement, which was aspirational.

Interviewers each assessing their own idea of the role, which produces disagreement that looks like judgement and is actually confusion.

And requirements nobody can justify, which is the position you do not want to be in if a rejected candidate asks.

What to check

Is there a written analysis, or only a job advertisement?

Did anybody who does the job contribute to it?

Does each requirement have a stated reason and a form of evidence?

And has it been read in the last year?

The point

A job analysis takes an afternoon: talk to two or three people who do the job well, ask what they actually did last week, and ask for two critical incidents..

Underlying all of this

Almost everything in this collection reduces to one discipline: write down what the job requires, assess that thing directly, record the evidence, and look at your own outcomes afterwards. None of it requires buying anything, and organisations that do those four things consistently outperform ones running longer processes built from instruments chosen before the requirements were known.