Dabbling, Delivering, Developing

Every organisation right now will tell you it is doing something with AI. Most are right. The harder question is what, exactly, and whether that activity is building anything that lasts.

After working with organisations across housing, professional services, manufacturing, retail and events over the past three years, we have started naming something we see repeatedly. There are three distinct stages of AI adoption, and most organisations are either misidentifying which one they are in, or assuming that moving through the stages happens automatically, without deliberate effort.

The three stages are Dabbling, Delivering, and Developing. They are not a maturity scale in the consulting sense, where higher is always better and the goal is to reach the top. They are descriptions of three fundamentally different relationships with AI, each with its own risks and its own opportunities. The point is not to rush to Developing. The point is to know where you are, so you can make deliberate choices about where you want to be.

What Dabbling Looks Like

Dabbling is experimentation without stakes. It is the AI activity that sits outside the work that actually matters: the prompts people run in their lunch breaks, the tool someone tried once and mentioned in a team meeting, the task that someone delegated to a generative AI tool to see what would come back.

Dabbling is not a problem. It is almost always where adoption starts. The issue is that organisations frequently mistake dabbling for progress. They survey their teams, find that 60 per cent have tried a generative AI tool, and interpret that as evidence of meaningful adoption. It is not. It is evidence that people are curious. Curiosity is the beginning of adoption, not adoption itself.

The tell-tale sign of a dabbling organisation is that AI feels optional. Staff who use it are early adopters or enthusiasts. Staff who do not are not missing anything consequential. The outputs of AI use are things people could also have done without it, possibly slower, but without meaningful difference to the outcome. Nobody's work depends on AI yet.

There is also a shadow version of dabbling worth naming separately. In some organisations, what looks like casual experimentation from the outside is actually ungoverned use on real work, with no visibility from leadership. Staff pasting client data into public-facing tools. AI-generated drafts going out without human review. This is not cautious experimentation. It is ungoverned exposure, and it is more common than most organisations realise when they actually look. The distinction between healthy dabbling and ungoverned use matters enormously.

The First Test: Does It Touch Real Work?

The shift from Dabbling to Delivering happens when AI moves from discretionary to consequential. The test is a single question: does it touch work that matters?

Delivering organisations are not defined by the volume of AI use. They are defined by whether AI is embedded in processes where the output carries real stakes. A customer-facing team using AI to draft communications that go directly to clients. A finance function using AI to generate analysis that informs board decisions. A leadership team using AI to synthesise data that shapes policy. When AI fails in a Delivering organisation, something consequential fails with it.

This is the stage where governance becomes non-negotiable, because the risk profile changes completely. In a Dabbling organisation, AI errors are inconsequential. In a Delivering organisation, they are not. This is also where capability gaps tend to surface most sharply. People who managed early experimentation without much support often struggle when the expectations and stakes go up. The confidence gap that was invisible during dabbling becomes visible the moment the work depends on the output.

The organisations we work with in the housing sector are largely at this transition point right now. They have invested in tools. Staff are using them. But governance, training, and cultural work have not kept pace with usage. The investment in the tool has outrun the investment in the people using it.

What Delivering Requires

The transition to Delivering is not primarily a technology decision. The tools rarely change significantly between the Dabbling and Delivering stages. What changes is the organisational infrastructure around them.

Delivering requires three things most Dabbling organisations have not yet built. The first is a clear position on which tools are approved and for what purposes: not a policy document that sits on an intranet, but a shared understanding that is genuinely operational. The second is a minimum standard of capability across anyone whose work now depends on AI outputs. This does not mean advanced technical training. It means the kind of practical, confidence-building work that gets people from anxious to competent.

From our delivery, that shift is faster than most people expect. In a well-structured session, the majority of a leadership team can move from low confidence to working competence in a matter of hours. Pre-session surveys routinely show 70 to 80 per cent of participants rating their AI confidence as low or very low. By the close, the majority have shifted. The problem is not the learning. The problem is finding the right conditions for it.

The third requirement is accountability. When AI is doing consequential work, someone needs to be responsible for the quality of its outputs. This is often the thing organisations forget to design. They invest in the tool and the training, and then assume that responsibility for AI output will take care of itself. It rarely does.

The Second Test: Are You Shaping the Tool?

The move from Delivering to Developing is a different kind of shift. The test here is whether the organisation is consuming AI or building with it.

A Developing organisation is actively shaping how AI operates in its context. It is not just using tools as they come out of the box. It is customising, refining, and building processes and systems around AI that embed its specific knowledge, values, and operational logic. The difference between Delivering and Developing is the difference between a professional using a tool and a craftsperson building with materials.

Developing is not the right stage for every organisation right now. For many, the priority is getting from Dabbling to Delivering with proper governance and genuine capability. But it is worth knowing what Developing looks like, because the organisations that are already there are building structural advantages that compound over time. They are not just using AI to do existing work faster. They are doing work that was not possible before, at a quality and scale that creates real competitive distance.

Which Stage Are You Actually In?

The most common error is overestimating. Organisations tend to place themselves at the Delivering stage because they have active AI use across the business, when the honest answer is that most of that use is still Dabbling. The test is not whether people are using AI. It is whether the work depends on it.

The second most common error is assuming that progress through the stages is automatic. It is not. The move from Dabbling to Delivering requires deliberate investment in governance, capability, and accountability. The move from Delivering to Developing requires a strategic decision and sustained commitment. Neither happens by accident, or simply because the tools are available.

A useful diagnostic: pick the three most consequential things your organisation does, the decisions, outputs, or services where getting it wrong matters most, and ask honestly whether AI is involved in any of them, with what oversight, and with what governance. If the answer is unclear or uncomfortable, that tells you something about which stage you are actually in.

The point of naming the stages is not to create a hierarchy or a target. It is to give organisations a more precise language for talking about where they are, what they are trying to build, and what the move from here to there actually requires. Precision is useful. Vagueness is where risk hides.