Centre of Excellence vs Embedded Teams

5 min read · updated August 3, 2026

The argument is normally framed as one choice between two org charts, which is why it never resolves. There are five separate things you can centralise, they have different economics, and the sensible answer centralises some and not others.

It is not two models

A centre of excellence and embedded teams are not two designs; they are two default settings for five independent dials. When two people disagree about structure, they are usually agreeing about four dials and disagreeing about one, and naming which one ends the argument in about ten minutes.

The test for whether something should be central is not “expertise”. It is whether the thing needs to have one answer across the company, and whether the cost of producing that answer falls as more teams use it.

There is also a third default that gets proposed and then quietly dropped: a community of practice with no delivery mandate and no budget — a guild, a working group, a monthly forum. It is not a rival to the other two. It is one of the five dials below, set to “shared”, and it fails whenever it is asked to do the job of the other four. A guild cannot sign a contract, cannot say no, and cannot be a dependency, which is exactly why it survives reorganisations and exactly why it cannot substitute for a decision function.

Five things you can centralise

Dial	Description
vendor relationship	Contracts, keys, billing, negotiation, the sub-processor list. Centralises extremely well: one legal review instead of six, one commitment instead of six small ones, and one place that knows what the terms actually say. Decentralising this is how you end up with four contracts with the same vendor at four prices.
platform	The gateway, logging, cost attribution, the evaluation harness, guardrails, the secrets store. Strong economies of scale and a genuine correctness argument — a redaction bug fixed once is fixed everywhere. Centralises well, provided it is a library and a service rather than a queue.
standards and review	Policy, risk tiering, the approval path, the decision log. Must be central because the point of it is consistency; two answers to the same question is the failure mode it exists to prevent.
delivery capacity	The engineers who build the features. Centralises badly past the first two projects: the work needs domain knowledge the central team does not have, and demand arrives faster than a shared team can absorb, so the team becomes a waiting list.
knowledge	Patterns, prompts that worked, failure taxonomies, training material, the internal write-ups. Neither central nor local — it is an artefact that needs an owner and a place to live, and it decays silently when nobody owns it.

The recommendation that falls out of the table: centralise the first three, distribute the fourth, and give the fifth a named owner and a repository. That is neither of the two named models, which is the point.

How a centre of excellence fails

The characteristic failure is not incompetence. It is that a central team with delivery capacity becomes a queue, and a queue has a wait time that grows without anybody deciding it should.

The symptoms are specific and worth watching for. Product teams start describing the AI team as a dependency rather than as a partner. The backlog contains work that has been waiting long enough that its requester has stopped checking. Teams that can build something themselves quietly do, without the platform or the review — which is the same dynamic as shadow tool use one level up. And the central team spends an increasing fraction of its time on triage rather than on building.

The measurable version: a centre of excellence should report its own median and p90 wait time from request to start, the same way any service reports latency. If that number is not published, the structure has no feedback loop and the queue will grow until somebody senior complains, which is the least useful possible trigger.

How the central team is funded changes its behaviour more than its reporting line does, and it is worth deciding on purpose. Funded centrally, it is free at the point of use, so demand is unbounded and rationing happens through the queue — which is invisible and therefore unmanaged. Charged back to requesting teams, demand is self-limiting and priorities become the requesters’, but the platform work that benefits everybody and is asked for by nobody stops getting done. The workable middle is usually to fund the platform, the contracts and the review centrally, and to charge back only delivery capacity — which is the same split the dial table recommends, arrived at from the money side.

How embedded teams fail

The mirror failure is duplication that nobody can see, because each instance of it is locally reasonable.

N evaluation harnesses. Four teams each build a way to run a frozen set. None of them is bad; collectively they are three wasted quarters and four different definitions of a regression.
N vendor relationships. Separate keys, separate terms, separate rate limits, no aggregate volume, and no single person who can answer what the retention setting is.
Unattributable spend. If each team has its own account, the finance question “what did AI cost us” has no answer without a reconstruction project, which is why attribution has to be designed in rather than discovered.
Data flows that reached production unreviewed. The serious one. Nobody was hiding anything; there was simply no step at which anyone was required to look.

Note the asymmetry between the two failure modes. The centralised failure is visible — people complain about the queue. The embedded failure is invisible until an audit, an incident, or a bill. That asymmetry is the argument for centralising the review dial even in an otherwise decentralised organisation.

A quieter version of the same problem is skills. In a fully embedded model, the person who learned how the evaluation harness works, why the retrieval filter is shaped as it is, and what the vendor actually committed to, is one person on one team. Nothing is written down because there was no audience for writing it down, and the knowledge leaves when they do. This is the argument for the fifth dial having a named owner and a repository even when everything else is distributed — not a wiki nobody edits, but a small number of documents somebody is responsible for keeping true: the pattern list, the failure taxonomy, and the write-up of each project’s decisions.

Triggers for changing structure

Structure changes should be triggered by measurements rather than by reorganisations. Pick your own thresholds; publish them; check them quarterly.

MOVE DELIVERY OUT OF THE CENTRE WHEN
  p90 wait time from request to start > 6 weeks
  more than half the central team's time is triage
  a team has shipped something without the platform

MOVE SOMETHING INTO THE CENTRE WHEN
  two or more teams have built the same component
  a data flow reached production without a review
  spend cannot be attributed to a team within a day
  two teams give different answers to the same policy
    question

REVIEW THE STRUCTURE ANYWAY WHEN
  the number of teams shipping AI features doubles
  a second vendor is added
  the first regulated use case appears

One transition is common enough to name. Early on, one small central team doing everything is correct, because there is one project and the expertise does not exist anywhere else. It stops being correct at around the third or fourth simultaneous project, and the signal is almost always the wait time rather than any strategic reassessment. The move at that point is not to abolish the centre but to change what it sells: from building features to providing the platform, the contracts and the review — which is precisely the pre-approved path a governance function is supposed to run.