the queue between a question and its answer
self-service analytics never removed the wait for workforce answers, because the slow part was never retrieval.
A CHRO asks a reasonable question in a planning session. Which roles are most exposed to automation over the next three years. The answer arrives as a ranked list of job titles. It looks authoritative. It cannot support the decision it was requested for.
The list fails because exposure does not live in job titles. It lives in tasks. Two people holding the same title, on the same band, in the same function, can carry very different exposure because they spend their weeks differently. Ranking titles averages away the variation that matters most.
This is not a data quality problem that better reporting solves. It is a unit of analysis problem. The job description is the wrong container for most workforce decisions an enterprise now has to make.
what the job description was built to do
Job descriptions serve two masters: hiring and defence. They tell candidates roughly what a role involves. They give compensation teams something to match against survey data. They give legal teams a document to cite when a termination is challenged. They are written once, approved slowly, and reopened rarely.
Those purposes reward a specific style of writing. Descriptions stay broad enough to cover internal variation, vague enough to survive a reorganisation, and stable enough that nobody has to renegotiate them. Every one of those properties makes the document worse as an analytical object.
Deloitte's research on skills-based organisations surveyed 1,246 workers and executives across ten countries. It found that 71 percent of workers already perform some work outside their job descriptions. Only 24 percent said they do the same work as other people holding the identical job title.
That second number deserves a second reading. Three in four workers do not do the same work as their same-titled colleagues. A job title is not a category. It is a label sitting on top of a distribution.
four decisions the container cannot carry
The problem becomes concrete the moment someone tries to use job descriptions for analysis rather than administration.
- workforce planning. You need to know which work will still exist, not which titles will still exist. Titles survive long after their contents have been replaced.
- internal redeployment. Moving a person requires knowing what they can do, at what depth. A description tells you what someone was hired to do, which is a different claim.
- learning investment. Training budgets are allocated by function and level. Capability gaps sit at task level, and they cluster in ways that cut across both.
- automation sequencing. Nothing automates a job. Things automate steps. A sequencing decision made at job level will always be either too aggressive or too timid, because it is averaging across steps with different economics.
Every one of these decisions needs a unit smaller than the job. The job description offers no smaller unit. Its bullet points are not tasks. They are compressed summaries of task groups, written to avoid commitment.
the five layers that replace it
The replacement is not a better document. It is a chain, where each layer has one job and one test it must pass.
- role. The scope a person is accountable for. It answers what this person exists to own. Test: you can name the outcome that fails if nobody holds it.
- responsibility. A durable area of accountability inside the role, usually three to seven of them. It answers how the work is organised. Test: it survives a change of tooling and a change of team structure.
- task. The observable unit of work. It answers what happens on a Tuesday. Test: someone could watch it being done and know it was done.
- KPI. The evidence that a responsibility was discharged. Test: it moves when the work is done well, and stays flat when it is not.
- skill. The capability a task requires, stated at a proficiency level. Test: you can describe what a person at level three does that a person at level two cannot.
The chain matters more than any individual layer. Skills without tasks float free, which is why most skills inventories cannot be used for anything. Tasks without KPIs cannot be prioritised, because nothing tells you which ones carry the outcome. KPIs without responsibilities cannot be assigned, which is how metrics end up owned by everyone and nobody.
the load-bearing test
Here is a procedure you can run against any role you already have documented. For each responsibility, answer three questions in order.
- What evidence would show this was discharged?
- Which tasks produce that evidence?
- What capability, at what depth, does each of those tasks require?
The failures are diagnostic. If you cannot answer the first question, the responsibility is decoration and can be retired without loss. If you cannot answer the second, the responsibility is a goal rather than work, and somebody else's tasks are producing it. If you cannot answer the third, you have a task nobody has thought about staffing, which is where quiet failure accumulates.
Run this against a job description you already have. The bullets that fail question one are common in most enterprises, and they are the ones nobody misses when they are removed.
how to decompose one role in ninety minutes
None of this requires a two-year architecture programme. It requires one role, four people, and a timebox.
- Pick a role with at least twenty incumbents. Variation is the whole point, and you need enough of it to see the shape.
- Invite the manager, two consistently strong performers, and one person who joined in the past six months. The new joiner is there because they still remember what surprised them.
- Spend the first twenty minutes listing tasks only. No responsibilities, no competency language. Ask what happened last week, not what the role involves.
- Group tasks into responsibilities. If you need more than seven groups, two roles are probably wearing one title.
- Attach one KPI per responsibility. Where a responsibility has no measurable evidence, write down why and move on. Do not invent a metric to fill the cell.
- For each task, name the capability required and the depth required. Depth is the harder and more useful half.
- Compare the result against the current job description.
Step seven is the one that changes minds. Two lists come out of it: what appears in the document but never came up in the room, and what came up repeatedly in the room but appears nowhere in the document. The size of the second list is the size of the problem.
three ways this goes wrong
- decomposing everything at once. Organisations start with a full role library and stall around role forty. Start with the roles attached to a live decision, and let the method earn its next tranche.
- writing tasks at the wrong altitude. "Manage stakeholders" is not a task. "Run the monthly steering review and circulate decisions within one working day" is. If a task cannot be observed, it is a responsibility wearing the wrong label.
- letting it freeze. A decomposition with no refresh cadence becomes a job description with more rows. Assign an owner and an interval per layer. Tasks move fastest and deserve a quarterly look. Responsibilities move slowly and can hold for a year.
the honest cost
Decomposition is more work than writing a description, and it stays more work, because a living model has to be maintained. The return is that the four decisions above become answerable rather than arguable. When a business leader asks which roles are exposed, the answer names the tasks, the volumes, and the capabilities involved, and it can be checked.
The alternative is what most enterprises have now: a role library that describes a company that no longer exists, and analysis built on top of it that inherits the error. This is the layer entomo built axon to hold, treating a role as a living profile with its responsibilities, tasks, KPIs and proficiencies attached, rather than a document filed once at hire.
Whether you build that model yourself or buy it, the sequencing point stands. Fix the unit of analysis before you invest in the analysis. Better tooling on the wrong unit produces faster wrong answers, delivered with more confidence.