Getting your team actually using AI, as a team leader

Licences are not adoption. The usual pattern: everyone gets access, three people try it, one keeps going, and eight weeks later the invoice is the only evidence it happened.

What follows works for one team — five people or fifty — where you are the person accountable for its output. In a larger organisation it is still the unit that matters: adoption happens inside teams, not across an org chart. What changes at scale is the coordination around it, which is the last section.

Week one: pick the workflow, not the tool

One workflow. Not "use AI more". A specific, recurring, annoying task that at least three people do every week — first-draft quotes, structuring meeting notes into actions, answering the same category of customer question, cleaning a recurring report.

Two criteria that matter more than they look:

• It is done weekly at least. Anything monthly gives too little feedback to build a habit before people forget.
• The person doing it can tell whether the output is good. If nobody can judge, you cannot adopt safely — you can only hope.

Weeks two and three: work in the open

The single highest-return practice, and it costs nothing: a shared channel where people paste what they tried and what came back. Including the bad ones. Especially the bad ones.

This does three things at once. It teaches prompting far faster than training does, because people copy what visibly worked for a colleague on a real task. It surfaces failure modes while they are still cheap. And it makes the sceptics' objections concrete rather than atmospheric — which is how you answer them.

Post your own failures first. If the first three posts are all successes, nobody posts a failure and the channel dies.

Weeks four to six: turn the good prompt into a shared thing

Somebody will find a prompt that reliably works. That is the moment.

Move it out of their personal history into somewhere the team can use it — a saved prompt, a skill, a document, whatever your tooling supports. Give it a name people say out loud. The difference between a team where one person is good at AI and a team where everyone is, is almost entirely whether this step happened.

Write down alongside it: what it is for, what it is not for, and what to check before sending. Three lines.

What to do about the sceptic

You have one, and they are usually your best worker. Their objection is rarely "AI is bad" — it is "the output needs checking anyway, so it saves me nothing".

That is often true, and it is a specific, testable claim. Take it seriously: time the task with and without. Sometimes they are right, and the honest answer is that this is the wrong workflow. Sometimes checking is faster than drafting and the number shows it.

Either way you have converted a mood into a measurement, and you have shown that disagreement is allowed — which is what determines whether anyone tells you when it goes wrong later.

What to do about the enthusiast

You have one of these too, and they are a different risk: they will put something in front of a customer before anyone has checked it.

Give them the most interesting problem and the rule that anything customer-facing gets a second pair of eyes until you have evidence it does not need one. Framed as "you are ahead, help us prove it is safe", not as a leash.

Six-week checkpoint

Ask three questions, honestly:

The third is the real test, and it is the one nobody asks.

In a larger organisation

At two hundred people or across several teams, the six weeks above still apply — run them per team, not company-wide. What has to be added is the coordination, and there are only three parts to it.

Shared context, local workflows. What the business is, what may be claimed, how it sounds — write once, centrally, and let every team draw on it. What the team does with it stays local: sales and operations do not share a workflow, and forcing one produces something neither uses.

One named owner for the shared material, with a review date. Context that belongs to everyone belongs to nobody, goes stale within a quarter, and quietly degrades every output built on it.

Let the second team choose their own workflow. The strongest failure pattern in a multi-team rollout is handing team two the conclusion team one reached. Their work is different; the answer will be different; and being handed someone else's solution is exactly what makes a rollout feel imposed. Share the method and the shared context, not the use case.

Two things get harder at this size and are worth naming in advance. Consultation obligations apply from fifty employees, so the go-live date is set by that process rather than by when the build is finished — plan the two in parallel. And the language rule bites across sites: what an operating unit in Flanders produces for its own staff is not what one in Wallonia produces, and a single shared template that ignores this creates documents with no legal standing.

What not to do

Do not run a company-wide training day first. Enthusiasm without a use case decays in about three weeks, and you will have spent your one chance at everyone's attention.

Do not make usage a target. You will get usage, and it will be theatre.

Do not roll out to everyone because it worked for one team. The next team's work is different; run their week one properly rather than handing them your conclusion.