The Operations Bridge

Point three in the AI Strategy Points series. Last time was about defining value before you build. This one is about a distinction that gets flattened far too often: the difference between someone who uses AI and someone who builds with it.

Two very different populations, one training slide

Most organizations treat “AI adoption” as a single population learning a single skill. In reality, I see at least two distinct groups with very different needs, and treating them the same way wastes both their time.

AI end users need to know how to ask good questions, evaluate an output critically, and recognize when something looks plausible but is wrong. That’s a real skill, but it’s a using skill — closer to learning to drive than to learning to build the engine.

AI builders need something different: the patience to iterate on a data model or a workflow across dozens of failed attempts, the technical curiosity to understand why something broke, and the willingness to sit with an unfinished, occasionally frustrating tool for weeks before it becomes reliable. That’s a builder’s temperament, and not everyone has it, wants it, or needs it.

Be honest about which one most of your people actually are

A realistic assessment means admitting that most of your workforce will be end users, not builders, and that this is completely fine. The mistake is designing your entire AI strategy as if everyone needs to become a builder, then feeling disappointed when adoption stays shallow.

It’s equally a mistake to assume nobody wants to build. In every group I’ve worked with, there are a handful of people with real builder instincts who are currently doing something else entirely because nobody ever asked. Finding those people and giving them room is one of the highest-leverage moves available to a leader right now.

What each group actually needs from you

• End users need clear examples of good and bad prompts, permission to question an AI output instead of trusting it automatically, and tools that are already built well enough to be useful on day one.
• Builders need time protected from other duties, tolerance for visible failure while they iterate, and a leader who understands enough of the process to ask good questions without micromanaging the technical details.

Confusing these needs — giving a builder a one-hour prompting workshop, or asking an end user to debug a broken automation — produces frustration on both sides and makes AI adoption look harder than it actually is.

A question for leaders

Look at your current AI training plan. Does it distinguish between the people who will use AI tools and the people who will build them, or does it treat everyone the same?

Next: why I believe people won’t lose their jobs to AI — yet. They’ll lose them to people who adopt it.