In the opening piece of this series, my colleague Cheney published a finding from our research that deserves to be sat with rather than skimmed: across 500+ HR (Human Resources) Directors and CFOs (Chief Financial Officers) surveyed between October 2024 and December 2025, roughly 90% report that job descriptions do not reflect the work people actually do. Every sector, seniority level and organisation size surveyed.
“90% of Your People Have a Job Description That Doesn’t Describe Their Job”.
Her conclusion was the right one. Don’t fix the paperwork. A better job description is still a job description, and it will drift out of date again on the same timeline for the same reasons. Move from roles to outcomes, and ask what she called the real question: what outcome is this work actually producing, and who or what is best placed to produce it.
I want to take that question seriously. Because if you do, it doesn’t just change how you write about work. It removes the atomic unit the entire enterprise is built from, and nothing has been agreed to replace it.
The job was never just a document
The reason a 90% error rate matters is that the job description is not administrative filing. It is the atom from which the enterprise compiles itself.
Person maps to job. Job maps to grade. Grade maps to pay. Jobs aggregate into budgets, report to managers, roll up into departments. Performance is assessed against the job. Careers are sequences of jobs. Workforce plans are projections of jobs. Redundancy law operates on jobs. Even the AI (Artificial Intelligence) deployment decisions Cheney’s piece examined are, in most organisations, decisions about jobs: which to automate, which to augment, which to restructure.
When the atom is inaccurate, everything compiled from it inherits the error. That was Cheney’s argument, and it is correct.
But notice what happens when you accept the remedy. If work is designed around outcomes rather than roles, the job stops being the reliable unit of anything. And an enterprise cannot run on a deprecated unit. Something has to take its place in the grading, the budgeting, the planning, and the governance.
The obvious answer, and why it isn’t enough
The obvious candidate is skills, and I want to concede the genuine contribution first. The skills movement broke the fiction that a job title tells you what someone can do. Task-level and skill-level analysis is the reason we can see automation exposure at all; the task-level research this programme draws on depends on exactly that resolution.
But the skills movement still takes human capability as its primary object. The moment you take Cheney’s question at face value, who or what is best placed to produce the outcome, the unit of work can no longer be defined as a human attribute. Replacing a taxonomy of jobs with a taxonomy of skills modernises the description while preserving the assumption underneath it: that the producer of work is an employee.
That assumption was stable for most of the industrial employment era. It is precisely the assumption Cheney’s question puts in play.
Capability attached to an outcome
The replacement unit, I’d argue, is capability attached to an outcome: the demonstrated capacity to produce a defined result, specified without reference to who or what produces it.
Specify work at that level and something uncomfortable becomes visible. Any given capability can, in principle, be sourced 4 ways: from a human you employ, from a machine you deploy, from a contract you sign, or from an ecosystem you participate in. Sometimes one of the 4, usually a composition of several.
Which surfaces the question that outcome-based design names but does not answer. An outcome tells you what must be produced. It does not tell you how the capability to produce it should be composed across those 4 sources, and it does not tell you who is authorised to decide.
Nobody owns that decision
The usual framing is that AI helps people work. Human performs, technology enables. That holds for most deployments today.
It stops holding at a specific boundary: when a system interprets information, generates options, decides within bounds, executes and coordinates with other systems to produce output the enterprise sells. At that point it is not enabling capability. It is supplying it.
To see what moves when headcount falls, capability has to be decomposed rather than treated as one object. Our transfer research separates four layers.
- Contractual. Roles, terms, accrued rights. Moves by law. Everyone manages this layer.
- Codified. Process documentation, models, data, tooling, IP. Moves by contract and licence, and increasingly needs no person attached.
- Tacit. Judgement, sequencing, workarounds, what normal looks like on a bad day. Moves only if the individual transfers and stays.
- Relational. Customer trust, regulator familiarity, institutional credibility. Attaches to people and rebuilds slowly or not at all.
Automation moves the centre of gravity from layers 3 and 4 into layer 2. It does not eliminate the human layers, which remain hardest to replace, but it shrinks the headcount they require while the codified layer carries more of the output. That is why people and workforce are ceasing to be synonyms. The workforce becomes a composition: employees, contractors, models, agents, machines and configurations of all of them.Look at how the composition question is actually settled in a large organisation today.
If the answer is “hire someone,” the decision runs through HR and a headcount budget. If it is “automate it,” it runs through technology and a change budget. If it is “contract it out,” it runs through procurement. If it is “partner for it,” it runs through strategy or corporate development. Four routes to the same capability, owned by 4 functions, funded from 4 lines, evaluated on 4 sets of metrics that share no common unit of comparison.
Which means one of the most consequential design decisions in the modern enterprise, the composition of the capability that produces its outcomes, is made nowhere as a single decision. It precipitates, capability by capability, from whichever budget line happens to move first.
A reasonable objection: line managers already make these choices in practice. They do, but usually after the source mix has been constrained by funding and governance decisions taken elsewhere.
Line managers then orchestrate, often brilliantly, across whatever that process delivers: the headcount they have, the agents that were licensed, the contracts that were signed. But there is a line worth drawing precisely here. Orchestration operates on a given set. Composition determines the set. We have become steadily better at the first while leaving the second undesigned.
Where this leaves Cheney’s argument
None of this is a disagreement with the research finding. The map is broken, and outcome-level mapping is the correct first act; Cheney’s “start with one function” advice stands.
But there is a problem with stopping at outcome-based work design: an outcome still tells us what must be achieved, not how the capability to achieve it should be composed, nor who holds the right to compose it. The organisations now redrawing their maps will discover this quickly. The moment the map is accurate, it stops being an HR document and becomes a set of composition decisions with no agreed owner.
So here is the thought I’d leave you with, and it is the reason I think this series matters beyond its immediate practicality.
The problem with the job description may not be that it describes the job badly. The deeper problem may be that we are still describing the enterprise in jobs. Fix the first and you get a better map. Fix the second and you have to redesign the cartography, which is a larger project, and one whose most important question, we will find, is not analytical at all.
More on that in the next piece.Bloor Research surveyed 500+ HR Directors and CFOs across UK financial services, technology, housing, retail and the public sector, October 2024 to December 2025. Findings are reported as what respondents report.
Print Article for this blog Download here