Skip to content

Job Analysis

Job Analysis is the structured description of what a role actually requires: the decisions it holds, the dependencies it runs through, the outcomes it owns and the behaviour those demand. It is the specification everything downstream is calibrated against, and it is where most selection error originates.

The measure of a sound job analysis is a valid task list, and most of the error in selection sits in that list rather than in the assessment.

Why it matters when the plan changes

Interviews, assessments and scorecards are all applied against a specification; selection is a methodical process, but the method is only ever pointed at whatever specification exists. When the specification describes the role as it was under the previous strategy, every subsequent step is rigorous about the wrong thing, and the rigour makes the answer more convincing rather than more correct. The measure of a sound analysis is a valid task list, not a plausible one.

The tension is that roles change faster than their descriptions. A title survives an operating-model change while what it actually requires is rewritten underneath, and nobody updates the document because nobody owns it. The analysis is cheap to redo and almost never redone at the moment it would matter most, which is immediately after a structural change has rewritten what the role is actually for.

In practice

A role description written before a shift to product lines lists regional relationship management as the core of the job. The role now requires settling trade-offs between a product owner and a market lead. Candidates are assessed carefully against the old list and the appointment is made on a specification that describes a job nobody holds any more.

Evidence

What it cannot tell you

It cannot tell you whether the current strategy is the right one, or predict how a role will change after the next structural shift; it describes what the role requires now, and its accuracy decays the moment the operating model moves again.

How Atlas reads it

Job Analysis is one of the current delivery names and sits in the platform's job profile tooling; Role Map is approved in principle as a future name and is not current. Atlas derives the specification from the plan rather than from the incumbent, which is what makes a role description perishable and tied to a review point rather than standing indefinitely.

Questions

A description of the duty areas, the tasks within them, the decisions the role holds and the dependencies it runs through. The entry for Job analysis on Wikipedia, dated 2026, defines the measure of a sound one as a valid task list rather than a plausible one covering those duty areas.

Because everything downstream is calibrated against it. The Wikipedia entry on Personnel selection, dated 2026, describes selection as a methodical process, and that method is only ever applied to whatever specification exists, so a description of the previous role produces a careful, convincing answer to a question nobody asked.

Whenever the plan changes what it demands, which is far more often than descriptions are updated. An operating-model change rewrites what many roles require while leaving every title intact, and nothing in the process prompts anyone to revisit the document.

The leader who owns the consequence of the role delivering, rather than a function maintaining a library of descriptions. Ownership by a central function keeps the documents tidy and disconnects them from the plan, which is where the drift comes from.

Role Map is approved in principle as a future name and is not current. Renaming touches the platform and the job profile tooling, so the current name remains canonical in delivery and contracts until a rename programme ships with a named owner and a date.