Drill to Detail - Drill to Detail Ep.101 ‘The Story Behind the Story of RJ Metrics, Fishtown Analytics and dbt Labs’ with Special Guest Tristan Handy

Episode Date: March 22, 2023

Joining Mark Rittman for this 101st Episode Special for the Drill to Detail Podcast is Tristan Handy, CEO and Founder of dbt Labs talking about what went right at RJ Metrics, how the Analyst Collective led to today’s community around the open-source dbt project and his personal journey from being in the lab building Fishtown Analytics to CEO of today’s hottest data analytics startup … and why he secretly wishes he was Mark (according to Mark).Ep.100 Special ‘Past, Present and Future of the Modern Data Stack’ with Special Guests Keenan Rice, Stewart Bryson and Jake Stein (Drill to Detail Podcast)My $2.6 Billion Ecosystem Fail: an RJMetrics Post Mortem (Bob Moore)How Best-in-Class eCommerce Businesses Achieve 230% Growth (2x eCommerce)Introducing the RA Warehouse dbt Framework : How Rittman Analytics Does Data Centralization using dbt, Google BigQuery, Stitch and Looker (Rittman Analytics Blog)Goodbye RJMetrics, Hello Fishtown Analytics (Tristan Handy)Ep.33 'Building Out Analytics Functions in Startups' With Special Guest Tristan Handy (Drill to Detail Podcast)Analytics is a Trade (Tristan Handy)Analyst Collective website (via the Internet Archive)Building a Mature Analytics Workflow: The Analyst Collective Viewpoint (SlideShare)Fishtown Analytics : Frequently-Asked Questions (via the Internet Archive)Ep 41: dbt Labs + Transform join forces on metrics w/ Nick Handel + Drew Banin (Analytics Engineering Podcast via Spotify)

So that's that's the like not successful version of the story. Do you want to do you want to hear some of the things that we got really right? Yeah yeah definitely. Okay so and this is the stuff that that gets talked about less. Hello and welcome to this special 101st episode of the Drill to Detail podcast, and I'm your host, Mark Rittman. Our very special guest on this very special episode is none other than Tristan Handy, founder and CEO of DBT Labs, and returning guest to the show. Welcome back, Tristan. Thanks for having me. I'm looking forward to it. And maybe for the one person in the world who doesn't know who you are, maybe just do a little intro to who you are, Tristan, and what you do.

So my name is Tristan. I have been in data for about 20 years. About coming up on seven years ago, I started a company called Fishtown Analytics. And right because of the community traction that DBT had gotten, we ended up raising money. We turned into a pure play software company. Now, eventually changed their name to DBT Labs because we were tired of answering the question, what is Fishtown over and over and over again? So Tristan, you've been a guest on the show a few times now,

which has been great. But I want to take a different tack on this episode and talk about three stories that personally I'm interested in and I think maybe illustrate your way of thinking and the thoughts that's gone into analytics engineering and DBT labs and a lot of the things that really underpin the modern data stack so really the first thing i want to talk to you about and that i've been fascinated by

personally is the story behind rg metrics so most people know the story that dbt came out of rg metrics along with stitch and and so on there um and but there's often this narrative around rg metrics that it was in it was in some form of failure it didn't sell for as much as it could do in the end. It didn't take advantage of the network effects of ecosystems. The technology was kind of was obsoleted by things like Redshift. But really, from what I can tell, there was a lot that was actually quite interesting about RG metrics, particularly RG metrics, the product, you know, the content that was

in there and so on. So and actually, I sat through a podcast that you recorded a few years ago, and it was talking about the top metrics that an e-commerce business should focus on, for example, for growth. I just thought all the time, there's a lot of value in this. And it's something we don't necessarily see in the modern data stack now, this kind of opinion about metrics. So maybe just talk to us about what RG Metrics was and what went right as well as what went wrong. Okay. Okay. This is going to be fun.

Let's get into this because I think that maybe a lot of the story that has survived around RG Metrics has been the story of not being as successful as any of us wanted it to be. So let me tell that version of the story real quick, and then we can get into maybe what's a less told version, which is some of the things that we did really right there. Okay. So RJ Metrics was started in, I think, late 2008, maybe early 2009, somewhere in that era, by two folks out of Inside Venture

Partners, Jake Stein and Bob Moore. Sorry, Bob, let me do it the other way. Bob Moore and Jake Stein. Bob would be forever offended if I put his name second in that comma delimited list. Um, but, uh, it was a, um, it was, it came out of something that, um, specifically Bob saw in his work at Insight. He was kind of like the quant guy where, um, he was involved in doing all the due diligence of, of the companies that they were looking at. And, and there was like a standard diligence playbook that they ran companies through cohort analysis and customer lifetime value and all these different things. And Bob had kind of routinized this a little bit while at Insight. And then he said,

I want to create a SaaS company to take this to the next level. And if you want to say that the company was not successful, I think really the primary driver around its non-success was the date of its founding. That's what I always start the story with. It was started in early 2009 because early 2009 is just a couple of years before the launch of Amazon Redshift and the subsequent, you know, bringing into life of the entire modern data stack. And as Redshift and Looker and Fivetran and Mode and Periscope and all these other companies kind of took flight, it was clear that as I was sitting inside of RJ Metrics and watching all this happen, it was clear that we could not possibly out-innovate that entire ecosystem.

And when you built a BI tool starting in early 2009, you kind of had to build essentially everything yourself. You had to build data ingestion and you had to have a warehouse itself. You had to do transformation layer and you had to do analytics. And now you have each of these four categories being owned by independent venture funded companies that they could just focus on what they did best and they moved faster. So that's the like, and eventually that ecosystem out-competed us and we decided, you know, if you can't beat them, join them.

And so we carved out a part of the RJ Metrics tech stack and that eventually became Stitch. Stitch is a data integration tool competitive with Fivetran and eventually that was sold to Talent for a reasonable acquisition number, not a looker style number, but it was at least partially successful. So that's the not successful version of the story. Do you want to hear some of the things that we got really right?

Okay. Okay. And this is the stuff that gets talked about less. RJ metrics. The foundation of the project was metrics. And many, many BI tools of that era, and even even today, don't actually have, they don't have a metadata concept of a business metric. And when you don't have that, then you are kind of missing this abstraction layer that allows business users to interact with the data more seamlessly. And also that the tool can then start doing things on your behalf. So if you went into RJ metrics and you defined, you know, core set of, uh, you know, res revenue, customers, et cetera, um, it could start

doing things for you. Like it could automatically, you could say, you know, cohort this data and buy, buy the following field. Um, you could, uh, gosh, it's been, it's been a long time now. It baked in some of these really important e-commerce and SaaS metrics right out of the gate. And so the time to value that back in, let's say 2012, that a company would get when they just plugged in some of their core operational systems was like incredibly high and sometimes still not today's tooling doesn't doesn't eclipse it in terms of like how much value you could get as quickly so was the benefit due to the fact it had a semantic layer or was actually the content was in the semantic layer. And with things like best practice definitions of e-commerce metrics, for example. Yeah, there was, you could call it a semantic layer.

It was like tightly coupled with the tool. And I think maybe not as powerful as something like LookML, but that did fundamentally drive how all visualizations get created inside the product. But I think it was more than just kind of a horizontal semantic layer. It was based on this core idea that there are certain business models out there that our users are going to have. And the two biggest ones for us were e-commerce and SaaS. And if you know the business model of the company,

then you have a pretty strong idea of like what stuff they're going to need to measure. And so you can make measuring those things easier. And I think a lot of the modern data stack kind of loses that concept a little bit. We've built very horizontal technology, which has allowed us to service appreciably all data use cases. But modern data stack vendors are not as opinionated about how do you, as a SaaS company, go from zero to 60 as quickly as possible?

So you and I have had this conversation in the past where I've talked about the fact that back in the Oracle BI world that I used to come from, the content layer that would run on top of the actual BI infrastructure would sell for many, many multiples of the price of the infrastructure and the BI tool, because that's where the value was for customers. And I've always been surprised that in the modern data stack world, in the DBT world, there hasn't really been an equivalent to DBT, but for content, an actual maybe a user community

and an open source project around collecting content together to go with BI as well as the tooling. Do you have any sort of thoughts on that? Is that a surprise to you or what? Oh, gosh. A little bit. So my original thesis around dbt was not actually let's build a horizontal data modeling product.

It started out as a package delivery system for Stitch. Which is why we were investing in it while at the company. Essentially, I wanted to do what Fivetran is now doing with DBT very extensively and taking every connector that we published and building useful data models and analytics on top of it. So back then we released data models for Stripe and MailChimp and, I don't know, a couple other products.

And so this idea of delivering reusable analytics via DBT has been around for me since the beginning. And again, something that really struck me since the beginning and again something that really struck me about the way you marketed rj metrics was that you didn't just market it as being a technology or a platform you marked it as a solution would you say you know that that is a fair thing to say and i think that you know i talked a little bit about where that came from and kind of the history of the company but there's also the fact that back in 2012, 2013, um, you, the, the, you know, we were still selling to early adopters and, um, the, those often were digital native companies. And, and back in that time period, it was not common at series A, series B companies to have literally any data technology

at all. And it was not like, oh, well, are you going to buy RJ Metrics? Are you going to buy Looker? In the early days, it was like, well, currently I'm doing everything in Excel. Why should I spend literally any money on this? And so we had to be very use case focused because if you just went and sold horizontal technology, the answer was just, no, I'm not interested in that. And the most common competitive questions that we got back in the day were like, RJ Metrics versus Google Analytics or RJ Metrics versus Mixpanel. It was just like, these were the only data products that early stage companies bought. So, as you said earlier on, RJ Metometrics, the product, was certainly successful in its time. But then I'm interested to understand how you and Jake had the kind of the thoughts or the foresight, really, or maybe the bravery, you know, to take what was a successful product at the time, but then actually kind of decompose it and almost like cannibalize your own business to turn that into Stitch and DBT.

It's easy to destroy things. It's easy to destroy things. It's easy to break things down, but not so easy to build things. So maybe just tell us a bit about how that worked and how you came to that decision in the end. I wish I could tell you that we were, you know, courageous visionaries here. But honestly, it probably took us a little over a year longer than it should have to make this change. We started seeing the success of the modern data stack in our own numbers, in our deal close rates, in our pipeline. Whereas, honestly,

I don't even remember what our close rates were at one point in time. But we saw those kinds of numbers fall off a cliff and then our very pretty exponential curve flattened out. And it was, you know, I think that whenever you decide to do something new, you have to ask, like, well, why did that person do that thing? Because most people at any given point in time, they're just kind of muddling along, whatever. And honestly, if I put myself back in the mindset of me from 2015, I would have been much happier to continue muddling along. And if RJ had been doing well, I probably would still be there, whatever.

But we get such a strong signal from the market that like, hey, there's a new thing coming that you couldn't do anything but respond to it as me as a longtime data practitioner, but also as a person who was working in a company that clearly wasn't going to be able to continue to just pursue the status quo. So you went on then to set up something called the Analyst Collective. So maybe let's talk about that. You know, how that idea emerged, what the kind of intention was behind it. Because it was quite a different approach to what RJ was doing at the time. And I think one of the things about you is that if you do things, you don't do them by half, really.

So tell us a bit about that and what the Analyst Collective was and how that actually became the foundation for a lot of what then came with DBT and analytics engineering. So Analyst Collective was really just an idea that I was, as so many of my ideas start with, I was frustrated that software engineers had a thing and I didn't have that thing. And in this case, I was frustrated that software engineers had Stack Overflow. And if you're a long-time data practitioner, you've probably experienced, uh, what is like to try to describe a problem that you're having

in like in, in an appropriate Google search and then like click through the results and, you know, okay. If you want to, if you have a like very specific SQL question, like, yes, you can get that answered from Stack Overflow. But most questions that data people have are not, don't map so well to like something syntactically in SQL. And I just felt completely unsupported. The thing that I was trying to do early on in my Redshift usage was I wanted to figure out how to get, like, I had a time series that was one record per day, but there were some days that had no data. And so they didn't have a record in the result set. And that caused all kinds of

problems with the report that I was generating. And I didn't know how to create a result set that had a record for the days with no data in it. And,. And I tried every Google search that I could think of. I eventually like shoulder tap somebody that I worked with and like we brainstormed on this for a while. And now this is common knowledge in the DBT ecosystem. You join to a day's table. But like I just didn't know anybody who knew that answer back then. And so I, I wanted to see if I could create some version of a, of a analyst community where we could all kind of make ourselves better. Um, and then I thought to myself, I actually have no idea how to do that. Um, so maybe I'll just be

an analytics consultant and maybe I'll figure out a way to do that as time goes on so just after that time you um you remember you posted a blog on media where you talked about how you were starting fishtown analytics and you know you were talking about how analytics was a trade and how um it was almost like as a reaction to to you know working in a startup or working in a kind of environment like that, you wanted to build this environment at Fishtown where analytics would be treated a bit differently, really. So maybe just talk to us about that and the thinking behind Fishtown and that blog post. uh this too is uh in reference to to software engineering so you know you can uh essentially every function inside of a venture-backed startup is, is, oh, how do I put this? It's, it's like under a tremendous amount of pressure to ship now, now, now, now. And if, if it's, if it's not now, then it's, you know, in five minutes. And the one team that kind of creates a little bit of space for itself to be a little bit more thoughtful about its approach.

And maybe I'm like making the maximalist version of this argument. Maybe I'm exaggerating a little bit. But I think that this is kind of broadly true. The one team that carves out some space for itself is the engineering team. And I think that that is because there are enough people in the technology ecosystem who have seen enough horror stories when you just try to do the most expedient possible thing and things blow up and the company dies that engineers have said, look, you need to let me think for a minute about what the right way to do this is. And then we can also think about what the

fast way is to do that. And we can make a decision which we want to do. But if you as a data analyst tried to say in 2015, like, hey, just hold on a second. Like, let me think for a second about whether I want to do this the fast way or the right way. That wouldn't have computed to anybody. It was such a foreign concept that even the data analysts wouldn't have even understood, like, what does a right way even look like? And so I wanted to import some of this trade craft into the analytics profession, which creates space to just say like, okay, I'm not just in the process of constantly in real

time responding to requests as fast as I can. I also have a roadmap I also have like a long-term strategy for how my work is is getting built out and how I'm creating leverage for myself over time yeah so I definitely thought that was there's quite a fresh thought at the time um back at that point everybody was either using excel for bi or they were using graphical bi tools and just like knocking out analyses and there was no real kind of there's repeatability and testing and so on um but you what you were proposing was to be mindful about how we did analytics and how treating it as a craft and and and giving it a lot more care of attention i mean so that was really refreshing at the time so so i remember meeting

you for the first time um i think we'd recorded an episode of the podcast before but um it's the first time i met you in person and we were both at a uh look a partner event i think um keenan was presenting and they were doing some kind of worthy uh partner of the year award uh and after a while i thought i'm going to the pub and so i sort of sneaked out the back and bumped into you and i've persuaded you to come and join me so that was the kind of first time that we'd ever spoken. And you had this, I mean, you told me at the time about Fishtown's business model, where you, again, has very strong opinions about how you were doing things. And the model you were going to follow, which was, will you tell us about it? Tell us about the Fishtown model and how that actually, you know, became quite successful. Yeah, yeah, yeah. I think there's a lot of interesting stuff

to learn from our consulting days. And I don't know how successful we were. I know that we were successful enough, but there are many consultancies that started later and scaled much faster, got much, much bigger, and I'm sure made their founders much more money than Fishtown Analytics ever made me. faster, got much, much bigger, and I'm sure made their founders much more money than, uh,

Fishtown analytics ever, ever made me, um, that my take was that if, you know, I had always believed that dbt was going to be kind of our, our secret sauce, uh, from a consulting delivery perspective. And I knew that dbt allowed, um, you to deliver, uh, this, the same amount of work or insight with less like human time. And, and that if I knew that if we had a really strong opinion about our target customer profile, then many of those companies could look similar to one another. And then we could deploy reusable analytics using dbt packages across multiple. So what one of the things in our contract was that we could use code from client engagements. And we could open source that code assuming that it had no like you know client proprietary stuff in it and um so so the idea was to have a bunch of clients that all looked similar and then continue to open source chunks of this code um and then every subsequent client got easier because we would be able to leverage work from clients before.

And so we charged on a per sprint basis. And the sprints were, they were not about a number of hours. They were about a number of points and the points related to value. And so it, after we built up a kind of a repeatable book of, of like a repeatable playbook, sometimes we could go for like the, and each of these sprints was depending on the time is either 25 or $3,000 or $4,000. And, um, sometimes we could onboard a new client in one of our core verticals, SaaS or e-commerce, and we could do four, five, six sprints without writing a single new line of code because our playbooks were so good. So how do you manage to keep scaling the business and keep true to your analytics as a trade principles. So it was interesting because if what we were doing was, we didn't spend a majority of our time putting hours into individual customer projects.

What we spent more of our time doing was curating this set of play, I'm saying playbooks, but really, they were like dbt packages, plus maybe looker blocks. And so we really tried to say like, I mean, for example, we had it, we had a e commerce Shopify playbook. And I don't know, we probably built that out over the course of a couple dozen clients that, that used Shopify. And, um, and, and so we, we actually spent real time thinking about like, okay, over these couple of dozen businesses, what are the things that generalize?

What are the options that we need to put in here? Because these are the options that we need to put in here because these are the things that differ um so that's that's kind of how we scaled our own trade craft back in the consulting days so another thing that i've realized with my businesses over time is it's never just about me or you or the kind of leaders it's about the whole team really and the team is the key to everything um and something that's obvious to me about how you've run things is certainly that's been seems to be sort of fairly central to how you do things and there's names that i recognize there that have been there through the days of fishtown and and now dbt labs um and there's certain way in which you run the companies as well you know you're very open with

how you do things i think there is you know your your corporate handbook is on on github and your change change log on it as well is there as well. So how have you managed to build a team over time? How important is that team? And how important is the way in which Fishtown and dbt Labs have been run? Oh, gosh. I don't...

We're originally from Philly. RJ Metrics is from Philly. And so five of the original team members were all from here. So myself and Drew and Connor, co-founders. And then employee number one was Erin. She ran a consulting business. And then we added Janessa, who is maybe employee number 10, something like that. And she's run marketing ever since. And so that gave, and we, you know, we added a bunch of other people in there, but these folks at this point I've worked with for now a decade.

And I, you know, we've gone through different iterations of like who does what and how reporting relationships work and all this. But like it does give any company, not just us, but if you can start a company with people that you know well and that if you can continue those relationships, gosh, it's such a powerful foundation on which to build because you already come in with these kind of, whether you want to say like culture and values or just like kind of implicit, unstated norms of behavior that you kind of bring with you that are very hard sometimes to write down. So how much is Philly and the grounding it gives you and the fact that it probably your friends and whoever you um associate with aren't tech entrepreneurs how much of that part defines who you are and how you think um i think it has been incredibly foundational for us. The original idea for the consulting business was just that I wanted to look for a VP of analytics job. I wanted that to be my next job. And there were no, you know, early stage, mid stage companies in Philadelphia at the time that were hiring for VP of analytics. And I also was not, it was not open to leaving, I was definitely staying in Philly. And so that that's kind of like, at the core of why the company started in the first place. But that's just like a generalization of a bigger point. When you're not located in the kind of center of the tech universe, it means that you have the ability to diverge from the kind of conventional wisdom to take paths that are less traveled.

I mean, if I was in Silicon Valley in this time period, I probably would have gotten sucked up into the set of companies that were, I mean, what was like 2015, 2016? What was like the hottest thing in data engineering? It was Airflow. And it was a bunch of internal tooling that was being built inside of Airbnb and LinkedIn and Twitter and et cetera. And maybe I would have had a nice little Apache project to my name that was highly useful in a very constrained context of a hyperscale tech company. But because we were located outside of that kind of information sphere, we were thinking about problems that were relevant to the much, like much, much larger group of companies who are not, you know, a hyperscale tech company. The last thing I want to talk about now is,

is I suppose the journey you've been on since the last couple of years, really, when, you know, you've been, you started off by being CEO of Fishtown, but defined by the fact that you, you,

you know, wanted to treat analytics as a craft and you were defined, I suppose, by not being part of a startup and everything you've been saying earlier on, to then being CEO of a well-funded startup with hundreds of staff, pretty much one of the most consequential startups or successful startups over the last few years. And it must have kind of been quite an interesting journey for you really how have you handled it and how has it worked for you the team and and so on i want to object to your characterization of biggest and most successful well i i certainly would say that we're well you've not done too badly we're we're doing okay and i think we're making a great impact and I'm, I'm excited about that. Um, what impact has it had on me? Um,

you know, I've been very, I went into this with open eyes. Um, I've, I've been involved in prior to raising money with then, then Fishtown analytics. Uh, I had been at VC back companies for seven years um had seen the great stuff about that and the less great stuff about that um the um i tried to make the decision about fundraising based on what i thought and this is this is the way that i think about in my my brain. I'm not,

I'm not a religious person, but I think about like, what does the universe need from me or the company or the product or whatever. And when I say the universe, it's not really like, it's the actually that magical. It's just like, there's, there's all these people out there and they, a lot of our, our community is just continually pulling more stuff out of us. Like ever since the first dbt commit, there have been people saying like, Hey, it would really help you if you did X or Y or Z.

And it was, it was getting to a place where it was a trade-off. Like either we would have to kind of declare bankruptcy and say like, Hey, we just can't keep up with the growth of this community, or we have to, you know, raise, raise money and accelerate in that way. Um, and, and it wasn't really about me and what I preferred. If you, if you'd honestly, if you purely asked me like, what would I prefer? I would prefer to have, uh, you know, five person consulting business and I I'd still work with data every single day and work with clients. And that, that's like kind of.

That's how I console myself at night. I, I sit there thinking about you, um, wishing you, wishing you had my small consultancy and how it's all gone along with your, with your well-funded startup. Well, like, yeah, to be honest, I haven't, I haven't had the opportunity to like really sit down and write code for hours and hours and hours in a long time. And that was where a lot of my professional joy came from. Now there's a lot of other great stuff about what I get to do today. And I'm tremendously proud of the impact that the company is having on the ecosystem at large. And I think that we're still just getting started, but you asked about

me personally. And how about, so how do you think you and the team and the community have handled the changes that DBT has been through over the last few years? I think the thing that every open source founder is stressed about is as you go down this trajectory of having to be more and more of a grownup company, do you, do you lose the team that started because of this big vision? Do you lose the community who, you know, in the early days we were all just kind of like in it together and there was no kind of

profit motive or anything like that. And I certainly, I have been stressed about this over the years. I think, and I'm sure your listeners are more well qualified to know this than I am, but I think we've done a reasonable job at trying to both build a real company that is in the interest of our... The ability for us to govern the project over the longest possible time horizon, and also have taken our team on this journey kind of in, in stages. I will say that there we probably experienced about 30% employee turn from the,

the days when we were a pure play consulting company and when we were a software company. And that was just because we were very transparent about, you know, that this is a different path and your roles in this different path look different. I mean, we certainly didn't, like, we had an amazing team. We didn't let anyone go. But some people just raised their hands and said, like, hey, that's not exactly the company that I signed up to work for. And so that was cool. And they work at awesome companies now.

So recently you announced the acquisition of Transform. So how did that go? Well, I have never acquired a company before. So that is something to check off my bucket list in life, I suppose. No, I have... Certain elements within our company have wanted to be more acquisitive for several years now. I think that the...

Apparently, if you're from San Francisco, this is what you talk about when you get together for beers. You're like, who's going to acquire whom and what company should we acquire and all this. But I have, so dbt is, um, still a little bit unusual in the data space in terms of how we build product. And, um, so it is even if, so why is that then?

Oh, just the way the product actually works is a little bit different. There's a bunch of... Okay, so if you want to build a data catalog, you want to build a data catalog that integrates with everything, right? And for us, we want to build a great catalog experience for DBT. And those two things are not the same. And the way that you build a data catalog for DBT is very different than the way you build a data catalog for like arbitrary different data.

And so we've looked at different companies over the years and we've just said like, well, that might be an interesting category. But the companies that are in that space today, we would just choose to build the product super, super different. And this was the first time that we looked at a company where we're just like, that's, that's like exactly how we would want our product to look when it's more grown up. And, and not only that, but like the team there, that's how we want our team to show up at work too. So it was really, I don't think you should expect us to all of a sudden become a very acquisitive company

because it's not, it's like a lot of things had to come together in a very, very positive way. So this kind of stage in the story, this phase in the story of, of, of dbt and dbt labs, how would you like to sort of see this ending up? What's the kind of the perfect ending really for you for this journey you're going on? The success for me is

how many of you have ever ended up on this Wikipedia page that shows the longest continuously operating companies in existence? Right? It's an interesting page. There's like some Japanese pub that's been operating for a thousand years or something. I mean, there's some really interesting ones. To me, the reason that we made the pivot towards software that we did was because we wanted to be in a position to steward this community and this product in the longest possible time horizons.

And so, you know, success for me personally will look like, you know, one day, uh, having the, the organization outlast me as its, uh, as its CEO. I think that if you build something really successful, um, the, the mark of that is that, that you are no longer needed to, to continue leading it now that I'm not actually thinking about that in any kind of active way, but, but like, that's, that's success. Like, I think that we are, the ideas that we are helping bring to life, they're not two, three, five, even 10 year ideas. Like, I think that this thing needs to exist for, for a long time. Tristan, as ever, it's been great to have you on the show. Just to round things off, where do people go to, to find out more about DBT?

GetDBT.com. And if you navigate in there to the community and sign up for Slack, shoot me a message. I'm at Tristan. I love hearing from folks who are new to the community. Thank you.