Ep 20: Tristan on the Hot Seat
Get to know more about Tristan’s trajectory as a human, as a writer, and as CEO at dbt Labs.
In this very special episode, we’ll be turning the spotlight on co-host Tristan Handy, the CEO & Co-founder of dbt Labs and author of the Analytics Engineering Roundup.
In this conversation with Julia, you’ll get to know more about Tristan as a human, as a writer, and as the CEO of dbt Labs helping to push the analytics engineering practice forward.
Listen & Subscribe
Listen & subscribe from:
Show Notes
Key points from Tristan in this episode:
Why do you think you've been drawn to tech?
I was drawn to tech for the same reason that like other kids my age. We're talking about my birthday. I just turned 41, which means that I got a 28 modem whenever I was 12 or 13 or something. The right level of complexity required to get online was reasonably high, but I was also at a point in my life where I was willing to sit down and figure out all of these.
I think it was called Cali, the protocol that allowed me to play multiplayer World of Warcraft II back in the day. But the two lines intersected like my own capabilities as a human and like the complexity of getting online and it just felt like this really exciting world. I pictured it as like the frontier in the same way that people explored the American frontier in the mid-1800s. It was like a new space opened up and it felt exciting to move into.
But no, I had literally no models of entrepreneurship in my life at all until I was living across the hall from Anthony when he was just like, "yeah, I'm going to spend $30,000 on servers, and we'll see how this thing goes".
Where did your love for writing come from?
My dad was a great storyteller as a kid. He just had such a deep knowledge of so much literature that anytime we were in the car for 45 minutes, which we were frequently, he would tell us the story of Theseus and the minotaur, or whatever.
I knew a lot of literature in this kid bite-sized version. But no, I didn't enjoy writing until I could write publicly on the internet, which happened to me at age 21 or 22. I had the good fortune to be friends, mostly not in high school, mostly in college with the founder of Squarespace, Anthony Casalena.
I think to this day, I'm like account ID number seven or something like that on Squarespace and this was like 2003. It's not like blogging was brand new. People had been writing words on the internet for a lot longer than that, but it was still the early days of the concept of blogging. And I just really, as a kid, the internet had always felt cool. Like I had a 28.8 modem and all of the stuff. And just the idea that I could easily put my words on the internet made me find a love of trying to think things through publicly. Then, every once in a while I would get like 100 people to view a post that I would write, and it was just like a big rush.
I remember writing a post on my thoughts on gun control in the second amendment — and remember, this was like the early days of the internet or at least early days of blogging — and that ended up getting a lot of views. Maybe not the kind of conversation in my comment section that I had looked for. That was my first brush up with maybe you want to self-censor a little bit with exactly what parts of your internal state you want to share with everyone online.
Tell us about RJ metrics. What was it?
RJ is such an interesting story. It taught me so much before going into too much depth there. I want to first start by saying that this story has been told publicly by the CEO, Bob Moore. So I'm not being controversial or anything when I say that RJ probably didn't go exactly the way that any of us had thought in the early days when we had big dreams of success. But that's not to say that it didn't achieve some really fantastic things. And a lot of us learn a lot of things along the way.
The RJ story at the highest level was like two guys, Bob and Jake, founded a company while they were at Insight Partners and they were analysts there. They were like, Bob, in particular, was responsible for running a lot of the due diligence on companies that Insight was dealing with. And he developed a way of doing this analysis that was really routinized and effective. And so he attempted to create a company that would help with analytics in this kind of model of the world. The challenge I think was ultimately a timing challenge.
So 2008 turns out to have been like a really bad time to start, looking back on it in hindsight, but what was fundamentally a business intelligence company? And I say that because it was like three, four years prior to Redshift. I've written publicly about this, like the advent of Amazon Redshift, like really upended the BI industry. It reshaped the very beginnings of the modern data stack and the way that you built a BI tool pre Redshift was very different from the way you built a BI tool post Redshift.
And so RJ was really on top of the world in 2012, 2013 time horizon. I joined in 2013. We had a fantastic client list and started to raise what at the time seemed like a lot of money. And then, Redshift came out. And of course, at the beginning, it takes a long time for anything to make any impact, but we didn't, it didn't really register on our radars. It didn't seem like a thing that we should care too much about. But then by 2014, we were getting in deals with companies like mode and Looker, these like upstarts. And by 2015, we were reasonably consistently losing those deals.
And we had to like the architecture of the product, fundamentally it was not that well suited to the modern cloud data warehouse. Like, actually the original database that underlies the product was My SQL if you can believe it, and a lot of the data processing was done in PHP. Really nuts today, 13 years on, but that's just was, seemed like a reasonable decision at the time.
So we had to figure out what to do. It was clear that we weren't gonna rebuild the product from scratch with the whole customer base and revenue base and everything. And so what we ended up doing was, but Bob and Jake orchestrated this fantastic move where the existing business, the BI business was sold to Magento. And that in turn capitalized, the spinoff of Stitch ended up being created from all of this. And it was like a core part of the RJ metrics technology became Stitch, and that ended up working much better with the modern data stack. And, still is very widely used now housed inside of talent.
But RJ, as a product, attempted to do all of the different parts of what we now call the modern data stack because it didn't exist yet. So, in order to build a BI tool, you had to do all of the stuff you had to adjust the data you had to store and process it. You had to transform it. You had to have a dashboarding component. If you can imagine a little startup that had a couple of million dollars in funding trying to do all of that stuff, which now there's like literally billions of dollars raised. It's not going to work.
The way I responded to that was to have incredibly clear ideas for what dbt was and wasn't going to do, and an incredibly clear understanding of in their early days, like how I was going to assemble a data stack for the consulting clients that I worked with. It was always going to be a best-of-breed stack. We were going to see the solution as multiple layers in which tool worked best in which layer was a choice to be made for each client.
Was dbt the winning name from the start or did you have a different idea than "data built tool" as being the name for the product that you were going to be building alongside at Fishtown Analytics?
Originally dbt was an open source project started inside of Stitch. We got Jake, the CEO of Stitch, to approve us working on this as a marketing project because I had used the data that came out of Stitch in the early days. And it was a struggle to work with. There was just you plug in the Facebook connector and you just got so many tables that show up in the schema. And I was just like, "I have no idea what's going on here. I want to measure ad ROI".
And so I was like it seems like our product team has enough going on. It seems like it might actually be a really good marketing tool. And the story of like, why a data person brand marketing? In the early stages of a B2B SaaS company demand generation is everything and it's very quantitative. And so that would really appeal to my data brain. But so the idea of an open source community to create packages for Stitch connectors, to make them easier to use and create content around what you could do with this data once you installed this package on top of it, that was like the entire idea. That's why dbt had a package manager in I don't know, month two or something because it was actually like a core part of the whole idea. That was like why dbt existed.
Chris Merrick the CTO of Stitch made the very first commit to the dbt repo, he named the dbt repo. And it wasn't some brilliant product name. He was just like, "I don't know. I couldn't think of what to call it. I have been using Scala recently. Scala has this thing called sbt (Scala Build Tool). So I just called it dbt. And we all actually, Chris liked it, but the rest of us hated it and we'd, but we just never thought of a better name, and so at a certain point, it was like, "that's the name".
Another thing that's been pretty consistent is community. How do you think growing up in a small town influenced how you think about community, or was that not really the driver on how you think about it?
I could try to make that connection, and maybe there's a little bit of that there. I would say, actually, the early days of community for me were probably two things.
I had literally zero interest in trying to convince people. To work with me. Sure, if they wrote me an email and said "Hey, I'd like to talk about doing a consulting project. I was happy to tell them why I thought I'd do a good job of that". But I had zero interest in going to all my friends and saying "Hey, connect me to your friends who run companies", the whole outbound sales thing, which is generally, if you run a consulting company, that's what you're doing most of your time.
You're like trying to do business development.
So, for me, a big part of the community was like a way to spread the word of the way that I did work. At the time it was Drew and I, and some people would knock on our door as opposed to me trying to convince them to talk to me. And that actually worked. It was via community that we landed essentially all of our consulting. Like, I've never outbound sold a consulting engagement we've done. I don't know hundreds of them.
Also, for anybody who's done this, the early days of founding a company are incredibly lonely. It was me sitting in my home office and my wife would leave for work at 7:38 AM, and I'd see her again at six 30. And in the meantime, some days I would literally have talked to zero people. Most of us use Slack and there are other people in Slack with you. But Slack is surprisingly a lonely experience with two people in it. It's just very quiet.
So the community was just like other people who were doing the work that we could all hang out. And I think that's why I've always had this peer relationship with the community. It hasn’t come out of a desire to spread the word of dbt. It's a thing that I want to be a part of too.
What from the old data stack is still the most relevant in the modern data stack and why, or maybe set a different way. What's not going away.
Gosh, what is not going away?
I think all the technologies are going away. Literally, the products, the lines of code, like all of that's going away. But the jobs to be done are not going anywhere.
If you look back at the problems that data companies were solving in 1995. They're fundamentally not that different from what we're talking about today. Yeah, there is: Where is your data located? How do you want to be able to process it? Your whole workflow is like transformation, cataloging, governance, all of that, which is called data integration, which is the worst term ever from my perspective. And the whole set of analytical or BI capabilities. Like all of that stuff is the wheel of time or time is a flat circle. We're going to be rebuilding that stuff on every new generation of technology forever.
I think that one of the interesting things about quote-unquote, the modern data stack, and I've been on podcasts recently where I've been roasted for that too. What does that even mean? Are we gonna still be saying that in 2050 and what the hell is modern then?
But when you move to the cloud, do we have the opportunity to break this chain, like stop reinventing everything every 10 years, because once SQL is just an abstraction for computation and it no longer matters exactly what box is running that SQL query for you. Then you can start to think about it as like this API you can build products on top of. dbt doesn't actually care whether you're running on top of Postgres or Snowflake or Materialize. And these are like three products that are really fundamentally architecturally different, but SQL just becomes this API. And maybe you can forever have these like generations of technology that continue to progress forwards. But the layers above don't have to be completely rewritten every time, which is what has happened in the past.
Is it better to be the first data person bringing a company's data stack and literacy from zero to one, or is it better to join a more established data team where there's access to great mentors and knowledge share?
I can tell you what I did. And I can tell you the pros and cons of that. I frequently find myself giving advice to people who are in their early stages of thinking that their companies are just getting off the ground. And so I know that this is not advice for data professionals, but the advice I always give is lots of startup founders.
And many of the most successful ones had never worked at a startup before, but I had. Three startups before I ever wanted to start my own. And by no means, if I'd done a perfect job, but I think that I've managed to avoid some of the pitfalls that a first-time founder or somebody who had never been at another startup before might not have been able to foresee and avoid.
So your. Probably going to be pretty long. And I don't think you should really be in a huge rush. You will get there. You will have time. I think that the amount that you can learn in other environments, as opposed to just figuring everything out yourself, is really dramatic at the beginning of your career.
And I spent my first five years in the big four consulting company and it was a very shotgun set of experiences like a hood. It did all kinds of random crap, but I dropped. All the time still 15 years later. So I don't think there is a right answer, but I would actually say that the best thing that you get from joining an environment where you're not the only person is okay, maybe mentorship, maybe that kind of stuff is useful, but I think it's actually, it's more cultural.
How do you do work? What is a mental model for approaching this particular type of problem? And it's sometimes stuff that's very hard to do. Unless you're literally shoulder to shoulder with people like working on stuff.
More from Tristan:
You can find him on Twitter @jthandy and in dbt Community Slack @tristan.