Before the Tool

The previous six pieces in this series looked at AI from inside one person. Part 1 asked what makes someone distinctive once the technical layer is handled. Part 2 covered why polymaths struggle in organisations built on labels. Part 3 offered a method for finding the abilities you don’t notice in yourself, and Part 4 looked at how a wound becomes a form of perception. Part 5 dealt with walking a path nobody has mapped, and Part 6 with what we tell the next generation. This piece goes back to the company, because that is where most people will meet these questions first.

The link between the two levels is older than AI. Change management has long distinguished the change itself, which happens on a date, from the transition people go through, which happens inside them and takes longer. AI makes that transition harder than usual.

In most change programmes people move toward a defined end state, such as a new process or a new system. Here the end state for the person is open, because they have to work out what they are for once the tool takes over part of what they did.

Most AI rollouts ignore that and follow the familiar order: choose the tool, train the staff, measure adoption. I have seen where that order leads. In my BI consulting years, trainees stopped using the software once the training ended, and projects failed for organisational reasons while the technology worked as specified.

When a team’s technical tasks are automated, the people who did them lose what made them valuable. If nobody helps them find a new definition, they protect the old one.

They keep work manual, slow the rollout, or quietly avoid the tool. Resistance of this kind is rarely about the technology. It is a rational response to a threat nobody named.

For a COO, or whoever is running the change, that calls for a different sequence, with the people work placed before the rollout.

1. Map what each role is about to lose. For every role in scope, list the tasks AI will absorb, then ask the harder question: what did this role’s value depend on? An analyst whose reputation rests on producing reports quickly loses more than a task when the reports produce themselves. Write the answer down, because it tells you where the resistance will come from.
2. Run the discovery work as a team. The method from the third piece works inside a team, and colleagues are the best outside witnesses you have. In one session, each person lists what colleagues regularly ask them for. The colleagues then add what they see that person do that they themselves would find hard. Expect to learn things about your team that no performance review captured.
3. Rebuild roles around people before redrawing the org chart. Once you know what comes naturally to each person, combine it with what the tools now handle. Some roles will merge. Some people will turn out to be polymaths your job descriptions never allowed for. Treat new role descriptions as provisional for the first year, because nobody can see the final shape yet.
4. Keep friction for juniors. If AI takes all the entry-level work, newcomers never build the judgment your seniors rely on, and in a few years you have nobody to promote. Decide deliberately which tasks juniors still do by hand, and explain why.
5. Make the path visible. Ask each person or team to keep a short weekly log of what they attempted with AI, what worked and what did not. Review it for the attempts, not the output. The log shows you where new value is forming in the company. It also gives people evidence of their own progress at a moment when their old markers are disappearing.

There are two things to avoid. Do not announce efficiency gains in headcount terms before the redefinition work has happened. People who expect to be replaced hide what they know, which is the opposite of what you need from them. And do not hand this work to the tool vendor. A vendor’s training teaches the product. It cannot tell your people what they are now for, and the vendor is paid on adoption metrics, which can climb while the organisation stalls.

None of this is a proven playbook, and I would be wary of anyone selling one. It is the order I would follow, based on where I have seen rollouts break.

The question a leader has to answer turns out to be the same one each person faces in this series: once the technical work is handled, what are your people for?