Organising for AI: roles, team models and ways of working

0:00 Organising for AI

Here is a pattern I have seen in banks, telecoms and scale-ups alike. A company sets up an AI innovation lab, hires brilliant people, and produces a stream of impressive demos. A year later, almost none of them are in front of customers. The technology was not the problem. The organisation was. In this lesson you will learn the roles AI products need, the main team models, the ways of working that change, and how to write a one-page team charter.

0:35 Analogy: a restaurant kitchen

Here is an analogy. Building AI products is like running a restaurant kitchen. You need chefs, but you also need someone who decides the menu, someone who tastes every dish before it leaves, suppliers who deliver fresh ingredients, and health and safety inspections. A kitchen full of brilliant chefs with no one tasting and no fresh ingredients still serves bad food. In AI teams, the tasting is evaluation and the fresh ingredients are data.

1:07 Key roles

The roles. The AI product manager owns problem selection, autonomy levels, the PRD with evaluation criteria, golden-set coverage, economics and launch gates. AI engineers build features on models: prompts, retrieval, tools, agents and evals in the pipeline. ML engineers handle fine-tuning, serving optimisation and open-weight deployment. Data engineers keep knowledge fresh and permissions correct. Designers own interaction patterns for uncertainty. And an evaluation lead, domain experts and risk, legal, privacy and security colleagues complete the picture. One person often holds several roles.

1:43 Team models

Three team models. A central AI team, or centre of excellence: a small expert group that prototypes and advises, great early on, but prone to demos that never ship. Embedded AI in product squads: each squad owns its AI features end to end, great for adoption, but prone to duplicated infrastructure and uneven quality. And platform plus embedded, hub and spoke: a platform team provides the model gateway, routing, evaluation tooling, guardrails, observability, cost dashboards and vendor management, and squads build features on top. That is the common end state once you have several AI features.

2:25 Governance forum

Alongside, a lightweight governance forum with product, engineering, legal or privacy, security and risk. It sets policies, reviews high-risk launches and keeps an inventory of models and vendors. The goal is a fast lane with clear rules, not a queue. If teams know exactly what a safe launch requires, governance speeds things up.

2:48 Ways of working

Ways of working change too. Evals become part of the definition of done: no change to AI behaviour merges without eval results. Weekly error-analysis sessions put a PM, an engineer and a domain expert in front of real failures together. Prompt and configuration changes are treated as code: reviewed, versioned and deployed through the pipeline. Monthly cost reviews track cost per task by feature. There is a process for adopting new models. And everyone upskills: PMs in evaluation, engineers in UX for uncertainty, support staff in structured feedback.

3:26 Simple example: 12-person startup

A simple example. A twelve-person startup in Lahore cannot hire eight roles. So they assign hats: the founder is the AI PM and owns the golden set; two engineers share AI engineering and the small platform, a gateway and logging; a customer success lead spends four hours a week scoring outputs; and an outside privacy advisor reviews launches quarterly. One weekly error-analysis hour keeps them honest. Small team, every role covered.

3:57 Business example: Riyadh bank (illustrative)

Now a realistic business example, with illustrative outcomes. A Riyadh bank's innovation lab built chatbot prototypes that rarely reached customers. They restructured into a six-person AI platform team, providing a gateway with approved models, in-kingdom hosting options, evaluation tooling and logging, plus AI engineers embedded in the retail, small-business and operations squads. A governance forum approved use cases and ran safety reviews. Within two quarters, three AI features reached production with shared evaluation and monitoring, and time from idea to pilot dropped substantially.

4:33 Hands-on: team charter

Your hands-on template is a one-page team charter. The mission with a measurable goal. The team model. Clear ownership: golden sets and launch gates, evaluation tooling and the gateway, the human scoring programme, and the model and vendor inventory. The rituals. The definition of done for AI changes. And the escalation path for serious incidents. One page, reviewed every quarter.

4:59 Common mistakes

Common mistakes. A central lab with no path to production. Every squad building its own gateway, logging and evals. No named owner for golden sets and quality. And governance that acts as a blocker instead of a fast lane with clear rules. Each of these slows you down more than any model limitation.

5:22 Another example: UAE retail group

Another example, from a UAE retail group. They did not hire a large AI team at first. Instead, they trained twenty strong software engineers in AI engineering over three months, with a focus on retrieval, evaluation and cost, and hired three experienced specialists to lead the platform. Store operations staff became part-time evaluators, scoring outputs in Arabic and English. Within a year, AI skills were spread across the product teams rather than trapped in one lab.

5:55 Is the org working?

How do you know your AI organisation is working? Watch three numbers. Time from idea to safe pilot. The share of AI features with an owner, a golden set and a scorecard. And the number of AI incidents, with how quickly they were resolved. If ideas take months to reach a pilot, or features have no owner, the org design needs attention, whatever the org chart says.

6:24 FAQ: do we need a chief AI officer?

A question from HR and leadership: do we need a chief AI officer? Some organisations benefit from a senior leader who owns AI strategy, platform investment and governance, especially when many teams are adopting AI at once. Others give those responsibilities to existing product and technology leaders. What matters is not the title but that someone accountable owns the platform, the governance forum and the portfolio of AI bets, with the authority to make trade-offs.

6:57 Try this now

Try this now. Draw your current AI setup on one page. Who owns the golden sets? Who owns cost? Who can approve a high-risk launch? Where is infrastructure duplicated? Then write the one change that would most improve your path from idea to safe pilot, and who needs to agree to it.

7:20 Watch me do it

Watch me do it. I'm drafting the AI team charter for a fintech with four product squads. Mission: reduce onboarding time and support handling time with reliable AI within twelve months. Team model: platform plus embedded. The platform team of three owns the model gateway, logging, evaluation tooling and cost dashboards. Each squad gets one AI engineer, upskilled from existing developers. Ownership: each feature's PM owns its golden set and launch gates; a support quality lead spends eight hours a week on human scoring; the governance forum, meeting monthly, owns the model and vendor inventory. Rituals: a weekly error-analysis hour per squad, a monthly cost review, a quarterly model review. Definition of done: eval report attached, no slice regression, cost within budget. Escalation: serious AI incidents page the on-call engineer and the PM. I share it with the four squad leads and ask each to name one gap.

8:24 Recap

Recap. AI products need clear roles, from PM and AI engineer to evaluation lead and domain experts. Most organisations end up with a platform team plus embedded AI engineers, guided by a lightweight governance forum. Put evals in the definition of done, hold weekly error analysis, treat prompts as code and review costs monthly. Next, your capstone brings the whole course together.