Teaching an organisation to build with AI

There is a version of "we adopted AI" that means a licence was purchased. Seats get assigned, a few people try the tool for a fortnight, and a year later someone asks why the productivity did not arrive.

The tools were never the hard part. Getting an organisation to operate them was.

Adoption is a scoping problem first

Before any of the enablement work, there was a narrower question I had to answer honestly: with Vertex AI, Cursor and Replit in hand, how long does it actually take to build a full-stack application and deploy it onto the tech stack this company already runs?

Not the demo answer. The answer including the org's auth, its deployment path, its review expectations and its data access rules. That number is the one every adoption decision downstream depends on, and it is the one nobody had.

Scoping it properly is what turned "we should use more AI" into a set of specific bets: which internal tools were now worth building, and which were still not.

The A2A framework

The clearest application was an agent-to-agent framework, built on Vertex AI, aimed at a specific daily tax: analysts navigating fragmented systems to assemble one answer. Compliance sat in one place, the wiki in another, measurement in a third, and knowing which was authoritative when they disagreed lived in a handful of heads.

The framework let those questions be asked in natural language and routed across compliance, wiki and query agents, rather than across four tabs and two people.

The club was the mechanism

The part that made adoption survive contact with a busy quarter was not technical. I founded MiQ's AI Club to give AI/ML literacy somewhere to accumulate: a standing place for people to bring what they had tried, show what broke, and take away something they could use on Monday.

A club sounds soft next to a framework. It is the opposite. A tool with no forum around it produces a handful of power users and a long tail of people who tried it once. The forum is what turns individual competence into an organisational one.

The same instinct went into the DnA intern onboarding programme, which I designed and ran. Onboarding is where a team's actual standards get transmitted, and it is usually the first thing dropped when everyone is busy, which is precisely why it is worth owning.

And the unglamorous half

Ten or more product analysts and data scientists, across Healthcare, Entertainment and DOOH, working with product managers in the US on requirements that arrived in someone else's timezone.

That runs on cadence, not enthusiasm: daily scrum, sprint planning, and the quarterly BRP planning discussions I started within the team so roadmap prioritisation was an argument held once, deliberately, rather than relitigated every fortnight.

None of this is the part that gets written up. It is the part that decides whether any of the rest of it ships.