Executive Summary
You seem to be stuck with two unappealing choices for structuring your data team: a central team that’s become a bottleneck, or embedded analysts who all seem to be working from different numbers.
A central team can slow things down and leave business teams feeling unsupported. An embedded model, on the other hand, often leads to a loss of trust in the data, with too much time spent in meetings debating whose figures are right.
The way forward isn’t to pick one, but to change the underlying system. It’s more about architecture than headcount. A hybrid approach, with a central ‘Platform’ team managing the core data and enabling specialists in the business units, seems to work best.
The usual tension between speed and control
If you're a COO in a growing business, this probably feels familiar. Your Head of Sales wants an analyst in their team, someone who really understands the CRM and can get answers quickly. They are arguing for speed.
Your CFO, meanwhile, is understandably nervous. They need consistent, auditable numbers for the board. They know what can happen when each department has its own analyst and its own definition of ‘revenue’. They are arguing for control.
They are both right. And being forced to choose between these two is often a sign that the underlying structure isn't quite right. You may have invested a good deal in the modern data stack, but all you’ve done is move the same problems to a new, faster system. Automating a messy process just means you produce confusing data more quickly. The debate about team structure is often a distraction from the real issue: you don't have a coherent Data Strategy.
Why the purely centralised and embedded models don't scale
I've seen this pattern quite a few times in companies around the Series B to D stage. They tend to switch between the two models, restructuring every 18 months or so, and good people often leave. This happens because they're often looking at the wrong problem. The issue isn't usually the people, it's the system they have to work in.
The problem with a purely central team
On paper, a single, central data team seems sensible. It should ensure consistency and control. In practice, it often turns into a service desk. The team can become a bit disconnected from what's happening on the ground in the business units they're meant to be helping. They don't always have the commercial context, so their reports can be technically correct, but not all that useful for making decisions.
This structure almost always creates a Data Engineering Bottleneck. The list of ad-hoc requests gets longer, business users get frustrated, and a bit of an 'us and them' culture can develop. Before you know it, people start keeping their own spreadsheets on the side, and you’re back where you started, only now you're paying for a data team that people work around.
The problem with a purely embedded team
Frustrated by the central bottleneck, companies often swing the other way and embed analysts directly into departments. This solves the problem of speed and context, but it creates a different, and arguably more serious, problem: you no longer have a single, agreed Single Source of Truth.
Marketing's analyst defines an 'Active User' one way, and Product defines it another. Finance has a third definition. Board meetings can become quite difficult, with senior people arguing over whose dashboard is showing the right numbers. This isn't just inefficient, it's a real failure of governance. Without solid, central Data Governance, your decentralised model is just a kind of organised chaos.
A hybrid model: the Platform and Domain approach
In my experience, the model that tends to work as a company grows is a hybrid one. It’s not just splitting the difference, it's a specific architectural decision that balances the need for speed with the need for trust.
1. The central 'Platform' team
This is a small, senior team. Their job isn't to build reports. They are there to build and maintain the foundations. Their responsibilities are:
Their main customer isn't the CEO, it's the specialist in the business team.
2. The embedded 'Domain Champions'
These are your analysts, but their role is slightly different. They sit inside the business functions (Marketing, Ops, Product) and have a deep understanding of their area. They use the trusted, clean data provided by the Platform team to build their own dashboards and analyses.
This structure gives them what they need to deliver insights quickly, which allows for proper Self-serve Analytics. They can answer 80% of their department's questions without needing to file a ticket with the central team, because the foundations they're building on are solid.
What this change actually involves
This isn't just a change to the org chart. It requires a shift in culture. The Platform team needs to get comfortable with not building the final report. They have to see themselves as enablers rather than gatekeepers. The Domain Champions have to accept that they can't just create their own metrics from scratch, they must build from the governed core.
This can cause a bit of friction. You might need to accept a slower pace for a few weeks to get the architecture right. You're asking people to give up their private spreadsheets, which they can be quite attached to. This is the unglamorous, difficult work that many companies put off. But it's the only way I've seen to build a data function that can grow with the business, rather than struggling to keep up.
By getting the system of work right, you move from endless debates about whose numbers are right, to a place where people can get on with their work, trusting the data. You get the speed the business needs and the control the board requires.