I have now spent about 17 years building and leading data teams.

During that time, I have supported almost 100 startups and scaleups to build their first data team and infrastructure.

I have also audited dozens of data teams and helped multiple large corporations create more business impact with their data teams.

During that time, I have made every possible mistake you can make.

Stepped in every possible trap that you can step in.

But every misstep taught me valuable lessons.

Today, I want to share with you my 8 most powerful learnings.

Let’s go:

1 Data Leaders must be able to think like Product Managers.

When building my first data team at Rocket Internet - then the world’s largest venture builder - I was doing so with the mindset of a technician.

Today, I am convinced that data leaders must approach building their data team with the mindset of a product manager.

As a technician, I approached building the team and the data infrastructure at Rocket Internet with a solution in mind.

• I started by writing a long concept document
• I evaluated vendors
• I integrated lots of data sources
• I designed data models
• And I built dashboards

A product manager builds things with the user and the user’s challenges in mind.

• They start by talking to users
• Learn interview techniques to understand which user challenges are worth solving
• Focus on the problem before building a solution.

To the technician, the data infrastructure is the product.

To the product manager, the data team is the product.

This mindset shift is the key to creating business impact with your data team.

2 Data Modeling best practices are the foundation of data-driven decision-making.

Feeling pressured to deliver insights rapidly, many first-time data leaders forget about data modeling.

This approach will always fail - sooner or later.

During 80% of my data audits, data teams struggled because they failed to apply data modeling best practices early on.

Many first-time data leaders also overestimate the effort to set up a functional data model.

It’s not as complex as you might think.

You can find my detailed thoughts on data modeling ​here​.

3 Data Teams that don’t decentralize at the right time to the right extent are doomed to fail.

Centralized data teams vs decentralized data teams is not a black-or-white decision.

It’s a spectrum.

And the right approach depends a lot on the maturity of the organization.

When I started my career, all I knew were heavily centralized data teams with a central data hub carrying all data-related responsibilities.

Later, I moved to the other extreme. I started leaning towards heavily decentralized setups and implemented a data mesh at a large European retailer.

Today, I prefer a semi-centralized setup when starting the first data team - with Data Engineering, Analytics Engineering, Analyst, and Product Owner roles in a central data hub.

Usually, one person wears multiple hats in early-stage setups (for example one person takes over the role of Product Owner, Analyst, and Analytics Engineer).

A key role in this setup is the “Super User” role - a business decision-maker who uses Google Sheets to access the single source of truth data infrastructure.

Introducing this Super User Role is the first, careful step toward decentralization.

As the company matures, I usually continue decentralizing Analysts, followed by Analytics Engineers and Data Scientists.

In our ​Data Action Mentor masterclass​ - “Create massive business impact with your data team” we are diving very deep into this.

4 Excel (or better: Google Sheets) is the world’s best data & analytics tool - it’s not the enemy.

During my first data leader assignment at Rocket Internet, I tried to eliminate Excel and failed miserably.

I wanted all business stakeholders to use a data visualization tool for ad-hoc analyses and reporting.

Let's just say: Business users did not like that. And that's ok.

Today, my favorite setup allows business decision-makers to access a single source of truth in BigQuery with Google Sheets.

Since I switched to this approach, stakeholder adoption and stakeholder satisfaction with the data team went through the roof.

Our strong data modeling best practices, processes and documentation helped increase stakeholder adoption without compromising on data quality.

5 The Pareto principle applies to 99% of data challenges - 20% of the effort gets you 80% there.

This was one of the most impactful things I learned at Rocket Internet.

We often waste so much time and resources building really complicated things and overlook the simple solution sitting right in front of our faces.

Done is better than perfect!

My favorite example is when we wasted hundreds(!) of hours building a recommendation engine for our e-commerce portfolio companies and nothing worked.

We ended up building a semi-manual approach that outperformed all complex AI-driven approaches by 10x and cost a fraction to build.

6 The best first data hire in a company is an analytics engineer with a keen interest in the company’s business model.

A lot of companies who want to start becoming more “data-driven” either hire someone who is too little technical or too much.

Typical scenarios:

• A recent MBA graduate from a top university building a “Data Warehouse” in Excel
• A data engineer coming from a big bank or telco building a data vault into an early-stage startup.

Neither works.

The first data hire must be someone who can talk to business users, understand their business challenges, and build a well-designed data warehouse while utilizing data integration tooling that connects to data sources out of the box.

7 The data organization is a business unit and not a tech team.

Many Founders misuse data teams as a dashboard factory and data leaders let it happen.

As a consequence, data leaders report to the CTO and sit in the machine room.

Often, this doesn’t end well.

Data Engineering challenges are completely different from software engineering challenges and CTOs in fast-growing companies do not have the bandwidth to switch context between data engineering and software engineering.

In 90% of cases, it is best to let the data function report to a business leader.

In consumer internet scale-ups it often makes sense to let data report to the CMO, while in SaaS scale-ups it often makes sense to let data report to the CPO.

There are dozens of variables to take into account when deciding who the data function should report to but in most cases it’s best if that is a business function.

8 Data Leaders in high-growth companies need strong Mentors to survive and thrive.

Lastly, I wouldn’t be where I am today without incredible Mentors.

When I was a puppy consultant, my Mentor taught me how to become a data engineer.

When I was a puppy data leader, my Mentor taught me how to become a leader.

When I was a puppy freelance consultant, my Mentor taught me how to become a pro freelance consultant.

Now, as a puppy solopreneur, I have Mentors who guide my way.

At Data Action Mentor we are building a community of mentors who show the way to future data leaders.