SeattleDataGuy’s Newsletter

SeattleDataGuy’s Newsletter

Share this post

SeattleDataGuy’s Newsletter
SeattleDataGuy’s Newsletter
How to Keep Your Data Team From Becoming a Money Pit

How to Keep Your Data Team From Becoming a Money Pit

Lessons I've Learned From Turning Around Data Teams

SeattleDataGuy
May 23, 2025
∙ Paid
24

Share this post

SeattleDataGuy’s Newsletter
SeattleDataGuy’s Newsletter
How to Keep Your Data Team From Becoming a Money Pit
1
3
Share

Hi, fellow future and current Data Leaders; Ben here 👋

Today, we are going to discuss what I’ve learned as a consultant being called in to help turn around data teams and infrastructure. Ok the first story will be one of my early mistakes.

But before we jump in, I wanted to share a bit about Estuary, a platform I've used to help make clients' data workflows easier and am an adviser for. Estuary helps teams easily move data in real-time or on a schedule, from databases and SaaS apps to data lakes and warehouses, empowering data leaders to focus on strategy and impact rather than getting bogged down by infrastructure challenges. If you want to simplify your data workflows, check them out today.

Now let’s jump into the article!


Intro

After years of consulting, one thing has become clear: most failed data projects don’t collapse because of some obscure technical flaw.

They fail because teams chase perfect architecture and never ship anything useful. Or because no one clearly owns the project. In both cases, the outcome is the same—data teams that could drive meaningful impact end up becoming expensive money pits that leadership loses faith in.

So in this post, I want to share a few lessons I’ve learned (sometimes the hard way) from helping data teams get back on track. Lessons about delivery, ownership, prioritization, and, ultimately, driving outcomes.

1) Outputs Don’t Equal Outcomes

Let’s start by talking about a mistake I made early on in my career before I was the consultant. When I landed my first technical job, I came ready to prove myself. I had spent so much time learning every tool I could get my hands on: D3.js, Tableau, SSIS, Python, C#, Java, SQL Server, Hadoop, etc.

So when I was asked to build dashboards, I went all in. I built a dozen dashboards covering everything from operations to invoicing.

Guess what changed?

Nothing.

The dashboards were technically sound, but none of them were connected to a meaningful business outcome. No one’s workflow got easier. No decisions got better. I was shipping outputs, not delivering impact.

That was a wake-up call.

Eventually, a consultant came in and helped me reframe my approach. Two big shifts made a difference:

  1. Building dashboards that were actually easy to read and use

  2. Engaging stakeholders and actually delivering

It’s not about how many dashboards you can ship. It’s about whether what you’ve built actually helps someone do their job better.

SeattleDataGuy’s Newsletter is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Keep reading with a 7-day free trial

Subscribe to SeattleDataGuy’s Newsletter to keep reading this post and get 7 days of free access to the full post archives.

Already a paid subscriber? Sign in
© 2025 SeattleDataGuy
Privacy ∙ Terms ∙ Collection notice
Start writingGet the app
Substack is the home for great culture

Share