The fear is real, but it's rarely about the tool This week, a former Anthropic researcher told the BBC that AI staff are "genuinely frightened" for humanity's future. The company's own boss is calling for development to slow down. These are people who build the technology for a living. So when someone on your team goes quiet during a software demo, or asks pointed questions about "what this means for my role", they're not being difficult. They're paying attention. I've watched this play out dozens of times. A business owner gets excited about a new system. They see the time savings, the cleaner processes, the potential. They roll it out. And then they're baffled when the team drags their feet, finds workarounds, or just never quite gets around to using it properly. The problem is almost never that people can't learn the tool. The problem is what the tool represents. Three fears dressed as one When I sit down with teams who are resisting new systems, the conversation usually lands on one of three things. First: fear of looking incompetent. Someone who has been doing a job well for years suddenly has to learn something new, in front of colleagues, possibly in front of people they manage. That's uncomfortable. Most people would rather stick with a clunky process they know than risk failing publicly at a better one. Second: fear of being replaced. This one is getting louder. When you introduce automation or AI tools, people hear "we need fewer of you". Sometimes that's true. Often it isn't. But if you haven't said which it is, they'll assume the worst. Third: fear of change they didn't choose. People can handle a lot when they've had a say in it. Impose something from above with no consultation and you get resistance even to things that would genuinely help them. These fears are rational. They're based on real experience. Treating them as irrational or obstructive makes the problem worse. What I've seen work Last year I worked with a team of eight in east London. The owner wanted to move everything onto a new project management system. He'd done his research, picked a good tool, built out templates. He was ready. The team was not. Three weeks in, half of them were still using the old spreadsheets. The other half were using the new system so inconsistently that it was creating more confusion, not less. We paused the rollout. I asked each person, separately, what was actually going on. One said she didn't understand why the old system was a problem. One said he felt like his years of experience were being dismissed. One said she was worried the tool would show how much time she spent on certain tasks, and that felt like surveillance. None of these concerns were about the software. All of them were about trust, autonomy, and respect. Here's what we changed. The owner went back to the team and explained, specifically, what problem he was trying to solve. Not "we need to be more efficient" but "I'm losing track of project status and it's causing me to miss things, which makes everyone's job harder". That's a concrete problem. People can get behind solving a concrete problem. Then he asked who wanted to be involved in configuring the tool. Two people volunteered. They spent a few hours setting it up in a way that made sense for how the team actually worked. When it rolled out again, those two became the go-to people for questions. Adoption went from 50% to 90% within a fortnight. The 72-hour rule I've started recommending something I call the 72-hour rule. Before you announce any new tool to your team, wait 72 hours and write down answers to these questions: What specific problem does this solve, in terms the team will recognise? Who on the team will this affect most, and have you talked to them first? What happens to the time or tasks this tool is meant to save? Does it go back to the person, or does it get filled with more work? If you can't answer these clearly, you're not ready to roll it out. You might have the right tool. But you haven't built the ground for it to land on. When the fear is warranted Sometimes the fear is correct. Sometimes the tool really does mean fewer jobs. Sometimes the business is changing in ways that will affect people's roles. If that's the case, say so. Clearly and early. I know that feels risky. You might lose people before you're ready. But the alternative is worse. People sense when something is off. They talk to each other. Uncertainty breeds rumour, and rumour breeds paralysis. One client I worked with through alira.london last spring was honest with her team: "This system will reduce the admin load by about 40%. That means we'll need fewer hours on admin. I want to use that time to expand what we offer, which means different work, not less work. But I can't promise that'll work out. I'll know more in three months." She lost one person. The rest stayed, worked through the transition, and the expansion happened. She told me later that the honesty was the only reason it worked. What to do this week Pick one tool you've introduced in the past year that isn't being used consistently. Ask two people who should be using it why they're not. Don't defend the tool. Just listen. Write down the specific problem the tool was meant to solve. If you can't do it in one sentence, you have your answer. If you're planning a new system, run it through the 72-hour rule before you announce anything. The questions are simple. The answers will tell you whether you're ready.