How to Structure a Data Team | 2026 Organisational Models

How to Structure a Data Team – a Guide

I sat down with Adam Li, who leads data and analytics talent placements at Salient, to talk about a question that comes up in almost every one of his client calls: how do you actually structure a data team? Not the org-chart-for-the-board-deck version. The real answer — the one that determines whether your Head of Data quits in a year or builds something that lasts.

Adam’s been doing this long enough to know what works and what doesn’t. “Most founders get the sequencing backwards,” he told me early in our conversation, before I’d even properly asked. “They hire a data scientist when what they need is someone to stop their pipelines falling over at 2 am.”

We talked for the better part of an hour. Here’s most of it, lightly cleaned up.

“There’s no best model. There’s a model that’s right for right now.”

I asked Adam to walk me through the standard frameworks on how to structure a data team — centralised, decentralised, hub and spoke, data mesh — the ones that show up in every LinkedIn carousel about data team organisational structure. He was happy to, but with a caveat that I think matters more than the frameworks themselves.

“People treat these like a menu where you pick your favourite,” he said. “It’s not that. It’s a maturity curve. You will probably move through two or three of these in the life of one company, and the mistake I see constantly is leaders picking the model that sounds impressive rather than the one that fits their headcount.”

Centralised.

Everyone — Engineers, analysts, scientists — sits under one data leader. Requests come in as tickets. Adam’s take: “It’s the right call under about a hundred people, full stop. You get one source of truth, consistent code quality, no one arguing over whose revenue number is correct. The catch is it doesn’t scale gracefully. The queue gets long, and long queues are how you end up with a VP of Sales building their own spreadsheet because they got tired of waiting three weeks for a dashboard.”

Decentralised, or Embedded.

Analysts get hired straight into Marketing, Product, Finance — wherever the noise is loudest — and report to those business heads. “Speed is the whole pitch here,” Adam said, “and it delivers on that. What it doesn’t tell you upfront is that in eighteen months you’ll have three different definitions of ‘customer lifetime value’ floating around the business, and nobody remembers agreeing to any of them.”

Hub and Spoke.

This is the one Adam pushes hardest for mid-sized scaleups, and he was more animated talking about this than either of the first two. “The hub owns the platform — engineering, governance, the boring infrastructure nobody thanks you for. The spokes are embedded analysts sitting inside Product or Revenue, close enough to the business to actually get invited to the meetings that matter. It’s the model I’d default to for almost any company between, say, 150 and a thousand people, and I’ll be the first to admit that’s a very Salient answer — it’s what we place the most on, because it’s what actually works at that size.”

Data Mesh.

Reserved, in his view, almost exclusively for genuinely large enterprises. “I’ve seen companies at three hundred people try to implement a full federated data mesh because they read about it working at Spotify. It’s not for you yet. It requires a level of platform self-service tooling most companies haven’t built, and honestly most companies never need it — they plateau at hub and spoke and that’s completely fine.”

Here’s the visual he sketched out for me on a notepad, which I’ve kept roughly intact:

Centralised                Decentralised (Embedded)          Hybrid (Hub & Spoke)               Federated (Data Mesh)

┌─────────────────┐       ┌───────────┬───────────┐         ┌────────────────────┐            ┌───────────────────────┐

│ Central Data    │       │ Sales     │ Marketing │         │    Central Hub     │            │ Domain Data Products  │

│ Team            │       │ Analyst   │ Analyst   │         │ (Infra & Gov)      │            │ (Sales, Product, Risk)│

└────────┬────────┘       └───────────┴───────────┘         └─────────┬──────────┘            └───────────┬───────────┘

│                                                            │                                   │

┌─────┴─────┐                                                ┌─────┴─────┐                     ┌───────┴───────┐

│ Business  │                                                ▼           ▼                     ▼               ▼

│ Units     │                                             Embedded    Embedded            Self-Serve      Self-Serve

└───────────┘                                             Analyst     Analyst             Platform        Platform

(Sales)    (Product)            Infrastructure  Governance

How to Structure a Data Team: Three Things That Actually Go Wrong

I asked Adam what a badly structured data team looks like from the outside, before anyone admits there’s a problem. He didn’t need to think about it.

“The central bottleneck is the classic one. Someone in Finance asks a simple question and it takes three weeks, so they build a shadow spreadsheet, and now you’ve got two versions of the truth in the building and nobody trusts either.” He paused. “Then there’s the metrics fight — Marketing’s conversion rate and Finance’s conversion rate are calculated differently and nobody notices until a board meeting, which is a genuinely terrible time to notice.”

The third one surprised me a little, mostly because it’s less talked about. “FinOps leakage. Duplicate pipelines. Every embedded analyst spinning up their own compute because nobody’s coordinating, and suddenly the Snowflake bill has tripled and no one can point to what it bought you.” He shrugged. “It’s not glamorous, but it’s the one that gets a CFO’s attention fastest.”

How to Structure a Data Team: Who to Hire, and In What Order

This is where Adam got most specific, and I got the sense it’s the part of the conversation he has most often — because it’s the part people get wrong most expensively.

“The single biggest mistake I watch founders make is hiring a data scientist first,” he said. “It feels ambitious. It sounds like you’re doing ‘AI.’ But without a clean pipeline behind them, that person spends most of their week doing data janitorial work instead of anything predictive. It’s an expensive way to clean spreadsheets.”

His recommended sequence, roughly:

Phase 1 — Foundation (0–100 people).

A senior data engineer or analytics engineer first, to stand up the warehouse — Snowflake or BigQuery — and get raw data into a state anyone can trust. Then a commercial data analyst, someone who can sit with executives and produce the one dashboard everyone agrees is correct.

Phase 2 — Scaling (100–500 people).

An analytics engineer to formalise the dbt models. Embedded analysts pushed out into Product, Growth, Finance. And, Adam said, “somewhere in here you need a Head of Data or CDO — not before, because there’s nothing to lead yet, but you’ll feel the gap the moment you’re past this point.”

Phase 3 — Advanced (500+ people).

ML and AI engineers, governance and risk leads. “This is where it gets genuinely technical and genuinely political in equal measure,” he said, and left it there.

Here’s the role breakdown as he described it — this is the version I’d hand a founder who asked me to explain the stack in one table:

He was particularly insistent on one point I hadn’t heard framed quite this way before: “The analytics engineer is the hire everyone underrates. That role is the hinge between the backend engineers and the business. Get that wrong, and your data engineers end up doing dashboard work they hate, or your analysts end up writing pipeline code they shouldn’t be trusted with.”

How Do You Know It’s Actually Working?

I asked what he tells clients to actually measure, once the team exists and the org chart looks tidy. Structure on paper is one thing; knowing whether it’s paying off is another.

He gave me four, more or less off the top of his head:

• Time-to-insight — how long from a business question landing to an accurate answer arriving.
• Trust in the numbers — are leaders using the dashboard, or quietly rebuilding it in Excel because they don’t believe it?
• FinOps efficiency — is cloud spend growing in line with the business, or faster than it, for no clear reason?
• Self-service adoption — what share of non-technical people can answer their own questions without filing a ticket?

“Honestly, that last one is the tell,” he said. “If your business users still can’t self-serve after two years of investment, something upstream is broken — usually the structure, not the tooling.”

How to Structure a Data Team: Where This Gets Hard

I’ll be honest — I went in expecting Adam to give me a tidy “here’s the framework” answer, and what I got instead was closer to “it depends, but here’s how to think about it,” which is less punchy but probably more useful. He was clear that none of this is really about org charts. It’s about sequencing and trust — building the boring infrastructure before the exciting roles, and being honest with yourself about which stage your company is actually at, rather than the stage you’d like to be at.

If there’s a thread running through the whole conversation, it’s this: the model matters less than most people think, and the hiring order matters more.

For companies trying to build or rebuild this function, Adam and the team at Salient work as a specialised data recruitment agency. We place talent from contract data engineers through to CDO-level executive search across Australia and APAC — which is, unsurprisingly, most of what our conversation kept circling back to.

Ready to build your next tech team? We’ll be in touch within 24 hours. Reach out!