How to structure your data function as you scale beyond £500m
Most organisations at this stage have data. What they do not have is a data function that scales with the business. They have analysts scattered across departments, a central team that spends most of its time on reporting, and a data infrastructure that was designed for a company half the size. The result is not a lack of information - it is too much conflicting information, too slowly, from too many sources that do not agree with each other.
The mistake most firms make at this revenue threshold is treating data structure as a technical problem. They hire a Head of Data, buy a modern data stack and wait for insight to materialise. It does not. Because the bottleneck was never technology. It was governance, ownership and the relationship between the data function and the decisions that actually drive commercial performance.
This article sets out how to structure your data function as you scale beyond £500m - the operating model, the talent architecture, the governance decisions you cannot defer and the point at which centralised control becomes a constraint rather than a protection.
The centralise-versus-federate question is the wrong starting point
Every conversation about data function structure eventually arrives at the same fork: centralise everything under a CDO, or push capability into business units and let them own their data. Most organisations spend too long debating this and too little time asking what problem they are actually trying to solve.
At £500m to £1.5bn, the real constraint is rarely organisational design. It is data literacy asymmetry. You have pockets of genuine analytical sophistication - typically in finance and ecommerce - sitting alongside business units that still run on spreadsheets and intuition. A centralised model starves the sophisticated units of speed. A federated model abandons the weaker units to poor decisions.
The answer is a hybrid model, but not the vague kind. Consider a mid-size B2B distribution business scaling from £600m to £1bn through acquisition. Their central data team owned infrastructure, data quality, definitions and tooling. Business units owned their own analysts, who were hired against a shared competency framework and reported into the business unit commercially but into the central function professionally. The central team set the rules of the road. The business units drove.
This is sometimes called a "hub and spoke" model, but that label obscures what matters: the centre has to have genuine authority over data standards, or the model collapses into data chaos within eighteen months. Federated execution without centralised standards is not federation - it is fragmentation.
What the centre must own, non-negotiably
The central data function at this scale has a specific and bounded remit. It is not responsible for every analysis the business produces. It is responsible for the things that, if left to individual business units, will produce contradictory outputs and erode confidence in data across the organisation.
There are four non-negotiables:
- Data definitions - what "customer", "revenue" and "churn" mean in your business, specified formally, documented and enforced in your semantic layer. If your CFO and your CRO cannot agree on ARR because they are pulling from different definitions, that is a governance failure, not an analytics failure.
- Data infrastructure and pipeline ownership - the central team owns the warehouse, the transformation layer and the tooling decisions. Business units consume; they do not build parallel infrastructure.
- Data quality standards and monitoring - proactive, not reactive. Not waiting for someone to notice a dashboard is wrong.
- The data product roadmap - prioritising which data assets get built, for whom and in what sequence. Without this, the central team becomes a request-fulfilment service and loses any capacity for strategic work.
Everything else - analysis, modelling, reporting, experimentation - can sit closer to the business.
The talent architecture that actually works at this scale
The mistake here is hiring for the wrong profile at the centre. Firms at this stage often recruit senior data scientists into the central function when what they need are senior data engineers and a strong analytics engineer or two. The science comes later. The foundation comes first.
A practical talent architecture for a firm in the £600m to £1.2bn range:
- Head of Data or CDO - commercially credible, able to operate at board level, technically literate but not hands-on. This person's primary job is translating business problems into data investments and protecting the function's credibility with the leadership team.
- Two to three senior data engineers - owning the warehouse, pipelines and infrastructure. These are not junior hires.
- One analytics engineer - owning the transformation layer, the semantic layer, dbt or equivalent. The person who makes sure the numbers in every dashboard derive from the same source of truth.
- Embedded analysts in business units - typically three to six across commercial, operations and finance. Hired centrally, deployed into the business.
Data science capability at this scale should largely be project-based and brought in for specific problems - pricing optimisation, demand forecasting, propensity modelling - rather than maintained as a permanent overhead in the central function. A fractional or advisory arrangement for senior data science leadership is often more effective than a full-time hire until the analytical foundations are mature enough to support it.
Governance without bureaucracy
Data governance has a reputation for producing committees, policies and very little else. At this scale, that is not just irritating - it is actively harmful. Governance overhead slows the business down and drives analytical work back into the shadows, into spreadsheets and into personal data stores that no one can audit.
Effective governance at this stage has three components and no more.
First, a data council - not a steering committee. A small group (CDO, CFO, one or two commercial leads) that meets monthly to resolve definitional disputes, approve major data investments and hold the data quality standard. Its only job is decisions. It does not review dashboards.
Second, a data contract framework - lightweight agreements between the central data team and each business unit specifying what data each unit produces, what quality standard it is held to, and who is accountable when it degrades. A private equity-backed retail group Rodan has worked with reduced their data incident resolution time by over 60% after formalising these contracts, primarily because ownership was no longer ambiguous.
Third, a documented semantic layer - not a wiki page that is eighteen months out of date, but an enforced layer in the data stack itself. When your BI tool queries "net revenue", it should be impossible to get a different number depending on who built the report.
When your current structure becomes the ceiling
There is a point, typically somewhere between £800m and £1.2bn, where the structure that got you here starts to slow you down. The central team is overwhelmed. Embedded analysts have gone native in their business units and stopped contributing to the shared data estate. The data product roadmap has collapsed into a backlog. And the CDO, if you have one, is spending more time managing relationships than building capability.
This is the moment to audit the operating model honestly, not defensively. The question is not "is our data team working hard?" - they almost certainly are. The question is "does our data function match the commercial decisions we need to make faster and better than our competitors?"
At this inflection point, many firms benefit from bringing in external perspective before restructuring internally. A structured diagnostic - examining data architecture, team capability, governance maturity and the alignment between data investment and business priority - typically surfaces the two or three decisions that will unblock the most value. It also avoids the common mistake of restructuring the team when the actual problem is the infrastructure, or rebuilding the infrastructure when the actual problem is governance.
What to do now
If your data function is producing reports but not decisions, generating insight but not action, or growing headcount without growing impact - the structure is the problem. Not the people.
The organisations that get this right between £500m and £1.5bn are the ones that treat data function design as a strategic decision, not an HR exercise. They define what the centre owns. They build the foundation before the science. They govern through standards, not committees.
The ones that get it wrong spend two or three years and significant capital on a data transformation that produces a modern tech stack, a larger team and the same quality of decision-making as before.
If you are at this stage and uncertain whether your current structure will carry you to the next revenue threshold, a diagnostic engagement is the right starting point. Rodan's data strategy diagnostics are scoped to deliver a clear structural recommendation and a prioritised roadmap within three to four weeks. Book a diagnostic with Rodan.
