How to structure an analytics team

There is no structure that is right at every company size, and the structure that served a fifty-person company well is often the one holding back the five-hundred-person version of the same company. The three common models — centralised, embedded, and hub-and-spoke — trade off consistency against responsiveness, and most organizations move through more than one of them as they grow. This guide is about choosing deliberately and recognizing the signals that say it is time to change, not about declaring one model universally best.

Centralised: one team, shared standards

Every analyst reports into a single analytics or data function, which takes requests from across the business. Standards, tooling and metric definitions are consistent by default because one team maintains all of them — there is no version of "revenue" from marketing that disagrees with finance's, because the same team built both.

The cost is distance from the business. A centralized team is often one step removed from the day-to-day context of the stakeholders it serves, and prioritization becomes a queue: whichever team shouts loudest, or whoever has the best relationship with the analytics lead, gets served first. This model works best at small to mid-size companies, or in businesses where consistency and control matter more than speed — heavily regulated industries, or companies with a small number of high-stakes decisions rather than many fast ones.

Embedded: analysts live inside the business unit

Each function — marketing, product, finance — has its own analyst or small analytics team, reporting into that function's leadership rather than into a central data organization. Turnaround is fast and context is deep: an embedded marketing analyst sits in marketing's meetings, understands its campaigns, and does not need a ticket to answer a question the team already discussed that morning.

The cost is exactly what centralisation avoids: definitions drift. Marketing's "customer," product's "active user" and finance's "revenue" quietly diverge because each team optimizes its own numbers for its own purposes, and nobody outside that team reviews the logic. Career growth for embedded analysts is also harder — a team of one has no peer group, no shared code review, and often no path upward except leaving the function entirely. This model fits organizations large enough to afford dedicated analysts per function, where speed and deep context matter more than cross-functional consistency, and where a metrics layer or governance function (see how to build a metrics layer and how to establish data governance) can hold definitions consistent without requiring one team to build everything.

Hub-and-spoke: the middle path

A central hub owns infrastructure, standards, the semantic layer and shared tooling; embedded "spoke" analysts sit inside business units for day-to-day requests but are managed, trained and held to shared standards by the hub. This is the most common model at companies past a certain scale, because it captures most of each pure model's benefit: definitions and tooling stay centrally governed, while responsiveness stays close to the business.

It is also the hardest to run well. Dual reporting lines (a spoke analyst answering to both a business unit lead and the hub) create real tension over prioritization, and the hub can atrophy into either a bureaucratic gatekeeper that spokes route around, or a service desk with no actual authority over standards. Making it work requires clarity, in writing, about what the hub controls (data infrastructure, metric definitions, tooling standards) versus what spokes control (which questions to prioritize, how to present findings to their business unit).

The roles that make any model work

Regardless of structure, two roles matter disproportionately:

• An analytics translator — someone who can sit in a business conversation and turn a vague question ("why did sales dip") into an analyzable one, and then turn a statistical answer back into a business recommendation. Without this role, technically correct analysis regularly fails to change a decision because nobody translated it.
• A single accountable owner for data strategy — at larger organizations this is a chief data officer or equivalent; at smaller ones it can be a single analytics lead — someone who can arbitrate the standards-versus-speed tension the models above are all managing.

An analytics center of excellence — a small group that sets standards, trains analysts across the organization and curates reusable assets like query templates and dashboard patterns — can support any of the three structures; it is a set of practices, not a fourth org chart. It works best as a lightweight function analysts rotate through part-time rather than a permanent department competing with the delivery teams for headcount; the moment it starts approving or blocking work rather than supporting it, it has effectively become a second centralised team by another name.

Signals that say it is time to change

• From centralised to hub-and-spoke or embedded: requests routinely wait weeks; business units start building their own shadow analytics with spreadsheets because the central team cannot keep up.
• From embedded back toward a hub: two teams present conflicting numbers for the same metric to the same executive; analysts feel isolated and start leaving; nobody can name who owns the definition of a company-wide metric.
• From hub-and-spoke to something simpler: the dual-reporting tension consumes more management time than the model saves in speed and consistency combined — a sign the organization may be too small for the coordination overhead this model requires.

Practical starting point

Below roughly fifty people who touch data regularly, start centralised — the coordination cost of any other model exceeds its benefit at that scale. Move toward hub-and-spoke as business units grow large enough to need dedicated attention and the central team cannot serve all of them promptly. Reserve fully embedded structures for large, mature organizations where data literacy and data governance are already strong enough to hold definitions consistent without central enforcement.

What a working structure looks like, regardless of model

Whichever model you run, a few outcomes should hold true if it is actually working: a new stakeholder request gets an initial response within days, not weeks; two people asked to define the same core metric give the same answer; analysts have a peer group for code review and career growth rather than working in permanent isolation; and there is a clear, known answer to "who do I ask" for any major dataset. When one of these breaks down consistently, that is usually a structural signal before it is a hiring or tooling problem — adding headcount to a structure that is mismatched to the company's size or shape rarely fixes the underlying friction.

For the people side of this decision, see how to hire your first data person and analyst vs analytics engineer vs data engineer vs data scientist.