A chief executive I once worked for had every email printed. He scribbled his answers on the printouts and had them typed back. He did not last.
He had a method, and the method was the thing that had to go. He refused to change, so he went. That is the cost of experience when the craft moves: the more you have practised, the more you have to replace, and the skill that matters then is unlearning at work.
On 16 October I argued that you should hire people who learned to deploy a skill, and give your own people time to practise it deliberately. I still agree. It has a limit I left out: deliberate practice builds experts for a craft that holds still.
A ladder with no way down
Apprenticeships run one way: apprentice, journeyman, master. Master is the top rung. Nothing in that design seems to have a step for a master who has to become a beginner again, and the pay, status, and authority all sit with the old craft. Plenty of systems still run on that shape: traditional experience-is-best setups like the civil service, or engineering cultures where the headline requirement is x years of experience doing y. When the method changes, that requirement keeps selecting for the old one.
The most experienced are the people most at risk of falling behind a change in the craft. They have the most to change and the most to forget.
What experts may not see
Attachment is only part of it. Sheridan and Reingold describe chess experts who found a familiar checkmate in five and then missed a shorter checkmate in three. They kept looking at the squares of the familiar solution even though they reported searching for alternatives. A familiar answer can steer an expert’s eyes away from a better one while they believe they are looking. The same pattern runs back to Luchins’s water-jug problems in 1942, as they recount: people who had learned one method kept applying it where a simpler one was available.
I wrote about the emotional side of resistance in Why AI Adoption Really Stalls. This is a different mechanism with a different remedy: someone outside your head has to show you what you are not looking at.
My own restart
Mine was not coding. It was my working day. I had to uproot every bit of it: my habit of writing extensive notes, the time I gave to preparing for meetings, and follow-ups that were never as good as they could be. Letting AI take the notes and handle the information made much better follow-ups possible, and left me time to prepare for the meetings that matter. It took a few serendipitous encounters to realise I was only nibbling at the edges. The setup is in a public starter kit on GitHub.
A video creator shows the same shift in another craft. On How I AI, Brooke Lacey describes how making one video used to take hours of her day, because editors never cut it the way she needed. Her new method, as the episode puts it, has no timeline, no project file, and no editor. The edit is a text file, and she says Claude kept telling her the edit is text.
Designing the way back
I did not do it alone. Colleagues, friends, people in my professional circle, and generous writers of articles and newsletters taught me, which is why I write too. Junior is not an age: I am a junior programmer in my 50s.
As a team-builder I do three things:
- I pair experienced people with people who never learned the old way.
- I ask people to examine what they do and challenge it, in retrospectives and work diaries.
- I run AMA-style sessions across the business, with people outside my teams, where I play the coach.
If you are hiring or promoting, ask not only what someone has practised but what they have had to unlearn. Experience is what lets someone judge the new method, so this is a restart by the experienced, not instead of them. Newcomers lack judgement, which is why the pairing matters. It is also why I think the panic that juniors have no jobs is silly: someone qualified with nothing to defend is exactly who a changing craft needs next to the people who know what good looks like.
Outcomes, not outputs
The tools are not the test. Experienced people can use AI as much as anyone. The test is outcomes, not outputs: has the way the work gets done changed, or only how much of it comes out? Code is one example. Notes, meetings, decisions, and hiring raise the same question.
Who on your team is allowed to be a beginner?
Leave a Reply