The document that stopped matching the job
Read a set of job descriptions from a company that has deployed machine intelligence into its operations, and the odd thing is not that the technology is mentioned. It is that nothing in the document has changed. The same activities, the same competencies, the same lines about responsibility and none about who actually does the work. A recruiter cannot tell which candidate profile is needed, and the person it describes cannot understand what is expected once half the output is generated rather than typed.
This is not a documentation failure. It is a structural one. A job description records a stable relationship between a person, a set of duties and a reporting line, and machine participation dissolves it. Human resources functions are asked to run a workforce transition while holding the only instrument the discipline has produced.
Five layers replace one document
A workable replacement is not a longer job description. It is a small set of layers, each answering a question the old document could not, and each owned by a different party.
| Layer | The question it answers | Who maintains it |
|---|---|---|
| Activity | What is actually done, in what order, how often. | The team performing the work. |
| Decision | Which choices are made, on what basis, under which policy. | The process owner. |
| Accountability | Who answers for the outcome, and who reviews the machine's contribution. | The accountable executive. |
| Competency | What a person must be able to do to perform the remaining work. | Human resources with the line. |
| Allocation | Which activities are performed by a person, a machine, both, or neither. | Joint, reviewed on a cycle. |
The layers matter in order. The activity inventory is the evidence, the decision layer identifies the judgement, the accountability layer fixes ownership, the competency layer follows from what is left, and the allocation layer changes most often. Built in a different order, they produce an architecture that reads well and allocates nothing.
Decisions are the layer that is usually missing
Ask a team what they do and you will get activities. Ask what they decide and you get something more useful, because a decision has an owner, a policy, a threshold and a consequence. A decision can be delegated to a machine only when the policy behind it is written down, the inputs are available, and the consequence of being wrong is bounded. A decision left implicit in a person's experience cannot be handed over.
This layer matters commercially because decisions are where the value of the human role concentrates once routine production is automated. The capability profile of a role follows from which decisions remain, and the development plan follows from that.
Accountability cannot be left in the description
The temptation is to keep the accountability language as it is and let the allocation be an operational detail. That produces the situation where an output is largely machine-generated, the description still says the person is responsible for it, and nobody can say who would have caught the error. Accountability has to be attached to the activity rather than to the title, and it has to name a person, because a system cannot be made accountable to a regulator, a customer or a court.
Competency follows the redesign rather than preceding it
Most capability frameworks are written as lists of skills, assessed against a scale, and refreshed annually. They work reasonably well when the work is stable. Once activities are reallocated, they drift out of date, and nobody sees the drift because the framework measures the presence of a skill rather than the work.
Two changes make the framework track reality. Assess against the activity inventory: what can this person do today that the redesigned role still requires, and where is the gap. Then build the human path into the role itself — escalation, exception, review of machine output — so that development is not a separate programme competing for the same hours. Measuring that shift is the subject of measuring workforce impact beyond headcount.
A sequence for building it in one function
- Pick a function with high volume, visible manual work and a clear process owner, and secure that owner's agreement.
- Build the activity inventory with the team, working from a real period rather than from memory, recording frequency and time per activity.
- Extract the decisions, write the policy behind each one, and mark the ones with no written policy.
- Allocate each activity to a person, a machine, both or neither, recording the reason, and name the accountable owner.
- Rebuild the competency profile from the remaining activities and compare it with the current population.
- Publish the architecture in a form that recruiting, line management and workforce planning read from.
This is a smaller exercise than it sounds: one function, one quarter, one team, and a document that tells the organisation what its people are for and what the machines are for — a distinction most organisations have never written down.
The consequences for hiring and progression
Once the architecture exists, three ordinary people problems become much easier. Hiring starts to select for the remaining decisions rather than for a list of activities that will be automated within a year. Internal mobility stops being an exception negotiated case by case, because the activity inventory shows which activities a person already performs and which they would need to learn. Grading stops depending on a title, because the accountability layer shows what the role is answerable for.
None of this requires new technology. It requires a decision about how the organisation describes itself, and a willingness to publish the answer. The engineering consequences of the allocation are covered in enterprise agent engineering, and the wider case for treating work design as an operating-model question rather than a tooling one is set out in the CHRO's new mandate.