The decision about how to organise the analytics function — all analysts in a central team, analysts embedded in business units, or some hybrid — has more impact on analytical output quality than almost any tooling or technology decision. Each model has different trade-offs in speed, quality, consistency, and career development. This guide covers when each model works and how to evolve between them.
The organisation of the analytics function — who reports to whom, how analysts are embedded or centralised, how work is prioritised — has more practical impact on analytical output than almost any technology decision. The same tools produce dramatically different outcomes depending on how the team using them is structured.
Three fundamental models exist, each with genuine trade-offs. Understanding the trade-offs is the prerequisite to making an organisational decision, rather than copying the structure of a company whose context is different from yours.
The Centralised Model
In a centralised analytics model, all analysts report to a central analytics function — typically a Head of Analytics or VP of Data who reports to either the CTO or CFO. Business units submit analytical requests to the central team. The central team prioritises, assigns, and delivers.
Advantages:
Consistency. Standards for data definitions, dashboard design, and methodology are enforced centrally. "Revenue" means the same thing in every report because the same team builds every report with the same definitions.
Specialisation. Analysts can develop deep expertise in specific analytical domains (statistical modelling, data visualisation, data engineering) that would be difficult to maintain in a distributed model where each analyst must be a generalist.
Knowledge sharing. Centralised analysts encounter analytical problems across the business and develop cross-domain pattern recognition. A fraud detection approach that works in the payments domain may be adapted for the returns domain.
Career development. Analysts have peers, can be mentored, and have a visible career path within the function.
Disadvantages:
Bottleneck and backlog. Every business unit competes for the same pool of analytical capacity. Backlogs grow. High-priority requests wait behind other high-priority requests. Speed to insight is slow.
Context deficit. Analysts who service multiple business units simultaneously do not develop the deep domain knowledge that makes analytical work genuinely insightful. A query that produces a technically correct answer but misses the business context in which it should be interpreted is worse than useful.
Misaligned incentives. The central team's success metrics (throughput, stakeholder satisfaction ratings) may not align with any business unit's outcomes. Analysts who are not accountable for the decisions their work informs are less likely to develop the judgment required to make that work genuinely useful.
The centralised model works well for: organisations where cross-domain analytical consistency is critical (financial reporting, regulatory submissions, corporate strategy); organisations where analytical demand is insufficient to justify embedded analysts in each business unit; and organisations where analytical maturity is low and consistent standards need to be established before distributing the function.
The Embedded Model
In an embedded model, analysts report directly to the business unit they support — sales analytics reports to the VP of Sales, product analytics reports to the VP of Product, finance analytics reports to the CFO. The Head of Analytics (if the role exists) is typically a dotted-line coordinator rather than a direct manager.
Advantages:
Domain depth. An analyst who works exclusively in one business domain develops genuine subject matter expertise. They know which metrics the business unit cares about, what questions are actually important vs what seems important in the moment, and how to frame analytical conclusions in terms the business leadership acts on.
Speed. An embedded analyst can respond to a business unit request without competing with other business units for capacity. Requests move from conception to delivery in days rather than weeks.
Accountability alignment. The embedded analyst is accountable to the business unit leadership, whose success depends on making good decisions. This creates alignment between analytical work and business outcomes.
Disadvantages:
Inconsistency. Different embedded analysts serving different business units will define metrics differently, build reports with different methodologies, and produce analyses that cannot be reconciled at the aggregate level. "Revenue" per the sales analyst and "revenue" per the finance analyst will differ, and when leadership assembles a company-wide view, the numbers will not add up.
Siloing. Embedded analysts rarely share knowledge or analytical approaches across business units. A technique developed in marketing does not transfer to supply chain because there is no mechanism for knowledge sharing.
Career development. An analyst embedded in a single business unit has limited opportunities for specialisation, mentorship, or career growth within the analytics function. They are often better described as "business analysts" than "data analysts" — their career paths diverge from analytical specialisation toward domain expertise or business leadership.
Generalist requirement. Each embedded analyst must handle the full analytical stack — data pull, analysis, visualisation, presentation — rather than specialising. This produces competent generalists but rarely exceptional specialists.
The embedded model works well for: business units with high analytical demand and specific domain requirements that a centralised team cannot meet with sufficient speed; organisations with sufficient analytical maturity that each embedded analyst can maintain standards independently; and organisations where business unit autonomy is a core value.
The Hybrid Model
Most mature analytics organisations operate some version of a hybrid model: a central analytics infrastructure team (data engineering, data platform, standards) with embedded analysts who are dotted-line connected to the central function.
The most effective hybrid structures:
**Hub-and-spoke**: a central analytics team of senior analysts and data engineers maintains the data platform, defines standards, and handles cross-domain analytical work. Domain-embedded analytics engineers and analysts report to their business unit but follow central team standards and participate in regular cross-functional knowledge sharing. The hub provides infrastructure and consistency; the spokes provide domain depth and speed.
**Competency centre + embedded**: a small central analytics competency centre sets methodology, trains analytical staff, and handles enterprise-level reporting. Analytical capacity is fully embedded in business units. The competency centre does not do production analytical work — it enables the embedded analysts to do it well.
**Federated with shared services**: analytical work is fully federated to business units, but shared services (data engineering, tooling, quality monitoring) are centrally managed. Business units own their analytical questions; the central team owns the infrastructure that answers them.
Choosing Between Models
**Centralised when**: the organisation is in early analytical maturity, where establishing consistent standards is more valuable than speed; when cross-domain analytical integration is critical; when the business units lack the domain knowledge to scope analytical work effectively.
**Embedded when**: business units have specific, well-understood analytical needs and sufficient domain knowledge to scope work; when speed is more important than cross-domain consistency; when the organisation is large enough to sustain full-time analytical capacity in each business unit.
**Hybrid when**: the organisation has reached a scale where pure centralisation creates unacceptable backlogs but pure embedding creates unacceptable inconsistency. Almost every analytical function above a certain scale ends up in some hybrid configuration.
The Evolution Path
Analytical functions almost universally evolve from centralised to hybrid to more distributed over time. The centralised phase establishes standards and infrastructure. The distributed evolution follows as business unit demand outpaces central capacity and business units accumulate domain knowledge to specify their own analytical needs.
The mistake is skipping the centralised phase. Organisations that start with distributed analytics without central standards accumulate definitional debt — inconsistent metric definitions, incompatible data models, methodological inconsistency — that is expensive to resolve later.
The second mistake is staying centralised past the point where it serves the business. A centralised team that becomes a bottleneck is failing the organisation even if it is technically excellent.
Our data architecture and BI strategy practice works with organisations to design analytics team structures that match their stage and scale — contact us to discuss your analytics operating model.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →