Data TeamsUpdated April 2026 • 2 min read

The Solve When Building a Data Team

The real problem when building a data team isn't hiring—it's what you hire for.

Author: Edward Chenard
Updated April 2026

Building a data team isn't a hiring problem. It's an architecture problem. Most companies hire a bunch of data engineers and analysts, throw them at the business, and wonder why nothing changes.

Sound familiar? There's a framework for building a data org that I think nails it. Not by title inflation, but by function: Users → Business decision makers consuming reports and analyses.

Super Users → Business people who don't just consume data, they create simple data products for their own teams. Analysts → The ones building complex data products that get published company-wide. Analytics Engineers / Data Scientists → Transforming raw data into actual business objects.

Data Engineers / ML Engineers → The foundation. Integrating sources, building the platform everyone else stands on. There's a spectrum at play.

As you move up, business understanding increases. As you move down, technical understanding increases. The magic happens in the middle where those worlds collide.

But the real insight? It's the three operating models. Semi-centralized → Best setup to get started.

Easiest to implement. Don't overlook the Super Users here, they're your secret weapon for adoption. Hub & Spoke → The most mature setup.

But pay attention to the ratios. 10:1 users to super users. 3:1 super users to analysts.

2:1 analysts to analytics engineers. 1.5:1 analytics engineers to data engineers. Those ratios exist for a reason.

Ignore them and you'll either starve the business of insights or drown your engineers in requests. Mesh → The hardest to pull off. Introduce it iteratively.

If you try to go mesh on day one, you're going to have a bad time. The part most orgs miss? The PM and PO roles.

A Product Manager on the business side communicating data needs. A Product Owner on the data side translating those needs into data products. Without that bridge, you get a data team building things nobody asked for and a business side complaining data never delivers.

Information without transformation is just entertainment. Same applies here. A data org without the right structure is just a cost center waiting to be questioned.

What model is your data org running? And more importantly, is it the right one for where you are today? Looking for someone to build your data team?

I can help. DM and lets discuss.

Related Reading

Continue with related frameworks and blueprints.