The months you cannot buy.

What cannot be bought

Almost everything in this market is sold as acceleration. It is worth being clear about the one thing that resists it. Individual fluency with these tools, the point at which somebody stops producing party tricks and starts producing work that holds up, takes about three months of regular use. Not a course. Use.

That period cannot be bought or skipped, and we should say plainly that we cannot do the practising for you. What we can do is make it count. Left to themselves, people meet the failure modes by accident and usually late: they find out a model was confidently wrong some time after they relied on it. With somebody in the room who knows, they meet the same failure on purpose, in the first hour, on something that does not matter.

The instinct for when a model is confidently wrong, the habit of checking, the sense of which problems are worth pointing it at: those still take repetition. They just take a great deal less of it when somebody is standing next to you explaining what you are looking at.

So what can be changed?

Two things. When the clock starts, and what the early weeks are worth. The first matters more, because a clock that has not started cannot be made to run faster.

A tool arrives in days. Fluency takes months. Procurement is fast and learning is slow, and only one of those is on the critical path, which is why an organisation can be several months into an initiative with the software fully deployed and the clock not yet running. It is not the licence that will hurt you. It is the months you did not start.

This is where most of the conversations we have actually begin, because almost nobody thinks of themselves as not having started. There is a licence, a pilot, a programme with a name, and still nothing anyone can measure has moved. That is the tell. Activity started; the months did not. The clock that matters runs on individuals using these tools in their own work, week after week, and for most people in most organisations it has never ticked.

What actually starts it

People start when three things are true at once: they have permission to experiment without it counting against them, a reason that connects to their own work rather than to an abstraction, and somebody in the room who genuinely knows and can answer the question they are too senior to ask in public.

That last one is underrated. Most people in senior roles have a question about this technology they would rather not ask in front of their team. Answer it once, properly, and the exploring begins that afternoon. Leave it unanswered and no amount of tooling will help.

Not everyone, and that is fine

There is an assumption worth dropping: that everybody has to become fluent. They do not, and expecting it wastes effort and goodwill.

Some people take to this immediately. Given permission and a first win, they build things, and they become the ones their colleagues quietly rely on. Others will never want to, which is an entirely reasonable position and does not make them a problem to be solved. They have the same pressures and the same needs as everyone else. What they need is not fluency. It is a button, an automation, an outcome somebody can measure, built for them by the first group.

That is the shape of it: you do not need everyone capable. You need enough capable people to serve the rest, and you need to know which is which.

What arrives two or three months later

The interesting part is not what people build while they are learning. Most early attempts are small, and that is fine, because they were never the point.

The point is what happens a couple of months in, when people who have actually used these tools start asking for different things. The requests get more ambitious and, more importantly, better founded. They stop being shaped by what somebody claimed at a conference and start being shaped by what the person has seen work with their own hands. Ambition of that kind is worth having, and it cannot be manufactured in a strategy session. It has to be grown, and growing it takes the months.

This is the argument for starting now rather than waiting for the picture to clarify. Not urgency for its own sake. Simply that the earliest date at which an organisation can have well-founded ambition about this technology is a few months after its people begin. Everything else can be arranged later. That cannot.

How we approach it

We start the clock. A small group, a couple of hours, a real problem, and somebody in the room who knows the answers. Usually senior teams first, because if the people making the consequential decisions have not felt this for themselves, everything below them inherits the gap.

Then we get out of the way, because the months belong to your people and nobody can serve them on their behalf. It is the same principle as capability beating dependency, and a week afterwards it is worth applying the Next Monday test to whatever they built.