Why on our own work rather than examples?

Because the hard part is not the tool, it is the judgment about your systems. A developer who watches an agent write a bad change against a repository they know learns exactly where to trust it. The same person watching a demo on a to-do app learns nothing transferable.

Who should be in the room?

The people who do the work, and their leads. Not the executives who approved the budget, who get their own shorter session, because the two groups need different things and neither speaks freely in front of the other.

What is a champion, concretely?

One person per team who owns the practice: keeps the rules current, answers the questions that come up, notices when something is going wrong, and reports at the quarterly review. It is a few hours a month, not a role change, and it works best when it is recognized rather than added quietly to someone's plate.

Does this replace the enablement engagement?

No. Training teaches people to use a practice; Engineering Enablement builds the practice. Training on its own produces enthusiasm with nothing to attach it to, which fades. We will say so if you ask for the workshop without the harness.

Training & Champions | After AI Consulting

How do you get a whole team using AI well, not just the two people who already were?

Teach on their own work, not sample data, and give someone on the inside the job of keeping it going. A two-day workshop on your actual repositories, tickets, or documents, a session for the leadership who have to back it, then a champions programme with a quarterly cadence. Training that happens once is a line item; training with a champion behind it is a practice.

Training & Champions

Why most AI training does not stick

It teaches the tool. Six weeks later the tool has changed, the examples are stale, and the people who were already using AI are the only ones still using it.

What transfers is judgment about your own systems: which changes an agent can be trusted with here, what the review needs to catch in this codebase, which documents are reliable enough to retrieve from. None of that can be taught on somebody else’s example.

The shape

Two days with the team. On your repositories, your ticket queue, your document set. Day one is the working patterns and where they fail. Day two is the participants doing real work with someone experienced watching, which is where the useful conversations happen.

A session with leadership. Shorter, separate, and honest. What the practice requires from them, what it will look like when it is going badly, and what they should stop asking for. Microsoft’s 2026 survey found only 13% of AI users say they are rewarded for reinventing their work with AI even when short-term results slip. That number is a leadership problem and it cannot be fixed in the team workshop.

Champions afterwards. One person per team, a few hours a month, with the quarterly review as the forcing function. This is the part that decides whether the workshop was worth the money.

What we will not do

Run the workshop without the practice existing. If there is no harness, no policy, and no measurement, two days of training produces a team that is enthusiastic and ungoverned, which is worse than where it started. We would rather sell you the smaller enablement engagement first and the workshop second.

What the research saysAny team that has the tools and not the practice

66%: of AI users say it lets them spend more time on higher-value work
26%: say leadership is clearly and consistently aligned on AI
13%: say they are rewarded for reinventing work with AI

Source: Microsoft, 2026 Work Trend Index: Agents, human agency, and the opportunity for every organization (20,000 full-time workers in 10 countries, 18 February to 7 April 2026, fielded by Edelman Data x Intelligence)

What changes

Accuracy: People learn where to trust the tools on your systems, not on a sample project.
Efficiency: The whole team moves, instead of the two who were always going to.
Quality: A champion keeps the rules current, so the practice survives past six weeks.

Load removed

The relapse that follows a one-off workshop
Rediscovering the same working patterns team by team
Onboarding that starts from nothing every time

What you get

A two-day workshop run on your own repositories, tickets, or documents, never on sample data
A leadership session on what changes for the people who have to back the practice
Written working patterns for your stack, not general advice about prompting
A champions programme: who they are, what they own, how much time it takes, and what they report
A quarterly review cadence with an agenda that survives the first quarter
Onboarding material so the next hire inherits the practice instead of rediscovering it
A measurement baseline, so the workshop's effect is visible rather than assumed

Questions we get

Why on our own work rather than examples?: Because the hard part is not the tool, it is the judgment about your systems. A developer who watches an agent write a bad change against a repository they know learns exactly where to trust it. The same person watching a demo on a to-do app learns nothing transferable.
Who should be in the room?: The people who do the work, and their leads. Not the executives who approved the budget, who get their own shorter session, because the two groups need different things and neither speaks freely in front of the other.
What is a champion, concretely?: One person per team who owns the practice: keeps the rules current, answers the questions that come up, notices when something is going wrong, and reports at the quarterly review. It is a few hours a month, not a role change, and it works best when it is recognized rather than added quietly to someone's plate.
Does this replace the enablement engagement?: No. Training teaches people to use a practice; Engineering Enablement builds the practice. Training on its own produces enthusiasm with nothing to attach it to, which fades. We will say so if you ask for the workshop without the harness.