5 counter-intuitive lessons from AI training and coaching

This article is the core of the methodology used in AI Activation Sprints. In five lessons, it describes what I see repeat from one team to the next, and what separates teams that move into action from teams that stay stuck in exploration.

The market promise vs. the field

The AI training market sells a simple promise: more tools, more productivity. My coaching work tells a different story. Teams that successfully integrate AI into daily work are not the teams that watched the most demos. They are the teams that agreed to question how they produce before touching a single tool.

What follows are five observations repeated in the field. Each one is counter-intuitive. Each one can be tested.

1. The problem is almost never the tool

The mandate to adopt AI echoes through every company — and mostly it produces a mix of pressure and confusion. The default response is almost always the same, a piece of innovation theater: top-down mandates, long theoretical courses, exhaustive “state of the art” presentations. These approaches overwhelm people more than they help them.

My method flips the traditional adoption playbook. The principle is radically simple: never start with the technology; always start with use cases and the team’s concrete scenarios. The starting point is not a lecture on large language models — it is a conversation about daily tasks, frustrations, and what people are actually trying to achieve.

The same pattern repeats from one engagement to the next: theoretical courses are mildly effective at best, and “state of the art” overviews create anxiety and overload. Practical conversations that start from the team’s reality do the opposite. They cut the noise, refocus on what matters, and lead quickly to experimentation. That is the key.

This approach short-circuits the technology anxiety cycle. The ambient noise — vendor jargon, the hype cycle, endless but irrelevant possibilities — gets filtered out instantly. Anchored to known problems, AI becomes a tangible, directly applicable tool. Moving into action is not just easier; it is much faster.

2. Training does not create adoption; guided practice does

In the classic learning model, theory comes before practice. In the field, I invert that dynamic: theory is not a prerequisite; it is a spotlight. It only enters the room when it becomes necessary — to understand how something works when a tool performs well, or why it fails when it does not.

The core of the work is extremely concrete: screen shares and live prompt adjustments. Theory is not a foundation to master upfront; it is a resource pulled in on demand.

This fundamentally changes the learner’s role. Instead of passively receiving knowledge, people become active problem-solvers who pull information toward them at the exact moment they need it. That inversion produces a much deeper understanding, because it is anchored in practice.

3. The best use cases come from the business, not from IT

Use cases that hold up do not come from a top-down mandate or a tool catalog. They emerge from conversations with the people who do the work — their tasks, their frustrations, their goals.

Surfacing them takes the right posture. Mine fits in one sentence: this is not consulting; it is coaching — accompaniment, sparring partnership.

That nuance changes everything. Instead of long formal engagements, the format stays compact, so the work stays inside informal experimentation. The energy is that of a maker and entrepreneur: less PowerPoint, more screen sharing; fewer formal reports, more real-time problem solving.

For an agile organization — a scale-up where execution speed is everything — this collaborative format fits far better than a traditional consulting relationship, which tends to be rigid and top-down. And it is exactly in that setting that the business dares to name its real use cases.

4. ROI is measured in hours returned, not tools deployed

The natural reflex for measuring AI adoption is to count what got deployed. That is the wrong counter. In this domain, the learning process is often worth more than the immediate result — and a prototype that never scales is not a failure; it is a win. A project can stay at the prototype stage and still raise the team’s maturity while clarifying its tooling and transformation needs.

Take Novable: a complex use case, attempted but never deployed, still triggered a real discussion about a key part of the work. On the “tools in production” counter, that experiment weighs nothing. In the reality of the team’s work, it weighed a lot.

The distinction comes down to posture: a consultant is judged on the final result; a coach is judged on the team’s growth. An experiment that “fails” but strengthens collective maturity has real value — that is the heart of the approach.

5. A team’s autonomy is not trained; it is revealed

AI is usually framed as a pure productivity lever. Its benefits can run much deeper — and this is where autonomy reveals itself. Very tactical sessions sometimes open completely unexpected strategic conversations, capable of redefining part of the business.

I have watched it happen live: during one session, presenting a tool and its “reasoning” principle suddenly resonated with the company’s product and some of its internal practices. That moment opened a genuine strategic reflection. The immediate effect: a major strategy insight, with potentially significant long-term impact. Nobody “trained” the team to do that — the tactical exploration revealed a capability that was already there.

That is the deeper truth about innovation today: competence is built through practice, not instruction. The goal is not to “deploy AI”; it is to grow a critical mass of practitioners inside the teams. It is less about learning AI than about learning with AI, step by step.

Where to start? My advice is disarmingly simple: pick a task that is short but highly repeated, think about how to change it radically, and test a tool to improve it — just to try.

So — what is the first small task you will reinvent this week?