Rolling Out AI to a Team of Ten

Most published advice on rolling out AI assumes a change management function, a pilot cohort, and a steering group. If you lead a team of eight or twelve, that advice is not merely too heavy — following it will consume the entire budget of goodwill you have for the whole project.

Small teams have real advantages here: everyone can be in one conversation, you'll see problems within days, and you can change your mind without a governance process. The sequence below assumes those advantages rather than apologising for them.

Start with tasks, not tools

The instinct is to pick a tool first. It's the most visible decision and the least important one — the major tools are close enough that the choice rarely determines outcomes.

Start instead by getting the team to list, individually, the three most tedious recurring parts of their week. Twenty minutes in a meeting you're already having.

That list is the rollout plan. It's specific to your work, it has the team's fingerprints on it, and it points at the tasks where a win is both likely and visible. Anything you'd have designed from the top would have been a worse guess.

Answer the two unasked questions before anything else

Nobody will raise these and both are gating.

Is my job at risk? Answer specifically, at the level of tasks — which parts you expect to move, which you don't. A slogan gets heard as a slogan.

Will I be blamed if it goes wrong? The workable answer is that people own what goes out under their name, and the time to check is part of the task. Say both halves. The first alone reads as a threat, and the response to a threat is to avoid the tool for anything consequential — which is exactly the work where it would help.

Ten minutes, once, in plain language. Skipping this is why rollouts produce attendance rather than adoption.

Two people, two weeks, one task each

Not a pilot cohort. Two volunteers, each taking one task from the list, for a fortnight.

They aren't testing the tool. Their job is to come back with what they had to tell it, what they had to correct, and what didn't work — which is the material everyone else needs and can't get from documentation.

Volunteers, not appointees. Someone who wants to do this will produce something useful; someone assigned will produce a report.

Make the second wave copy, not explore

The commonest failure at this point is telling everyone else to go and find their own use cases. That's asking eight people to each repeat two weeks of discovery.

Instead: here's what worked, here's the brief, here's what to check. Ask people to run it on their own work for a fortnight.

Copying produces a win in the first week. Exploring produces a fortnight of mediocre results and a conclusion that this isn't for them. Exploration comes later, once people have felt one thing work.

Set the standard as a team, once

Half an hour, together: for our main output types, what gets checked before it goes out?

Three or four lines is enough. The value isn't the content — it's that it exists collectively. Without it, every person invents their own rigour privately at wildly different levels, and your sceptic's real concerns become a personality trait rather than a checklist item.

Write the boundaries down, and make them short

Two lists, both short:

Never paste this. Client-identifying data, personal data, anything under NDA — whatever's true for you, named specifically.

Always have a person on this. Anything sent externally, anything that spends money, anything that deletes.

If your policy is longer than a page, it will be replaced in practice by people's guesses. And if the sanctioned path is slow — approval queues, a tool that takes two days to get — people will use personal accounts instead, and you'll have the exposure without the visibility.

What to watch, and for how long

Give it a quarter before drawing conclusions, and watch three things: whether the two initial tasks are still being done that way in month three, whether anyone has volunteered a new one, and whether quality complaints have changed.

The first is the real adoption signal. Enthusiasm at week two means very little; a workflow still running unprompted at week twelve means it's genuinely better.

Hélène — the list she didn't write

Hélène leads a ten-person marketing team. Her first attempt was a tool rollout with a training session, and by month two nothing had changed.

Her second attempt started with the team listing their own tedious tasks. Two things came up that she'd never have guessed — reformatting partner-supplied assets, and writing the same event follow-up eleven times with different names.

Both were solved within a fortnight. Her assessment: the top-down version failed because she'd picked tasks that were annoying for her, and she isn't the one doing most of the work.

Bilal — the policy that fitted on a card

Bilal runs an eleven-person consultancy. His first AI policy was four pages, produced by a template, and effectively unread.

He replaced it with two lists on one card: five things never to paste, and three actions that always need a person. Everything else permitted.

His observation a quarter later: the four-page version had produced cautious guessing and some quiet personal-account use, because nobody could hold it in their head. The short version is actually followed, which makes it the stricter policy in practice.

The one thing

At ten people, skip the programme. Start from the team's own list of tedious tasks, answer the job and blame questions specifically, run two volunteers for two weeks, then have everyone else copy rather than explore.

Set the checking standard together, keep the boundaries to one page, and judge it at week twelve rather than week two.