Bringing your teams up to speed on AI

Maturity is not counted in licences

The first reflex of an organisation that wants to move is to buy accounts and hand them out widely. Three months later the vendor dashboard shows a handful of active users, almost always the same ones, and often those who needed help least.

A licence count measures spending. What measures competence is a person's ability to describe one action in their own work, say whether a model can absorb it, and explain why. That ability comes in stages, and each stage has its own difficulty.

Why broad rollout almost always fails

Giving people access to a tool without pointing them at one specific action to try it on is like handing over an instrument with no score. People already comfortable with digital tools pick it up, experiment, sometimes give up, and progress on their own. Everyone else waits for a direction that never comes. After a few weeks the gap between the two groups has widened instead of closing, and management often draws the wrong conclusion, that the team is not interested in the topic, when in fact the missing piece was framing.

Seeing what the technology does, and what it does not

At the start, "AI" names a single slightly magical block. The first step is to break it apart. A large general purpose model, a small specialised model and automation with no language model at all do not cost the same, do not fail in the same way, and are not watched in the same way.

A team has cleared this step the day someone says in a meeting that a script would be enough. That is a better indicator than a training certificate.

Simple questions that reveal the real level

To place a team on this first step without giving it a test, it is enough to listen to how it talks about a concrete case. Can it say whether the action it describes needs language understanding, information retrieval, calculation, or simply repeating rules already written down somewhere? A team that answers "we don't know, let's see what the tool can do" is still at the very beginning. A team that answers "this one, a script would do it, that one really needs a model" has already done the sorting.

Finding the first action, by watching people work

The internal survey asking "which tasks would you like to automate" produces polite, unusable answers. People name what annoys them, rarely what costs them time.

What works fits into half a day sitting next to someone at work. You then see the file left permanently open, the same search repeated four times, the summary retyped from one tool into another. A team moves up a level when it learns to look at its own work that way, without waiting for a supplier to do it for them.

What to watch for during that half day

A few markers help keep this observation focused: how often a piece of information is retyped instead of reused, how many tabs or files stay open at once to piece together one answer, the moments where the person pauses to look up a rule or a past case, and the tasks they describe as tedious without being asked. These four markers are often enough to surface the first action worth tackling, well before any wish list collected on paper.

Writing down what you never hand to a model

This is the stage where a team stops being naive. A mature team keeps a written list of what a model never handles alone: a price, a contractual commitment, personal data, a judgement call. The list is shorter than people expect, and it is the most useful part of everything written around a project.

It also changes the conversation with management. A team that arrives with its own limits already set becomes credible when it proposes a use.

Building that list without copying it from somewhere else

The list should not be copied from a generic template found online. It is built from the cases where a model's mistake would carry a real cost for the team itself, not for some abstract company. A good method is to go through the last six months of cases and ask, for each one, what would have happened if an automatically generated answer had gone out unreviewed. Cases where the answer would have embarrassed the team, committed the company, or touched sensitive data go on the list. The rest do not.

Putting the tool in their hands, on real data

A demonstration on a test fixture teaches nobody anything. People rediscover their own trade through the edge cases: the incomplete file, the customer who appears under two names, the unreadable attachment, the rule that applies to one supplier only. Until the tool has met those cases, the team stays a spectator.

The turn happens there. The day someone uses the tool on a real case and fixes what is wrong themselves, without asking permission, the competence has changed hands.

Getting ready for that move to real data

Before opening the tool on real cases, it is worth checking three things with the person about to use it: that they know how to flag a wrong answer without it feeling like a personal failure, that they have dedicated time for this first use rather than squeezing it between two urgent tasks, and that they know exactly who to tell if an edge case goes beyond what the tool is meant to handle. These three points stop the first contact with real data from turning into a quiet drop-off.

The sign a team is mature: it knows how to say no

An autonomous team spots that an answer has gone off track, can say when a use should be stopped, and turns down a project that arrives too early. That last point often surprises management, who were expecting enthusiasm.

A reasoned refusal is worth more than a pilot launched to show movement. It is why we always start with a diagnostic: sometimes it concludes that it is too early, and that conclusion saves you a budget. Our AI diagnostic exists precisely to place a team on these stages before recommending a project, and our approach to responsible AI carries that same logic through into production use.

Questions to ask before launching a pilot

A few simple questions help check that a pilot arrives at the right moment rather than too early. Has the person who will use the tool already observed their own work the way described above? Does the list of what is never handed to a model exist, even in a short form? Can someone on the team explain, in one sentence, why this particular action suits a model rather than a plain script? If any of these answers is no, the pilot has a good chance of turning into a demonstration with no follow-through.

The false signals of progress

Some habits give the impression of movement while changing nothing. The training day for everyone, which leaves each person exactly where they were the next morning. The designated AI lead with no mandate and no time set aside, who ends up answering colleagues' questions during breaks. The savings percentage announced to the board when nobody measured the starting point.

None of these habits is dishonest. What they cost is credit: by the time the serious project arrives, the team has already heard about AI several times for nothing, and it listens less.

Spotting these signals before repeating them

A simple way to check whether an initiative is a false signal is to ask what, concretely, will be different a month later. If the answer amounts to "people will be more aware", the risk is high. If the answer describes one specific action, carried out differently by a named person, on a real case, the initiative is more likely to produce a real maturity gain than just a memory of a training day.

We have arranged these stages into five engagements, one per stage, each with its working framework and what you take away at the end: see the five stages. Some of these engagements draw on our training methods, others lead directly into an AI agent or automation project, depending on the stage a team is actually at. You can also browse concrete examples in our use cases before choosing where to start.

Common mistakes that slow a team down

Some mistakes repeat from one project to the next, regardless of sector or team size. The first is confusing individual enthusiasm with collective maturity: one curious person testing several tools on their own time makes the team look like it is moving forward, while the rest of the group has changed nothing about how it works. The second is picking the most visible action rather than the most time consuming one, because it is easier to present at a board meeting than to justify with hours actually saved. The third is skipping the step of writing down the limits, telling yourself you will handle each case as it comes, which leaves every person inventing their own rule and produces inconsistent practice from one department to the next.

A fourth mistake, more subtle, is treating the rise in maturity as a project with an end date. A team that has cleared the five stages described here keeps learning with every new edge case it meets. The question is never "are we done", but "do we still know where we stand, and which action to work on next".

A checklist before starting a project

Before launching an engagement or a pilot, a few simple checks help avoid most of the false starts described above. Can the team name one specific action, observed rather than just claimed, that repeatedly costs it time? Is there already a list, even a short one, of what nobody on the team would hand to a model without review? Does one person have genuinely dedicated time, set aside on their calendar, to lead the first use rather than squeezing it between two urgent tasks? And above all, can the team say it is not yet the right moment without that being seen as a failure? When these four answers are yes, a pilot has a good chance of producing a real gain in maturity rather than a demonstration with no follow-through.

Frequently asked questions

How long does it take to bring a team up to speed?

We do not give a typical duration, because it depends mostly on one variable: the time actually freed up for the people who do the work. A team of five that frees half a day a week moves faster than a department of thirty that frees none.

Should everyone be trained at the same time?

No, and it is the most common opening mistake. Start with the people who perform the repetitive action you want to absorb. They know the edge cases, they will see immediately if the tool is wrong, and their opinion will carry the rest of the team better than a presentation.

Who should own the subject internally?

Someone who knows the trade rather than someone who knows the technology, and who has hours written into their schedule. A lead with no mandate and no time set aside is a title, not a role.

How do we know we are ready for the next stage?

When the team asks sharper questions than yours. As long as the questions are about the tool, you are still at the beginning. When they are about the edge cases of one specific file, the stage has been cleared.