Hub-and-spoke data teams: the model that sounds right and works badly

The hub-and-spoke model has had a remarkable run as received wisdom. Ask any management consultant to sketch an org design for a data function in a company with more than three business units, and you will almost certainly see a circle in the middle, lines radiating outward, and some language about "embedded analysts" who report into the centre while sitting with the business. It feels like a compromise that satisfies everyone. That is precisely why it tends to fail.

The consensus view, stated fairly

The case for hub-and-spoke is genuinely coherent. Fully centralised data teams suffer from a well-documented pathology: they become a bottleneck. Business units queue for analysis, priorities get set by whoever shouts loudest or has the most political capital, and local domain knowledge atrophies because the analysts working on retail problems today will be redeployed to supply-chain next quarter. Gartner has repeatedly documented that centralised data organisations score poorly on business satisfaction, partly because cycle times are long and partly because the outputs often miss operational nuance.

Fully decentralised models solve the proximity problem but create a different one. Standards fragment. The same customer gets defined differently in three business units. A data mesh architecturedata mesh architectureData Mesh is a decentralized approach to data architecture and organization where domain teams own and serve their data as products, governed by shared standards.View full definition →, as articulated by Zhamak Dehghani in her work at Thoughtworks, tried to address this through federated ownership with central platform standards, but many organisations discovered they lacked the data engineering maturity to make self-serve infrastructure real.

Hub-and-spoke looks like the synthesis. A central team owns governance, standards, and shared infrastructure. Embedded "spoke" analysts sit inside business units and develop domain expertise. Everyone wins. The CDO retains authority; the business gets responsiveness.

Where the model breaks in practice

The problem is not with the diagram. It is with what the diagram cannot show: who actually controls the spoke analyst's time, career, and priorities.

In most implementations, the spoke analyst has two reporting lines, one solid to the business unit head or a local analytics manager, one dotted to the central CDO or head of data. In practice, the dotted line is decorative. The business unit controls salary reviews, project assignments, and the day-to-day work. Within six months, the spoke analyst has been absorbed by the business and the centre has lost meaningful influence over what that person does.

The consequence is that governance commitments made at the top of the organisation do not reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → the place where data is actually produced and consumed. A financial services company running this model might have its central team publish a data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.View full definition → policy while the spoke analysts embedded in the trading desk are building pipelines that bypass the approved data catalogue entirely, because the trading desk's timelines do not accommodate the approval process. The centre finds out when something breaks, not before.

There is also a talent problem that rarely gets named. Spoke analysts in this model tend to have worse career trajectories than their counterparts sitting fully inside the central team. The central team gets exposure to enterprise architecture, AI infrastructure, and cross-business pattern recognition. The spoke analyst becomes very good at one business unit's problems and increasingly difficult to promote or redeploy. Companies including large European banks and consumer goods multinationals have reported difficulty retaining spoke analysts after two or three years precisely for this reason. The role is neither interesting enough to keep technically ambitious people engaged nor senior enough to satisfy commercially ambitious ones.

The coordination overhead is also higher than it looks. Hub-and-spoke assumes the hub has bandwidth to actually serve the spokes: setting standards, reviewing work, maintaining shared infrastructure, running training, and resolving conflicts between business-unit data definitions. At Unilever's scale, or at a bank like BNP Paribas running data operations across twenty-odd countries, the hub becomes a second bottleneck because it is under-resourced relative to the coordination surface it is supposed to manage. MIT Sloan Management Review research on data operating models has pointed to governance capacity as a consistent constraint; organisations routinely underestimate the staffing needed to run a credible centre of excellence.

Second-order effects compound this. Because the model is presented as solving the centralisation-versus-decentralisation tension, organisations often stop iterating once they have drawn the org chart. The model becomes a political settlement rather than an operating design. Each constituency can point to the structure and claim their interests are represented. CDOs get to say they are "embedded in the business." Business unit heads get to say they have "their own" data people. Neither statement is quite true, and the ambiguity persists indefinitely because surfacing it would require someone to lose something.

What a sharp CDO should actually do

Recognise that hub-and-spoke is a transition architecture, not a destination. It can be a reasonable intermediate step when moving from a chaotic fully-decentralised state toward something more disciplined. The error is treating it as the end state.

If you are going to run it, the employment relationship has to be honest. Either the spoke analyst reports to the centre and is on assignment to the business unit, with the centre controlling career progression, compensation, and recall rights, or the spoke analyst is a business-unit employee and the centre's role is to set technical standards and provide shared tooling, not to pretend it has authority over people it does not manage. The dual-reporting fiction wastes everyone's time and creates resentment in both directions.

The hub also needs a service-level agreement written from the business unit's perspective, not the centre's. If the central governance process takes three weeks to approve a new data source, the spoke analyst will work around it. The SLA discipline forces the centre to be honest about its own capacity constraints.

Consider the data meshdata meshData Mesh is a decentralized approach to data architecture and organization where domain teams own and serve their data as products, governed by shared standards.View full definition → path seriously, but only if you have platform engineering maturity to support it. Companies like Zalando that have made federated data ownership work did so on top of years of investment in internal developer tooling and a culture where domain teams genuinely owned their production systems end-to-end. Without that foundation, data mesh is hub-and-spoke with better marketing copy.

The most durable data organisations tend to have one thing in common: clarity about where decisions actually get made, not where the org chart suggests they should be made. Draw the real decision mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → before you commit to a structure, and you will make fewer promises the model cannot keep.