Daniel Mintz is the Chief Data Evangelist at Looker, the BI software company headquartered in Santa Cruz, Calif. Previously, he was Head of Data & Analytics at fast-growing media startup Upworthy and before that he was Director of Analytics at political group MoveOn.org. Throughout his career, Daniel has focused on how people interact with data in their everyday lives and how they can use it to get better at what they do.
icrunchdata speaks with business leaders about their careers and latest focuses. Today, Daniel discusses unlocking the value of data, the importance of company culture and the popularity of SQL.
I think we're at an inflection point. We're well into the "big data revolution," but the promised benefits have (mostly) not materialized. And so companies are starting to ask why. And they're right to.
But the answer isn't that there isn't value there. It's that you don't get value simply by making your data "big." And I think companies are realizing that there is enormous value in their data, but that the methods they're using aren't unlocking that value. They've realized that pairing a modern data warehouse with a 20-year-old analytics platform with a 50-year-old way of doing business isn't going to be revolutionary.
And I think that's where Looker comes in. We're modern software built specifically to take advantage of today's fast, cheap datastores. And we're built to let anyone in the company ask questions of data and get reliable, trustworthy answers. And so that lets people change not just their database technology, but their analytics platforms and their cultures. And that allows them to access the value they knew was there all along.
It's hard to overstate how critical culture is to being data-driven. That's not to underplay the tools and the technology, of course, but I've seen lots of companies that have the tools in place but are still doing things in the same ways as before they had the data available. The reason is that being data-driven, or as I prefer to call it "data-informed,” is a completely different way of working.
For most of history, companies have made decisions based on HiPPO (the Highest Paid Person's Opinion). But with the advent of operational data, they can instead use data to inform their decision. This means that the highest-paid person in the room needs to relinquish their power to make the decision, and it means that everyone needs to be deeply humble.
Making decisions in a data-informed way means being humble enough to say "Wow, I never would have predicted that, but now that I know I was wrong, I guess I'll change the plan." And that's all about culture.
As an analyst, SQL is wonderful. It's incredibly versatile and powerful. And it's proven – it’s been around for 40+ years. It also mirrors the way that analysts think about problems, which I think is at the root of our love for it.
But SQL has historically been tied to the underlying RDBMS systems that it developed with. So when data volumes outgrew what RDBMSs could reasonably handle and companies started using the Hadoop ecosystem, they didn't initially bring SQL along with them. But with projects like Hive and SparkSQL, I think you're seeing that SQL remains the right tool for analysis, and it's worth bringing it to the Hadoop ecosystem.
Now, we've got the explosion of columnar datastores like Redshift, BigQuery, Snowflake and Vertica, all of which use SQL. So, I don't see anything taking SQL's place as the lingua franca for data analysis in the foreseeable future. That said, there are some serious limitations built into SQL. It's not reusable, it's impossible to keep organized, and it's effectively "write-only"– I regularly rewrite queries from scratch rather than trying to figure out what I was thinking when I wrote queries even a week or two ago.
So what we've done with LookML (which is Looker's modeling layer) is to keep all the great stuff about SQL, but solve some of its problems. Just like with any programming language, SQL needs to evolve by abstracting away from some of the lower-level concerns. That lets analysts focus on doing great analysis, rather than on remembering whether the particular dialect they're working in uses common table expressions or subqueries.
I majored in political science in college, and my Master's Degree is technically in "Multimedia Engineering," but really that means I studied electronic music. So I'm an analyst who trained (and worked in) politics and music.
But it turns out that's not actually that rare. Well, maybe that specific combo is, but some of the best analysts I've ever worked with trained as roboticists and molecular biologists and psychologists and economists and manufacturing engineers.
Mastering the technical parts of analysis – how to run a regression or evaluate a decision tree's performance or write a SQL query – is critical, but many of those skills are taught in lots of different disciplines. And I don't think there's any one discipline that covers all of them, so no matter what, you end up learning some of them yourself or on the job.
But the things that make someone a truly great analyst – skepticism, critical thinking, a logical mind, numeracy, creativity and an ability to translate business problems into analytic ones – aren't learned in school. And they're certainly not restricted to economists and engineers.
So, on behalf of music/political science majors (and people with interesting backgrounds of all kinds), I'll just put in my plea for people to have an open mind about what a great analysts' background looks like.