Writing

AI Isn't Failing Because of the Technology

Over the past year, working in AI business adoption, one thing has become very clear to me: AI isn't failing in enterprises because of the technology. It's failing because we haven't prepared our people to use it.

That sentence gets nods in the room and then almost nothing changes, because it sounds like a platitude. It isn't. It's a budget statement, an org-design statement, and a roadmap statement, and each of those has a specific consequence.

Here is what it actually means in practice, and where I spend my time closing the gap.

1. Establish clear ownership

Most AI programs have a technology owner and no capability owner. Procurement is somebody's job. Security review is somebody's job. Whether a claims processor in Charlotte can do her work differently on Tuesday is nobody's job — it's distributed across four functions, which is the same as nobody.

The fix is unglamorous: position AI business enablement as a defined function with a named owner, a budget and a number to hit. Not a workstream inside a technology program. Not a communications tent-pole. A function, with the standing to make demands of other functions.

Until that exists, everything below is somebody's side project.

2. Connect training to execution

Training is the most over-supplied and least effective part of most AI programs. Not because the training is bad — ours was genuinely good — but because there's a chasm between learning something in a session and doing something different at your desk.

The bridge is working directly with business teams to turn learning into real, measurable use cases. Not "here's how prompting works," but "let's take the thing your team does every Thursday and rebuild it together, now, while I'm sitting here."

That's expensive per person. It's also the only thing I've watched reliably convert exposure into behavior. Which means the model has to be a floor of broad training plus deliberate investment in hands-on execution, and you have to be honest that the second part is where the value is.

The pattern

Adoption doesn't come from big launches. It comes from small moments: someone trying their first prompt. A team sharing a real use case — the small ones resonate quickly. Curiosity replacing hesitation and building confidence.

3. Build repeatable frameworks

Early on, every AI use case is bespoke. Someone has a good idea, someone senior likes it, it gets built. That works for the first ten and collapses at the hundredth.

What scales is structured ways for teams to identify, test and scale AI opportunities themselves — a shared way to spot a candidate, a lightweight way to test it before committing, and a known path from "this works for my team" to "this is how we do it now."

The framework matters less than the fact that one exists and everyone uses the same one. Without it you get a thousand flowers and no garden, and eventually a governance problem you have to solve retroactively under time pressure.

4. Scale through partnerships

No internal team is big enough to enable an entire enterprise alone. The leverage is in vendor ecosystems — but with a critical caveat that took us a while to get right.

Vendor content is built for a general audience. It is competent, current, and slightly generic, and generic content is exactly what a skeptical employee uses to confirm that this isn't for their kind of work. The partnership only pays off if you do the translation layer: taking that content and making it practical and business-ready for the specific roles in front of you.

Done well, this is how you get enterprise-scale reach at a fraction of the cost. Done lazily, it is how you deliver a lot of training that nobody applies.

5. Align adoption to outcomes

The last gap is the one that determines whether the program survives its second budget cycle. Adoption has to be tied to productivity gains, time saved and tangible business outcomes — not to activity.

This is harder than it sounds and people avoid it for a rational reason: activity metrics always look good and outcome metrics sometimes don't. But a program that can only report activity has no defense when someone asks what the money bought, and in a regulated environment somebody always asks.

The reframe underneath all five

Look at that list again. Ownership. Execution. Frameworks. Partnerships. Outcomes.

Not one of them is a technology problem. Every one is an organizational-design problem wearing an AI costume — and that's precisely why they get under-resourced. They don't look like the exciting part.

AI transformation isn't a technology rollout. It's a workforce shift — and most companies are still early. But not for long.

The organizations that treat it as a workforce shift are going to compound. The ones still running it as a deployment schedule will keep buying capability their people never convert, and will keep concluding that the technology underdelivered.

It didn't. We did.


What are you focusing on to build AI adoption? I'd genuinely like to know which of these five is biting hardest where you are — tell me on LinkedIn or send me a note.

← All writing Next: The Gap Is No Longer Access. It's Capability.

Keep going

More on the human side of this

Shorter thinking on LinkedIn, longer arguments here.