The mandate arrived without a job description
Most companies now hold a licence for machine intelligence, a policy page and a training catalogue. Almost none have changed a single job. The evidence is easy to collect: the same approval cycle, the same weekly report, the same manual reconciliation, the same queue of requests waiting for somebody to touch them. The organisation has paid for capacity it is not using and still carries the cost of the work it meant to change.
A workforce handed new machinery without a new design of the work is an employment matter, and it lands on the executive accountable for capability, for performance and for the treatment of employees whose daily practice has just been invalidated.
Why training programmes stall at the third month
Training stalls for a reason unrelated to the quality of the curriculum. Attendees are taught to be faster at a job that will not exist in that form, and the people who designed the training have no route to change the job. Three causes are tangled together and need pulling apart first.
The work was never broken apart
A role is not a list of tasks. It is a bundle of them, mixed with judgement, relationships and calls nobody wrote down. Until somebody separates it, no one can say which part the machine should take and which part should disappear from the role entirely.
Nobody owns the design of the work
The line manager sees the output, the technology team sees the tool, human resources sees the skills record. Design of the work falls between all three, so it happens by accident rather than by default.
The tools landed outside the workflow
Usage data shows the pattern plainly. Adoption concentrates in individual accounts, in writing and summarising, and is almost absent from the systems where transactions actually live.
Redesign is a different intervention from upskilling
Redesign starts from what gets done, not from who does it. Take the work a team performs over a month, name each piece of it, identify the judgement embedded in it, and ask three questions of each: what should be automated, what should stay human, and what should be removed because it existed only to feed the old arrangement.
The detail of how to run that exercise is in moving from job descriptions to a work architecture, and the assignment of work between people and machines is the subject of deciding which tasks need people, AI or both.
Four decisions the CHRO has to own
- What the work actually is. A named register of the pieces of work and the judgement calls inside them, agreed with the people who perform them.
- What the machine should and should not do. A per-task assignment with a recorded reason, so it can be revisited when the risk changes.
- What the organisation must be able to do afterwards. Job families, a gap assessment, and a development plan with a named budget.
- What happens to the people whose work changes. Redeployment routes, retraining commitments, notice and consultation, and the answer you give when asked who is affected.
Affected employees are a stakeholder, not a line item
This is where a transformation either earns legitimacy or loses it. A team that spent years building a craft discovers that two thirds of its daily output has been reassigned to a system, and hears about it in an all-hands. That reaction is predictable, and no tooling repairs it.
The alternative is unglamorous and it works. Bring the affected team in at the point of decomposition, not at announcement. Show them the register, including the parts you expect to remove, and ask which items are wrong and what the machine will get wrong. Where the organisation must consult before restructuring, schedule that time into the plan and honour the commitments made during it.
Ownership has to be redrawn in the same exercise
When a machine begins to produce part of an output, the question of who answers for that output does not go away. It moves. A customer complaint about a drafted reply, an audit question about an assessment, a regulator asking for the reasoning: each lands on a named person. Without a redraw of ownership, that person is accountable for something they did not produce and cannot verify.
Do the redraw alongside the design rather than after deployment. For each piece of work, name the person who owns the outcome, the person who reviews the machine's contribution, and the record showing what was decided. The governance collection sets out the wider control environment this sits inside.
A sequence that can begin on Monday
- Select one function where the manual load is visibly highest and the consequences of error are bounded.
- Get the business owner to agree to the exercise in writing.
- Build the register with the team doing the work and publish it internally.
- Assign every item to a person, a machine, both, or neither, recording the reason.
- Name the owner of every item and publish the escalation route for machine-assisted output.
- Agree the employee commitments before any announcement, and take a baseline with finance.
What the first two quarters should show
A redesign that is working does not announce itself as a headcount change. It shows up as shorter queues, fewer escalations, more exceptions handled rather than forwarded, and a fall in the hours spent on work that no longer appears in the register. It also shows up in the retention of the people whose expertise the new arrangement depends on.
The economic argument for the programme needs the same discipline as any other: a measured baseline, a stated change, and a mechanism for checking both. The design work that runs alongside it is covered by our approach to business and organizational transformation.