The organisations getting AI wrong aren’t short of technologists. They’re short of leaders willing to treat AI adoption as a judgement problem rather than a procurement problem — and the judgement part requires no code at all.
You do not need a technical background to lead AI adoption. The decisions that determine whether AI helps or harms an organisation are leadership decisions: which problems to point it at, what level of risk is acceptable, who is accountable for its outputs, and how the people whose work changes are brought along. Start from a business problem rather than a tool, run pilots against a bar set in advance, govern before you scale, and lead the workforce change deliberately.
There is a peculiar abdication happening in senior teams right now. Leaders who would never sign off a new market entry without interrogating the strategy will approve an AI initiative on the strength of a supplier demo, because the technology feels like someone else’s department. It isn’t. Every consequential question in AI adoption — where it should be used, what risk is acceptable, who is accountable when it errs, what happens to the people whose work changes — is a leadership question. The code is the easy part, and someone else really can do that. The judgement cannot be delegated.
The most reliable predictor of a failed AI initiative is that it started with the technology. A team acquires a capability, then goes looking for somewhere to point it. Flip the sequence. List the places where your organisation is slow, inconsistent, expensive or blind — the backlog that never clears, the decisions that vary wildly by who makes them, the information nobody can find. Then ask, narrowly, whether current AI is actually good at that class of problem. Sometimes it is. Often the honest answer is that your problem is a process problem or an accountability problem wearing a technology costume, and automating it would simply produce the same mess faster.
A real pilot has three things most AI pilots lack: a defined decision it exists to inform, success measures agreed before it starts, and a pre-committed willingness to kill it. “Let’s try it and see” is not a pilot; it’s a way of adopting something without ever deciding to. Set the bar in advance — what accuracy, what time saved, what error rate, measured against what baseline — and write down what result would mean stopping. Leaders who do this discover something useful either way: a pilot that clears a pre-set bar earns genuine organisational confidence, and one that fails cheaply has saved you the expensive version of the same failure.
“Let’s try it and see” is not a pilot. It’s a way of adopting something without ever deciding to.
The moment an AI system starts touching customers, citizens or staff decisions, you need answers to questions that no vendor will volunteer: who is accountable for the system’s outputs, what data it may use, how errors are detected and corrected, where a human must stay in the loop, and how you would explain a decision it influenced to the person affected. This is not box-ticking — regulation from the EU AI Act to UK data-protection law is moving this way, but the deeper reason is trust. An organisation that cannot explain its own automated decisions will eventually be asked to, in public, at the worst possible moment.
People do not resist AI because they misunderstand it. They resist it because they understand precisely what unmanaged automation has historically meant for people like them. If the workforce story is an afterthought, quiet non-adoption will kill the initiative more surely than any technical fault: the tool gets rolled out, workarounds bloom, and a year later usage statistics tell the real story. Address the anxiety directly — what changes, what doesn’t, what people will get help learning — and involve the people who do the work in redesigning it. They know where the tool will actually break.
None of the above requires technical depth. It requires the discipline to ask plain questions and decline vague answers — the same discipline good leaders apply everywhere else, applied to a domain that has been allowed to feel exempt. The leaders who navigate this well over the next few years won’t be the ones who learned to code. They’ll be the ones who kept making leadership decisions when everyone around them was mesmerised by the technology.
Leading AI adoption means owning five decisions that no vendor, data scientist or consultant can make for you. First, where to apply it — which organisational problems are genuinely suited to what current AI does well. Second, what risk is acceptable — the tolerance for error, bias and opacity in each use case, which differs enormously between an internal drafting aid and a system that influences decisions about people. Third, who is accountable when the system is wrong, because “the algorithm did it” is not a defensible position to a regulator, a customer or a court. Fourth, how work is redesigned around the tool, since automation rarely slots into an unchanged process. And fifth, how the workforce is led through the change. Every one of those is a leadership judgement. The technical implementation sits underneath them, and it is genuinely the part you can hire for.
Consider a mid-sized services organisation whose leadership approved an AI tool to automate responses to inbound customer queries, impressed by a demo that handled sample questions fluently. Six months later, satisfaction scores had fallen. The tool answered the easy queries — which customers had never struggled with — and confidently mishandled the complex, emotionally charged ones that were the actual source of complaints. Nobody had asked the diagnostic question first: where does our current process actually break, and is AI good at that specific thing? Had they started from the problem, they would have found that their real bottleneck was slow internal escalation, not first-line response — a coordination problem the AI made marginally worse by absorbing the simple cases and leaving the hard ones to a thinner human team. The lesson is not that the technology failed. It is that a tool-first sequence produced a confident, expensive answer to a question the organisation never needed answered.
If you are leading this without a technical background, a workable sequence looks like this. In the first month, resist every impulse to evaluate tools and instead build an honest map of where your organisation is slow, inconsistent, expensive or blind — the problems, ranked by what they cost. In the second month, take the top few and ask, narrowly and with expert input, whether current AI is genuinely strong at that class of task, and what the failure modes would be. Only then, in the third month, commission a small pilot on the single most promising candidate, with a success bar and a stop condition written down before it starts. Throughout, keep the people who do the work in the room, because they know where any tool will actually break. This sequence feels slower than buying a capability and looking for a use, and it is precisely that patience that separates the organisations getting durable value from AI from the ones accumulating expensive disappointments.
No. The decisions that determine whether AI helps or harms an organisation — where to use it, what risk is acceptable, who is accountable, and how the workforce changes — are leadership decisions, not technical ones. Leaders add the most value by asking plain questions and declining vague answers, not by learning to code.
Starting from the technology rather than the problem. Initiatives that begin by acquiring a capability and then hunting for a use case tend to fail. The reliable sequence is to name where the organisation is slow, inconsistent or blind, and only then ask whether current AI is genuinely good at that class of problem.
A real pilot has a defined decision it exists to inform, success measures agreed before it starts, and a pre-committed willingness to stop. Set the accuracy, time-saved or error-rate bar against a baseline in advance, and decide up front what result would mean walking away.