Operating Model

AI Team Structures That Work

Org design · 3 min read

There is no single correct shape for an AI team, but there are two failure modes worth avoiding: a central group so remote from operations that it ships nothing, and federated enthusiasm with no shared standards. The workable answer is a small spine of central capability paired with embedded practitioners who own use cases in the business.

Start with a spine, not a department

A central group of even two or three people — an architect, a data steward, a delivery lead — is enough to set the standards for how models are evaluated, how data is accessed, and how systems are documented. Its purpose is to lower the cost of the second and third use case, not to build the first one alone. Where that spine is missing, every team reinvents its own conventions, duplicates retrieval and integration work, and signs its own vendor contracts.

Embedded practitioners sit inside the business unit and own a specific process. They understand the exceptions, the shift patterns, and the informal workarounds that no central team can see. Their mandate is narrow on purpose: make one workflow measurably better, document what they learned, and hand the pattern back to the spine for reuse elsewhere.

Sizing matters less than clarity. A spine of two may be right for an organisation of a few hundred people; an organisation of several thousand may need a small platform team and a number of embedded practitioners. What breaks the model is not a small team but an undefined one — people who hold the title without the mandate, or a centre that owns the standards yet has no route into the work itself.

Governance without a bureaucracy

Governance is often mistaken for a committee. In practice it is a short set of decision rules: who approves a use case, what data may be used, what happens when a model is wrong, and how outputs are reviewed before they affect a customer or a machine. A standing review of thirty minutes a fortnight, with a written decision log, achieves more than a quarterly board meeting with no record.

The forum should be able to say no. A governance body that only ratifies decisions is not governing; it is recording. The most valuable thing it does is stop a use case that carries more risk than value, or slow one down until the evidence is there. That requires a chair with the standing to overrule an enthusiastic sponsor.

• Central spine — sets standards, owns shared infrastructure and evaluation, and removes obstacles that recur across teams.
• Embedded practitioners — own a single workflow, carry domain knowledge, and prove value in place.
• Governance forum — approves use cases, arbitrates data access, and keeps a decision log anyone can read.
• Operating owner — a named executive accountable for whether AI work is delivering, separate from the technology itself.

Questions to ask

• Who owns the standard, and who owns the outcome?
• Which decisions can an embedded team take without escalation?
• Where does domain knowledge get captured so it survives a person leaving?
• What would make us stop a use case rather than scale it?

Centralised vs. Decentralised AI Functions

Comparison · 2 min read

The choice between a centralised and a decentralised AI function is usually framed as a trade-off between control and speed. The more useful question is which decisions should be made once for the whole organisation, and which should be made close to the work where the context lives.

What each model is good at

A centralised function buys consistency. One evaluation method, one access policy, one place where data governance is understood. It also buys distance: the centre can be slow, can be far from the shop floor, and can end up building capability that nobody has asked to use. A decentralised function buys speed and fit — teams solve the problem in front of them, in their own language — at the cost of duplication, inconsistent safety practice, and fragmented data.

The hybrid pattern that holds

Most organisations that sustain AI work end up federated: central ownership of platforms, evaluation methods, and guardrails; distributed ownership of use cases and the metrics they move. The centre builds the road; the units drive on it. What matters is drawing the line explicitly rather than letting it emerge from arguments. Platforms, data access, and safety standards belong to the centre; process design, adoption, and value realisation belong to the operating units.

Federation fails in two familiar ways. The centre accumulates authority — every exception becomes a ticket, every tool a platform decision — and the units stop proposing anything worth approving. Or the units accumulate capability, each solving data access in its own way, and the organisation discovers it has five answers to the same governance question. Both drifts are prevented by the same thing: a written boundary that names, decision by decision, where the line sits and who may move it.

• Centralise what is expensive to duplicate — infrastructure, the evaluation harness, model access policy, data governance.
• Decentralise what depends on context — use-case selection, workflow redesign, training, and the definition of success.
• Fund both — a centre with no delivery mandate becomes a standards body nobody obeys; units with no central support burn budget on duplicated work.

Questions to ask

• Which standards, if left to each team, would create real risk?
• Which decisions, if centralised, would slow work without adding value?
• Who arbitrates when a unit wants an exception to the standard?
• How will you know the model is working — what is measured, and by whom?

Decision Rights Operating Model

Framework · 2 min read

AI changes what can be decided, how fast, and by whom. Without a clear allocation of decision rights, organisations drift into one of two traps: people second-guessing every machine output, or machines acting beyond the boundaries anyone agreed.

Four layers of decision

Decision rights are best described as layers rather than job titles. Each layer answers a different kind of question, and each carries a different tolerance for being wrong.

1. Strategic — executives and the board decide which markets to enter, which capabilities to build, and what the organisation will not automate at all.
2. Tactical — business unit leads decide which use cases to pursue, how to sequence them, and where the resources come from.
3. Operational — systems operate with human review, making day-to-day adjustments where a person can see and override the output.
4. Autonomous — systems act alone, but only within narrow, reversible, well-bounded actions inside agreed guardrails.

The value of writing these layers down is that it forces a conversation most organisations avoid: what does the machine decide, and what does a person decide? Naming a layer for each decision removes the ambiguity that otherwise produces either paralysis or overreach.

Designing the guardrails

The layers are confidence bands, not seniority bands. A decision moves downward as the evidence, the guardrails, and the reversibility improve. A recommendation model earns operational rights long before it earns autonomous rights, and it should have to demonstrate them.

An autonomous decision is only defensible if someone can state its boundaries in plain language: what it may act on, at what value threshold, with what reversal, and what triggers escalation to a person. Where those boundaries cannot be written down, the decision belongs higher up the stack. Reversibility is the most useful single test — if an action can be undone cheaply, it can be delegated further down; if it cannot, it should not be delegated at all.

Guardrails are not only technical limits. They are also the organisational answer to who is answerable when an automated action causes harm. That answer should be a role, not a system, because a system cannot be accountable for itself. The people who set the boundaries can be.

• Name the decision, not the tool — rights attach to actions such as "approve a maintenance window", not to "use AI".
• Set thresholds explicitly — value, risk, and reversibility limits written down and reviewed on a schedule.
• Log every autonomous action with its reasoning, so it can be audited after the fact.
• Provide an override a person can exercise in the moment, and a route to change the rule itself.

Questions to ask

• Which decisions today have no named owner at all?
• What evidence moved a decision from human review to autonomous, and who signed it off?
• What is the reversal path if an autonomous action is wrong?
• Who reviews the log, and how often?

AI Operating Models for Industry

Practical guide · 3 min read

Most organisations adopting AI are not building frontier models. They run plants, depots, service operations, and back offices with a handful of specialists and no appetite for a large central team. The operating model that works here is deliberately small: one workflow, one owner, staged expansion, and governance that grows with use.

Start narrow, prove it, then widen

The temptation is to launch a programme. A programme invites a steering committee, a vendor, a platform decision, and a twelve-month plan before anything works. The alternative is to pick a single process with a measurable cost — a quoting step, a scheduling bottleneck, a repetitive compliance check — and improve it with the least technology that will move the number. Success is a solved problem, not a deployed tool.

Specialist headcount is scarce, so the practical model borrows capability rather than hiring for it. A single internal owner — often someone with operational credibility rather than a data title — coordinates with outside help for infrastructure and integration. The internal role is not to build models; it is to know the process well enough to judge whether an output is right, and to keep the work connected to the business rather than to the technology.

Staged adoption is not timidity. It is the recognition that the constraint is rarely the technology and usually the organisation's capacity to absorb change. A second use case built on the pattern of the first costs a fraction of the first; a fifth attempted before the first has settled produces five half-finished efforts and no credible result.

Governance that fits the headcount

Governance for a lean organisation is a document and a habit, not a committee. A one-page decision log records what was trialled, what it produced, and what was concluded. Data access rules are simple and written down. A short monthly review checks the log, approves the next step, and retires anything that is not working. This is enough to answer most audit and customer questions, and it grows naturally as adoption widens.

The decision log does more than record. It becomes the institution's memory of what it tried, which is exactly what a growing organisation loses first when the people who ran the early pilots move on.

• One workflow first — choose a process where the pain is measurable and the fix is reversible.
• One accountable owner — operational credibility matters more than a technical job title.
• Borrow, do not build, the platform — buy or partner for infrastructure and keep judgement in-house.
• Grow governance with use — start with a decision log and add formal review only when volume demands it.
• Retire openly — stopping a use case that does not work is a result, not a failure.

Questions to ask

• Which single process, if improved, would be felt most clearly by the business?
• Who inside the organisation can tell whether the output is right?
• What is the smallest technology change that would move the metric?
• What will you stop doing if the pilot does not deliver?

Change Management for AI Adoption

Strategy · 2 min read

AI adoption rarely fails on the model. It fails in the gap between a working demonstration and a changed way of working. Closing that gap is a leadership task, not a technology one, and it is won or lost in the first few months.

Lead visibly, communicate honestly

Visible sponsorship means the people accountable for the operation — not the technology function — are seen using and defending the change. When a plant manager or a service director can describe why a workflow changed and what it means for the team, resistance falls away. Silence from leadership is read as doubt.

Communicate about jobs plainly. People can work with change they understand; they struggle with ambiguity. If a task is being reduced or removed, say so and describe what replaces it. If a role is being reshaped, describe the new responsibilities. Vague reassurance creates more anxiety than a candid account, because people fill the silence with their own worst assumptions.

Honesty also covers what the organisation does not yet know. Where the effect on a role is genuinely unclear, say that it is unclear and describe how the organisation will decide and communicate. Claiming a certainty that will not hold for six months damages trust more than an honest, bounded acknowledgement of uncertainty.

Win early, then make it routine

Early wins build credibility faster than any business case. Choose a first use case where the improvement is visible to the people doing the work, not only to a dashboard. Then embed the change: update the standard operating procedure, train new joiners in the AI-assisted way, and make the new process the default rather than an option. Changes that remain optional quietly disappear.

The hardest moment is the plateau after the early win, when novelty has faded and the old way is still easier. That is where embedding earns its keep: if the new process sits in the procedure, in the training, and in how performance is measured, it survives the dip. If it depends on enthusiasm alone, it does not.

• Sponsor from operations — the change is led by the process owner, with technology in support.
• Be specific about impact — name the tasks that change and the skills that matter more.
• Start where the improvement is visible to the people affected, not just to management.
• Embed, do not announce — update procedures, training, and incentives so the new way sticks.
• Keep a feedback loop — a standing channel for the front line, with visible responses.

Questions to ask

• Is the visible sponsor from the business, or from technology?
• What have we told people about the effect on their roles?
• Which early win will the front line see for themselves?
• How is the new way embedded in procedures, training, and incentives?