"If you need a 15-people data team in a company with 200 employees then something is off"

The Goal of This Newsletter:

How big should a data team be?

It’s a simple question. But in today’s age of AI agents and vibe coding, the answer has become emotionally and politically charged.

Founders and CEOs are wondering if their data function is bloated and if they should replace everyone with AI agents. Data Leaders are scrambling to defend why they need a 15-people data team in a 200-people startup. And then there's the one analytics engineer in another company - managing everything, secretly wondering: "Shouldn’t there be more of us?"

Let’s break it down.

Where This Question Comes From

I often run data audits for CEOs and CTOs of VC- or PE-backed companies. These are typically fast-growing businesses with complex data needs: e-commerce, insurance, or consumer subscription products. But I've also run data audits for multinational behemoths with 15,000 employees and 750-people in data.

These Executives have usually built a team, invested in infrastructure, and then... something doesn’t feel right. Maybe the data team is too slow. Maybe decisions are still being made on gut feeling. Maybe the impact isn't "tangible". Or maybe the CEO just looked at the org chart and asked:

"Do we really need 750 people in our data org?"

Good question. Because often… no. You don’t need that many people to run an impactful data team.

I've built and run “first data teams” for many companies between 50 and 200 people. And I often do it alone. As in: I personally act as the only data person for 9-12 months. On 1 to 1.5 days per week.

And no, I’m not saying this to brag. I’m saying this because:

If one person, part-time, can cover your data needs, maybe the problem isn’t how few people you have. Maybe the problem is how the team is set up.

So let’s dig into that.

The Framework: A Practical Way to Size Your Data Team

Here’s the simplified version of the framework I use to benchmark and size data teams during audits:

Step 1: Convert Stakeholders Into Team Roles Using Ratios

You don’t start by asking how many analysts you should have. You start by looking at how many real data users you have inside the company: people who engage with data to make decisions, use dashboards, run reports, or use data tools.

Let's say there are 200 people in the company and let's assume that all of them will work with data (a simplified assumption). 

You will have something like this:

• 173 Users = business decision makers who only consume data & analytics content
• Ca. 17 Super Users = business decision makers who can independently create simple analyses and reports → 1 Super User serves ca. 10 Users
• Ca. 6 Analysts / Data Scientists = data people who can create complex analyses and reports) → Ratio Super Users to Analyst of 3:1 - 2:1
• Ca. 2 Analytics Engineers = data people who can transform raw data into data that’s useable for analytical use cases → Ratio Analysts to Analytics Engineers of 3:1 - 2:1
• 1 Data Engineer / ML Engineer = data person who provides the technical platform for the analytics engineers and data scientists → Ratio Analytics Engineers to Data Engineers of 2:1 - 1.5 - 1
• 1-2 Data Product Managers = data person who acts as the glue between analytics engineers and analysts or between analysts and super users, depending on how the team is structured

That's a maximum of 11 people in a data team for a 200 people org.

Generally, a data team size of 5% relative to the org size is something that I have observed to be relatively common across many projects and conversations with other data leaders. 

Step 2: Adjust Ratios Based on Key Factors That Inflate or Deflate Headcount Need

The ratios above are your baseline. But that number will need to go up or down depending on your specific context.

These are the most common factors I use to adjust that number:

⚙️ 1. Technical Debt and Strength of Foundations

This is by far the biggest inflator of team size.

If your data foundation is weak, you’ll need more people to babysit it.

Examples:

• Single Source of Truth
• Maturity of Self-Service
• Data Modeling Best Practices
• Data Engineering Best Practices (e.g. version control, test-driven development, environment separation)
• Data Governance

More foundational debt = more humans doing janitorial work.

In my ​masterclass From Dashboard Factory to Strategic Partner​ I am sharing all my secrets and frameworks that helped me build the foundations that sets up the data team for success and business impact. 

🧠 2. Business Complexity

Complexity isn’t about company size, it’s about data needs.

A 70-person consumer startup might need more data support than a 300-person B2B enterprise.

Indicators of high complexity:

• Multiple acquisition channels
• High customer volume
• Advanced funnel tracking
• Ongoing experimentation
• Pricing and LTV optimization

🏗️ 3. Organizational Debt

Companies with M&A history or fragmented orgs often have multiple data cultures and stacks.

This means:

• Parallel systems that haven’t been merged
• Different teams using different definitions
• Historical teams who are still deeply embedded and politically untouchable

In these cases, even if you should be able to consolidate, the reality is messier. You’ll likely carry a higher headcount, at least temporarily.

🤖 4. AI Maturity

Let’s get to the sensitive part: AI is reducing demand of data analysts.

But it’s not replacing the data team - it’s changing its shape.

Here’s the shift I’m already seeing:

• Analysts ↓ (AI agents start to handle basic queries and reporting)
• Super Users ↑ (AI is helping Super Users to move closer to the data)
• Analytics Engineers ↑ (They configure, QA, and maintain AI-driven systems, such as conversational analytics)

The Bottom Line

Forget vanity metrics like “one analyst per 50 employees” or “every team needs a dedicated data person.”

Instead, build from the ground up:

1. Count the real data users in your company
2. Define Roles
3. Apply Ratios per role
4. Adjust the ratios based on:

• Technical debt & Foundational Strength
• Business complexity
• Organizational legacy
• AI tooling maturity

That gives you a tailored, grounded, and defensible number.

And yes, that number will often be much lower than expected.

If your data team is bigger than 5% of total headcount, something is probably off. It’s worth asking if your team is sized for reality… or for past decisions that no longer hold up.

I hope I was able to tackle this sensitive topic in a nuanced way. If you have feedback or want to share your own experience, feel free to reply to this email. I would love to hear your thoughts.

See you next week!

Sebastian