Analytics Was Never About Tools

Why the tool centric mindset is completely misguided.

Before I get into this week’s essay I have a little request.

I’m updating my book Minimum Viable SQL Patterns and I need your help. I’ve set up a brand new DuckDB database and have updated all the code listings accordingly. So I need some help verifying that the setup works and of course editing the book. If you’re interested, please reply to this email and let me know.

Now back to this week’s post.

The more I think about metric trees, dashboard trees, data stacks and cloud data platforms the more I realize we’ve been focusing on the wrong things. Analytics was never about tools.

The “tool centric” mindset traces its roots unsurprisingly to data vendors. If a vendor was successful in creating a new concept — for example “self service analytics” — they undoubtedly succeeded in selling you yearly licenses in perpetuity. And once you’re locked in, good luck getting out.

Tools are just leverage for your mind to work faster. A good tool gets out of the way and lets your creativity shine. A bad tool forces you to learn complicated sequences of commands to get anything useful done.

So if it’s not about the tools, what is it about?

Analytics as a practice has been around for centuries. Dun & Bradstreet, one of the oldest data companies in the United States was founded in 1841. That’s 182 years ago!

Dun & Bradstreet traces its history to July 20, 1841, with formation of The Mercantile Agency in New York City by Lewis Tappan. Recognizing the need for a centralized credit reporting system, Tappan formed the company to create a network of correspondents who would provide reliable, objective credit information to subscribers.

Do you think they had fancy tools back then? No. The computer hadn’t even been invented yet. Did they let lack of tooling stop them? No. They wrote stuff down with pen and paper and did graphs by hand. And they’re very successful, thank you very much.

Why? Because data work is extremely valuable. But not just any data work. And that’s the crux of the matter. The point of it all.

The true purpose of data work, of extracting, collecting, transforming, modeling and visualizing data is to Curate Signal.

Whether it’s Dun & Bradstreet, credit rating agencies or the analytics department of a 10 person startup, the point of doing data work has always been to Curate Signal.

The signal you find is everything that matters. Unfortunately data teams have allowed other business functions to dictate their agenda. They’ve tried to adopt models that just don’t work, like the IT “self-service” model or the product management model.

Since the purpose of data work is to curate signal, the nature of the work is fundamentally research based. Yes the output of the work might be a report, a machine learning model or even a dashboard, but the work itself has always been about research.

Whether you’re looking to find the causes of why a key metric dropped by 20% or you’re looking for levers to drive growth, you’re doing research to curate the most important signals in the business.

Here we reach an interesting conundrum. Why is it that despite the importance of this work, data teams are dragged by everyone else to answer questions and build more dashboards?

Because they are also trying to curate signal!

Marketing, sales, customer support, operations, engineering and product are all trying to curate signals for their work. They have the business context while you have the data. They are many while you’re just one. It’s no wonder the “self service” model is so attractive: “Give them the data and let them do their own analysis.”

But do you want to be a “data help desk assistant” or do you want to have real impact in the business? Do you want someone in marketing to learn data analysis skills or would you rather learn about marketing?

The choice is yours. Go forth and curate signal.

Until next time.