The skills that make or break AI impact

Proven ability and desire to learn

Note the first half of that. Desire on its own is enthusiasm, which is easy to express and impossible to verify. What you want is evidence that someone has already taught themselves something difficult, plus the appetite to do it again.

This is where our expectations were most consistently wrong. On more than one team, the first working thing came from someone with no engineering background. They built something small and personal first, to learn the shape of it, and were then the person who spotted the valuable version a fortnight later. They were willing to have a go and unbothered by the first attempt being unimpressive.

It matters because of a common failure. Most people who decide AI is overhyped reached that verdict after one disappointing result and stopped. The capability is not excitement about technology; it is the disposition to try again differently. It matters for resourcing too: the tools keep improving, so deep knowledge of this quarter's approach with no appetite for the next one is a depreciating asset.

What to look for. Evidence of recent, self-directed learning, and honesty about how it went.

• Something they taught themselves recently and unprompted, rather than a course an employer paid for.
• A specific account of the first attempt failing. “I tried to get it to do our monthly report, it was useless, and it took three attempts to realise I was giving it the wrong file” is worth more than a fluent summary of what a tool does.
• In your existing team, the person who has quietly built themselves something without being asked.

Be wary of tool names with no story attached.

Understanding how information informs decision making

This capability separates a system that works from one that produces confident nonsense, and it is where we see the most time and money lost.

The pattern repeats almost every time. A team asks for help making the AI better at a task, and the real problem turns out to be that the information it needs is not available, not current, or not allowed to leave the system it sits in. One team wanted better written briefs; the actual issue was that no shared template existed and the person receiving the brief had none of the context the person writing it had. Another stalled on a routine summarisation task because only the host of a meeting could download the transcript. Nothing to do with AI. Everything to do with who could reach the information.

You may recognise this as data management wearing different clothes, and you would be right. One version of the truth. Someone accountable for whether it is current. Deciding who can see what. If your organisation already takes that seriously, you have a head start. One part will be less familiar: more information is not better information. Models get less accurate as you give them more to hold, so judgement about what to leave out matters as much as knowing what to include.

What to look for. People who can tell you what a decision actually rests on. Take a decision they make regularly and ask what they need to know, where it lives, and how they would know it was out of date. Strong answers:

• separate what changes the answer from what is only background
• name real sources, and are honest about which of them are unreliable
• include a confession about a workaround built because something is not where it should be

Someone who describes the steps they follow and never mentions what they need to know is describing a routine, not a decision.

The ability to describe a process and look at it critically

The most underrated of the three, and the one that converts most directly into value.

Most people can tell you what they do. Far fewer can describe it as a process: the trigger, the steps in order, the decisions inside it, who makes each one, the exceptions, and how you would know it had been done well. Fewer still can look at that description honestly and say which parts are necessary and which exist because someone left years ago and nobody revisited it.

“If people do not see the process, they can not improve it.”

W. Edwards Deming, The New Economics for Industry, Government, Education (p. 30)

That last part matters more than it sounds. Most processes carry steps that compensate for a constraint that has quietly gone away. A review stage because one person could only read so many documents a week. A handover because two systems never spoke. Remove the constraint and the step has no reason to exist, but nobody removes it, because by then it is simply how things are done.

It also determines whether outside help is worth buying. A clear, critical process description is the raw material every build works from. Without one, no amount of technology helps. You automate the confusion and get it faster.

What to look for. Ask someone to walk you through a process they own, end to end, without interrupting. Then ask two questions:

• What goes wrong most often?
• What would you remove if you were designing it today?

Strong answers volunteer the exceptions, because people who understand a process think in edge cases, and include at least one honest admission of waste. The happy path only, or a defence of every step, usually means they have never had to explain the work to anyone able to question it.

Twelve weeks with the people already in place

None of these three requires anyone to understand the technology, which is rather the point. They are ordinary judgement applied to a new set of tools. You could already spot a track record of learning, clear thinking about information, and honesty about how work really happens. You may just not have been selecting for them deliberately.

Which leads to the move we would make before writing any job advert: look for these three in the people you already employ. Organisations are usually short of visibility rather than talent.

That is what our AI Adoption Accelerator is built to do. Not teach these three, which cannot be done, but give them somewhere to show up: twelve weeks, the whole team rather than the two people who taught themselves, and a way for everyone to log the friction in their own work. A triage step sorts what they can build themselves from what needs real engineering, and each change carries a confirmed number for what it was worth.

The output is not really what gets built. It is that at the end you can see your own capability clearly: who has these three, where the gaps are, what your team can deliver alone, and what is worth bringing support in for.

Then the resourcing decision makes itself.