AI Adoption Is a Management Challenge, Not a Technology Project

*Part 5 of 6 in a series on the habits that make AI useful. Previously: [AI Time Investment: Spend Time on AI Before It Saves You Time](/insights/ai-time-investment-before-it-saves-time/). Next: [AI Rubric: Don't Just Ask AI for an Answer — Ask What Good Looks Like](/insights/ai-rubric-what-good-looks-like/).* Buying AI is now the easy part. A business can have licences for the whole team by Thursday. What that doesn't buy is adoption. There is a large gap between three states that get talked about as if they're the same thing: - AI is available to people - some people occasionally use AI - AI has genuinely changed how the organisation works Almost every SME I meet is somewhere in the first two. Getting to the third is a management problem far more than a technology one, which is inconvenient, because the technology part can be delegated and this part can't. ## Access does not create adoption Rolling out Copilot, ChatGPT or Claude changes what's possible, not what happens. People still need to know: - where AI is actually useful in their role - what they're allowed to use it for - what information they must never put into it - when the output has to be checked, and by whom - how it fits with the process they already follow Without that, the confident ones experiment freely — sometimes with data they shouldn't — and the cautious ones avoid it entirely. You end up with inconsistent practice and no way to tell which is which. ## Start with the work, not the technology The usual opening question is *"where can we use AI?"* It leads to tool-shaped answers. A better one is *"where is work slow, repetitive, expensive or frustrating?"* Then look at the workflows behind those answers: repeated admin, duplicated effort, information bottlenecks, manual research, reporting, document handling, chasing things nobody can find, the same message typed forty times a month. Decide whether AI helps only once you can see the work. Half the time the answer is a better form or a clearer handover, and you've saved yourself a subscription. ## Managers need to understand how the work is actually done AI opportunities hide inside day-to-day detail, and senior leaders often don't have that detail. Not through any failing — it's simply not visible from where they sit. How does that report actually get produced? Who rekeys what between systems? Where do people look when they can't find a document? What happens when an approval is needed and the approver is on holiday? The people doing the work know. Adoption goes badly when management prescribes solutions before asking them, and well when the first move is a conversation. [Process mapping](/insights/process-mapping-strategic-tool/) is a structured way to have it. ## Give people permission to experiment Employees don't experiment when they're worried about: - making a mistake in public - breaching a policy nobody has written down - being seen to waste time - appearing to automate their own job away - using a tool that isn't approved The last one is the quietest and the most damaging. That fear is what pushes AI use onto personal accounts, where you can neither see it nor govern it. The answer isn't a longer policy. It's a short, clear set of boundaries plus an explicit invitation to try things inside them. ## Set expectations people can live with AI is usually introduced with more enthusiasm than it can carry. Leaders expect transformation by Christmas; staff get cynical when the first pilot is mediocre; the initiative quietly dies of embarrassment. Say instead: this improves through experimentation and process change, we expect early wins to be small, and we'll be doing this for a couple of years. Early wins still matter — they build belief — but they should be presented as proof the approach works, not as the return. ## Train on real work Generic AI training gets good feedback and changes very little. People enjoy the session and go back to their inbox. The shift that works is from *"here are twenty things this tool can do"* to *"bring one task you do every week and let's see whether it can be improved."* People leave with something that works on Monday, and — more importantly — with the habit. That's how we run our [workshops](/workshops/), and it's why we ask attendees to bring their own work. ## Governance should enable, not just restrict You do need rules: confidential information, personal data, intellectual property, accuracy, human review, approved tools, high-risk decisions. Get them written down. But the tone determines the outcome. A policy that answers *"how can we use AI safely?"* gets read and used. One that only answers *"how do we stop people doing something stupid?"* gets ignored, and drives usage underground. Our guide on [writing an AI policy your team will actually follow](/insights/writing-an-ai-policy-your-team-will-actually-follow/) covers the practical version — usually two pages, not twenty. ## Find champions, not experts The most useful person in an AI rollout is rarely the most technical. Look for people who understand the organisation and its workflows, enjoy experimenting, share what they learn, help colleagues without being asked, and are honest about where AI is a bad idea. Give them time, a bit of recognition, and a route to raise ideas. Their job is to spread capability, not to become an internal helpdesk — if everything routes through them, you've created a bottleneck rather than a movement. ## Measure work, not usage Adoption metrics that mean nothing: licences bought, logins, prompts written, training attendance. Measures worth having: time saved on named tasks, admin reduced, faster response times, fewer errors, more capacity without more headcount, better customer experience. Usage is not value. A team can be using AI constantly and producing the same work slightly faster, while another team quietly removed an entire weekly process. ## Management sets the ceiling The four habits in this series only spread if the conditions allow it. Curiosity needs permission. Clear thinking needs someone to have mapped the work. Experimentation needs psychological and operational space. The time investment needs a manager who agrees it counts as work. An individual can become excellent at this on their own. An organisation can't. That part is a leadership job, and it's the reason two similar businesses with identical tools end up in completely different places. If you'd like an outside read on where yours stands, that's exactly what the [AI Readiness Assessment](/services/ai-readiness-assessment/) is for. ## FAQs ### Why do AI initiatives often fail after initial enthusiasm? Because the pilot is treated as a technology deployment rather than a change to how work is done. Without process change, protected time, clear boundaries and management follow-through, usage drifts back to habit within a couple of months. ### Should AI adoption be led by IT or the business? The business should lead on where AI is used and what good looks like; IT should own security, data handling, integration and approved tools. Adoption led solely by IT tends to produce well-governed tools nobody uses. ### Who should take responsibility for AI adoption? A named senior owner with authority over process, supported by champions in each team. Shared ownership with no named individual is the most common reason nothing moves. ### How much AI training do employees need? Less general training and more applied sessions. A short grounding in capabilities and risks, then regular hands-on time with their own real tasks. Behaviour changes when people apply it to work they already understand. ### How should businesses manage AI risk? Write down what data can and can't be used, which tools are approved, where human review is mandatory, and who signs off high-risk decisions. Keep it short enough that people read it, and review it a couple of times a year. ### Should employees be given time to experiment with AI? Yes — explicitly and in the diary. Unprotected time gets consumed by operational work, and unofficial experimentation moves to personal accounts where you can't see or govern it. ### What should organisations measure when assessing AI adoption? Business outcomes: time saved on specific tasks, error rates, turnaround times, capacity created and customer experience. Track those against a baseline taken before you start. ### Do businesses need an AI policy before they start? You need basic boundaries before people start putting company information into AI tools, which is likely happening already. A short, practical policy now beats a comprehensive one in six months.

This article was written by Peter Lowe. The ideas and opinions are his own; AI was used to assist with drafting and editing.