Why hub-and-spoke keeps winning

Companies building an AI and data capability have to decide where the people sit, usually before they have run enough work to know: one central team, people placed in the business units, or a combination of the two. For a company with distinct business units, the combination holds up more often than either alone. What decides whether it works is which responsibilities go where.

How the capability is organized

A center of excellence keeps the specialists in one team. Standards, platform choices, and evaluation practice stay consistent, scarce skills get spread across more than one problem, and the same people can be moved to whichever unit has the strongest case. The failure mode is distance from the work: the team builds what it can see from the center, and the units do not adopt it.

Placing the people inside the units removes that distance. The work is designed next to the process it changes, and the person who asked for it is in the room. Duplication is the cost. Several teams build similar things on different stacks, there is no shared platform to inherit from, and the standards only apply inside whichever unit wrote them.

Hub-and-spoke keeps a core that owns the platform, the standards, the governance process, and the roles that are scarce and expensive to duplicate: ML engineering, MLOps, data engineering, responsible AI. Translators, analysts, and domain experts sit in the units and at the sites. The center is accountable for the tooling, the gates, and the components other teams reuse. The units choose the use cases, fund them, and are answerable for whether the output gets used.

Where the hub reports is part of the design. The results land in the business units' numbers, so the hub needs a reporting line senior enough, and close enough to the operating side, to change how work is done.

A hub reporting several layers inside IT can produce good systems that no one runs.

The embedded domain expert

Every delivery team needs at least one person who knows how the process being changed works in practice: the fraud rules in a bank, the changeover and scheduling constraints in a plant, the way exceptions get handled in a claims operation. It is the role that gets cut first when a team is under pressure, and cutting it produces systems that are correct against the specification and wrong about the work.

That person is also the one who can say which cases the system will see once it is in production, which edge cases carry real cost, and where the current process already works well enough that automating it changes nothing.

The delivery pod

The same arrangement repeats at the delivery level. One cross-functional pod owns a use case from intake through production and into run: a product owner who holds the value case, data and ML engineers, an MLOps engineer who keeps it running after release, the embedded domain expert, and a change lead responsible for adoption. Keeping the same people across the whole path avoids the loss that comes with handing a system from a build team to a run team, where the reasoning behind the design stops being written down and has to be inferred later.

Around the pod, the hub is a supplier: platform access, gate reviews on a known schedule, a funding path, and the components that already exist. By the tenth use case a larger share of the build is assembled rather than written, from feature pipelines, deployment templates, evaluation harnesses, and the gate documentation the hub maintains.