I've made 20+ BUs AI native. This is my approach, the long version, with how I actually run it week to week. It works. You can copy it.
Why it starts. It usually starts the same way. The board has seen LinkedIn and X posts for months (or someone came back from a conference all fired up). Leadership realises "our product is AI native, our business ops aren't". Revenue per employee has to go up. Opex has to come down. Do more with less.
So the pressure lands on GTM, HR, legal, ops and finance all at once.
Then most companies pick one of two paths (disclaimer, neither of them works).
Top down. A big programme from the centre, a steering committee, a lot of slides... and nothing ships. The people who would actually use the tools never get near them.
POCs everywhere. Every team runs its own little experiment with its own tools. They pop up like mushrooms. None of them reach production and nobody can reuse what the others built. You end up with a pile of chatbots, a few different vector stores and no shared guardrails.
Here's the full map. I'll walk through it part by part.
1. Three prerequisites (the holy trifecta)
Exec buy in. A real sense of urgency and a budget behind it. Urgency without budget gives you a nice kick off and then nothing. Budget without urgency gives you a long programme nobody feels.
The right team. The structure below, with names on every seat. If nobody's name is on it, nobody does it.
Aggressive prioritisation. Pick where to start and say no to the rest for now. The "for now" matters. People take a no a lot better when they can see the backlog and where they sit in it.
Miss one of the three... you're gonna fail. If one of the three is missing, I don't take the project.
The first week I mostly listen. I try to understand the whole platform, their technology, their stack, their people, the internal politics and how everything really works. I sit down with the people who run each function (the function head, the ops people, the ones in the trenches) and ask about their remit, their team, their KPIs for this year and next, how work actually flows and which tools they use. AI comes last in those conversations. Along the way I build alliances.
Then I come back with a roadmap. The suggested architecture, the suggested teams and a ranked list of what the automation roadmap should look like.
2. One AI centre of excellence (sounds fancier than it actually is)
Choose between the CTO, CIO, CISO, legal, ops, finance, HR or people, an AI engineering lead and the function heads. Put the people who can say yes or no to data, tools, risk and money in one room. Others join as their function comes up.
It owns five things.
Guardrails. What data and tools are allowed.
Governance. Who approves what and how fast.
Decision making. The trade offs between BUs.
Leadership education (and enablement). So execs know what good looks like.
Synergies. Build once, reuse across BUs.
Monthly cadence. Big calls get made. Which platform we build on, which BU gets the next engineer, what data can leave which system. If a decision needs three meetings and an email chain, the CoE is too big or the wrong people are in it.
One of the first big calls is the environment decision. Where the shared build lives, on which cloud, using what you already own. Boring call. Every build after it runs on top of it, so make it early.
3. A small team in every BU (this is the investment in time and $$)
An exec sponsor. The function head, one per BU, who sets priorities and removes blockers.
An internal product owner who owns the BU backlog and decides what ships next.
Someone from ops who knows the tooling and the space really well (they can be shared across functions).
An AI native engineer embedded in the function. Spread them too thin and it falls apart.
This team works together daily, with a weekly check-in. That's where the magic happens. The sponsor clears blockers. The product owner reorders the backlog. Ops says what will break in real life. The engineer says what's realistic this week. The check-in stays short when the backlog is clean.
The engineer profile depends on your stack and architecture. What matters most is that they sit in one function, with the people who do the work, so they see the mess first hand.
4. Weekly sprints on one ranked backlog
Every use case gets scored on impact and ease. Then it moves left to right.
One warning before anything goes on the backlog. Automating a crappy process is really dangerous. You just get the crappy process faster. Sometimes you need to think AI native and redesign the work from scratch. Some processes shouldn't exist in the first place, so kill those first.
Scope → Prioritise → POC → Controlled pilot → Pilot → Harden → Monitor and optimise
Scope. What it does, who uses it, what data it touches, what done looks like.
Prioritise. Score impact and ease, rank it against everything else in that BU.
POC. Prove it works on real data. Small and ugly is fine.
Controlled pilot. A handful of real users, a close watch, quick fixes.
Pilot. A wider group and a real workload.
Harden. Security, access, audit, error handling. The stuff that makes it survive a Monday morning.
Monitor and optimise. It's live. You watch it and keep improving it.
Early on the KPIs are speed and adoption. How fast did it get to a pilot and are people actually using it? In harden and monitor they become cost and retention. What does it cost to run and are people still using it once the novelty wears off?
Each BU has its own backlog. The CoE sees all of them side by side. That's how it spots two BUs asking for the same thing and builds it once.
5. Aim to build 80% once
The shared layer, owned by the CoE.
The data layer
Connectors and access
The agent runtime
Guardrails and audit
Patterns and evals
It runs on whatever cloud you already have. AWS, GCP or Azure. Or a clean build when the old setup is too messy to build on. That's the environment decision from the CoE. You don't want to make it twice.
The last 20% gets fitted per use case.
Approvals and write back. Who signs off before the agent changes a record.
Multi day workflows. Processes that wait on people.
Buying vendor AI where it already exists. If a vendor already does it well, buy it and plug it into the shared layer.
Guardrails, the shared stack and patterns flow down to the BUs. Learnings, synergies and wins flow back up to the CoE.
So the second BU goes faster than the first. And every BU after that should go faster again.
The order I run it in
Interviews per function first, to get the use cases and test the trifecta.
The environment decision, made by the CoE.
The roadmap back to leadership with the suggested architecture, the teams (a name on every seat) and a ranked backlog per BU.
Then the weekly sprints start, one BU first, the next one when the first is moving.
Hope it helps. Don't hesitate to reach out on LinkedIn if you have any questions but keep the questions as specific as possible please.
David
