Two Philadelphians Talk Data Startups And Building An Analytics Community

Tristan Handy is the Founder & CEO of dbt Labs, creators, and maintainers of dbt. dbt Labs is building the modern analytics workflow used by tens of thousands of data analysts. Tristan stopped by to talk to our CEO, and fellow Philadelphian, Josh Benamram about how he founded and built dbt Labs, and how they are building an analytics community.

Two Philadelphians Talk Data Startups And Building An Analytics Community

About Our Guests

Tristan Handy

CEO & Founder dbt Labs

Tristan Handy is the CEO & Founder of dbt Labs, a Philadelphia startup pioneering the practice of modern analytics engineering. He has been working in data for two decades in both in-house and consulting roles with both large enterprises and small startups.

 

Twitter: @jthandy

Episode Transcript

Ryan: Well. Hey everyone, welcome back to another edition of the MAD Data Podcast. I’m Ryan, one of the hosts over here. We also have Josh from Databand, our CEO. And then we also have a another Philadelphian. Is that right? Philadelphian.

Tristan: Yes. Yeah.

Josh: Philly Head.

Ryan: Philly Head. Josh is in Philly. We have Tristan Handy, who is the CEO and co-founder over at dbt Labs. Tristan, how are you doing over there in Philadelphia?

Tristan: I’m doing all right. Thanks for having me.

Ryan: Do you want to get your Philadelphia plug-in right before we get going on the topic? I know you really wanted to plug this in.

Josh: Yes, please. I’m actually pretty new to Philly. I moved here from New York about a year ago. I think Tristan, you’ve been around for a little while longer. So I’d love to hear what you think of the Philly tech community so far, the data community here, what’s keeping you around and some thoughts on the future.

Tristan: I’ve been here for just shy of ten years. I moved here to work at a company called RJMetrics, which was kind of just predated the modern data stack and and brought a bunch of data talent into Philly. I, I am still here because within, within a month of moving to the city, you know, like you do, I got on an online dating app and you know the second person that I met I’m now married to, and she was based in Philadelphia. She works at a big hospital here and she was like, I have the greatest job in the world. I’m never moving. And so here I still am today. But but it’s actually like a part of our our story as a company. You know, I, I was like trying to figure out my next data job. And the Philly startup ecosystem was not actually in such a great place in the 2015, 2016 time period. Like there were there were some companies that were promising and have since grown a lot, but it certainly was was not that kind of like market liquidity on the talent side that you would see in like a New York or San Francisco. So was was actually forced kind of almost unwillingly to to start my own thing.

Josh: Yeah. And how much of dbt Labs now is actually in Philly?

Tristan: I think it’s like 8%. So. So at the outset, we were all at the outset we were all like ex RJ people, the first four of us, or we had all worked together. And then we, you know, there’s there’s great schools here. We hired some people out of Penn and other other schools in the area. And. We as we started to build up our engineering team, we’d kind of like seen this play out before the the talent for software engineers is like there’s there’s fantastic software engineers in Philly, but there’s actually not like that many of them. And and so we just adopted from the very outset, like, hey, if we’re going to grow a software engineer team of any size, we’re going to have to be distributed. And we made that decision back in 2018, you know, two full years before the world kind of decided that we were all distributed. So, you know, going into the pandemic, we were I don’t know, 75% of us were still in Philly, and now it’s 8% of us. And we, you know, have have people throughout the continental U.S. and in Europe and Asia Pacific.

Ryan: What I thought was really interesting was that you had mentioned that your spouse worked at a hospital, and that’s why you’re in Philadelphia. Isn’t that the same thing that’s going on with you Josh?

Josh: That’s actually why I’m here as well. Completely.

Tristan: I didn’t know that.

Josh: Works at a hospital. She completely finagled me out of New York. So it’s like why I’m over here. But I’m happy about the move.

Tristan: Some completely unreasonable percentage of the Philadelphia economy is health care and education. I mean, it just. It’s like everything.

Josh: Yeah, yeah, that’s right. But we love it. And to the handful of tech people in Philly, shout out everybody and ping me if you want to grab a beer somewhere at some point. Also, shout out to Jake Stein, R.J. Metrics and his new company, Common Paper, which we’re big fans of. So we like this little Philly tech mafia that’s beginning to form out here.

Ryan: Tech mafia. I like that. I like that. Well, Tristan, before we get into the topic today, which is discussing kind of the modern data team and we have the sub-topic around some metric layer we’re going to get into as well. Could you just kind of give us a background yourself how you got into co-founding dbt Labs, like what’s a day in the life of Tristan like? I know that you do a lot of keynotes and speaking nowadays, but kind of give us a little bit of background on how you got to where you’re at.

Tristan: Yeah, the worst thing is that now when people ask you to speak at a conference, they expect you to go somewhere in-person. It’s terrible. I know I was I was really into speaking at conferences when it just meant that I could open up a Zoom window. So my my story is that I’ve now been a data practitioner for. Depending on how you measure it, like probably a little over 20 years. I, I got a job even back in like high school as the kid who knew Excel. And, you know, this was in like the late nineties. And I’m surrounded by a bunch of civil engineers who needed to create Excel spreadsheets. But in order to, like, add multiple cells together, they would, like, pull out their calculator and then type in the results on the, you know, the results tab. They didn’t actually know about formulas. And so I became like that the kid in the office who knew how to do spreadsheets. And it turns out that, like, you can kind of push that for a long way, as you know, an early, very early career professional. I like did that in college and I parlayed that into, you know, if anyone listening has has been a management consultant, you know, that’s essentially the entire job description is like making very complicated Excel workbooks. So I that that was like kind of my way into data and then at. In in my consulting or early consulting career, I got I got exposed to building systems. So this is back in the era where like government agencies would pay big consulting firms millions of dollars to like build simple web systems. And now you could like throw these things together with like Ruby on Rails or Django in like a team of two people for a couple of sprints. But back then it was like this major undertaking. And so I got put in charge of a big data conversion effort from a 40 year old mainframe into a system that certified all teachers in the state of New York. And it was like my first real exposure to, you know, enterprise data. I used a whole suite of Oracle products. I like ran a small team of people to do this, this work. It was like really so, so cool. I, like, learn to think in sleep in SQL, I was like, it was the first time where I was like, This is a thing that I’m really good at and could imagine doing for a long time. But. The career path there is like at least was at the time was like not at all clear. Data people didn’t have this standard career path that like software engineers have where you continue to build up your skills, you continue to get promotions and pay more money like oftentimes if you’re really good at doing data work. That just meant that somebody some like some executive was going to make you like their quote on quote, their person. You were going to like sit in the corner, you were going to like make reports for them forever. And they were never going to let you do anything. But that was like the opposite of a good career path. And so, you know, it was clear they didn’t want to do that. And, you know, I got into the startup world. And in the startup world, when you you very quickly learned that, like, you need to learn how to do things, not just know stuff. So you I like had to learn how to do ops in marketing and have had leadership roles in those areas. But like those are still, you know, if you’ve, if you’ve been a VP marketing before, you realize that like a big chunk of that job is, is data. So I was like really good at the data part of marketing and I was kind of bad at the rest of it.

Ryan: Well, I appreciate you saying that marketing should be a data driven practice because I’m in marketing, so I appreciate, you saying that. No, I think that the whole marketing angle because you because from there from from marketing from your past job you because correct me if I’m wrong, before you got founded going into dbt, your last job was in marketing right or was it not?

Tristan: It was in marketing and I, I had at that point had marketing related roles for seven years. And, you know, marketing was the thing that I’m very happy to have learned how to do a reasonable job of. But it wasn’t the thing that got me out of bed every morning. It wasn’t like, you know, you can only force yourself to do something that is not your passion for for so long. Apparently that length of time for me was seven years. But, but, you know, as RJMetrics was kind of like winding its way to completion for me. I had to figure out what my next thing was, and it was definitely data. The question was, how do I how did I get get back into this in a way that was satisfying and was not like stuck in this not good career progression like I was talking about before. And so I really saw this as two things. One, like what opportunities were unlocked by the new data technology that was, you know, had had come out in the early 20 tens. So this is like Amazon redshift and looker and mode tools like Stitch and five train. So like it was clear to me that like practitioners with my type of skillset now had a lot more power than we had a decade prior. But but then it also like required a new workflow, a new way of using these tools. We had all these new superpowers, but like we didn’t really know what to do with them. Had it had it like actually take this and transform it into like a systemic practice. And, and so that’s, that’s what I tried to bring to, to, to the doing of the thing. And in order to, I mean, one we talked about because like I the the job market in Philly didn’t support me doing this as a part of a larger company. But I also wanted to have the space to experiment and figure out how to do this work for myself. So I started a consulting company and it was supposed to just be me. It was called Fishtown Analytics and dbt at the time was kind of it was a consulting delivery tool. It was like just something that I knew that I needed in order to like, deliver consulting work. So that’s that’s kind of the roots and everything at the beginning was about like, how do I efficiently do this type of analytics work in this new tooling stack that not that many people knew how to use back in 2016?

Josh: Did you have the ambition or interest in building a product company out of this consultancy, or was it more by accident?

Tristan: I had always worked in my like start in my time at startups. I had always worked at product companies. And so I, I loved the idea of building useful things that, you know, scale and, you know, scale well beyond like the number of hours in your day, which is ultimately like where you can get in consulting. But I was I was also very I felt very burned out by the the venture funded route. I had been in three startups. All of there had been like a mixed bag in terms of like how successful we had been. And there was just a lot of overwork and excessive focus on KPIs, KPI, achievement at all costs. There was a lot of this like not good part of startups too. And so I, I actually really was resistant to the idea of creating a product focused company at first because I didn’t want to subject myself to all of those kind of like negative pressures that that I had seen in the past. And that’s why, like, it turns out that. If you wait and if you can, rather than, you know, day one. I have an idea. Let’s go raise money. Okay, now you’re on the clock. You don’t have any users, you don’t have any revenue, you have nothing. But you have a bunch of B.S. sitting in a bank account. There’s like a tremendous amount of pressure in that scenario. That’s not what we did. We put this off for three and a half years while we bootstrapped the business and, like, tried to figure out if this is something we wanted to do. But by the time we did eventually go down the product company route, the VC funded route, we had a thousand companies using dbt every week. And we had like meaningful, meaningful product revenue and like customer count. Changes changes the dynamic there.

Josh: Yeah. So today in dbt, how does the heritage of consultant work and bootstrapping affect how you run the company now or how the product looks now, how you interact, interface with customers like what’s the what are the downstream effects on that for you today?

Tristan: There’s a couple different long lasting impacts there. I think the biggest one is the dbt community. The dbt community originally was. It was actually called Analyst Collective. There was like a logo for it. It was it was not focused on dbt. It was just like a place for people doing this kind of work to hang out together and and talk about, you know, best practices and commiserate and. You know, Drew and I and later, Connor and Aaron, were just like more people in this Slack channel, like talking with everybody else. And over time, it became as dbt grew in popularity. And this became a place where people could get support, could talk to each other about best practices, that kind of stuff. It we actually did change it to being explicitly this is the dbt community. But I think that there’s been a lot of observations about how the dbt community feels different than a lot of communities that arise around a softer product. And I think that’s really because, I mean, one, it’s because the thing is open source and that gives users a different relationship to it than if this were a commercial product. But but also it’s from the legacy of, you know, we. We intentionally when we rebranded the company from Fishtown Analytics to dbt Labs, there was there are a lot of folks who were who said, why don’t you just call the company dbt? And you know that the, you know, Looker is a product and Looker is also a company. Like, you don’t typically it’s very common to like call the product in the company the same thing. And we were very uncomfortable with that. We are not. dbt. dbt is a product and there’s also a community around dbt. We are the company who primarily maintains dbt, but we are not ourselves dbt. We’re dbt Labs. And so I think that this this like community dynamic would could only really have arisen in an environment where, like, we’re peers out there. We’re like figuring out how to do this work all together.

Josh: So there’s really to the topic of this distinction between the product and the company. I can imagine how your heritage coming from consultancy helps crystallize that distinction because the organization is the people. The people deliver the service. You invented the product to help you deliver the service, and now you have a product. But really, it’s the people in your in your company that make up the organization. What I think of your organization, dbt Labs, there’s really two things that I think about as an outsider. One is dbt and the other one is analytics, engineering. And that being an area and a term and a role that I’ve seen your company really, really champion within the market and and in large ways invent. So I’m curious if you see, you know, it sounds like you’re framing dbt as one of the potentially many products that you may ultimately deliver, if I’m reading that correctly, is how do you view analytics, engineering in that in that context, is that one of many roles that you see yourself delivering to, or is that more of a a centralization, a point of centralization for your company?

Tristan: Yeah. Okay. This is this is a great topic. The I’m going to try hard to to say useful things because my brain starts spiraling off because this is such a big topic.

Ryan: That sort of happens when Josh asks me about marketing. It’s the same thing happens to me. I just I start saying a bunch of stuff and then I’m like, you good? Okay bye.

Josh: Help me stay single threaded. Yeah, if you need me to.

Josh: Okay. What what is analytics engineering in the first place? How is it different than data engineering? How is it different than analytics? The and I don’t know if it is a perfect term, but the reason that I think this term came to mean something was that there, historically, the process of analyzing data as done by people who often call themselves data analysts, was very bespoke. Every time you asked a discrete question, a data analyst would kind of start from scratch and would, you know, go find the data needed, would go through the whole analytical process when output and answer and. Um, the, the problem with that is that organizations tend to want to add new information inputs and ask new analytical questions over time. And if every time you want to answer to a new question, it takes the complete span of that. You have to do all of those steps of the process. You find that. Your pace slows down and down and down over time because you wanted that dashboard last week, but you want it again this week. And so do you want the same data analyst to be just like literally my entire job is producing three dashboards and I do that once a week and that’s all I can do. That, like legitimately, is how a lot of data analysts spent their time prior to analytics, engineering that. Analytics Engineering asks you to apply engineering principles to this workflow. So, and, and rather than thinking about it as engineering analytics, I actually think about it as engineering knowledge or knowledge flow through an organization. So rather than like this bespoke trade craft process whereby a data analyst, the expert goes out into the field and, you know, does detective work? Instead you say like, okay, what’s the information flowing into our company? How do I make sure to make it available in a place where everybody can access it? How do I make sure to make it available in a format that is comprehensible, that is documented? Then how do I make sure to structure that information in increasingly intelligible ways? So instead of having to go to eight different systems with eight different customers tables, and I make sure to organize that all into a single customer’s table so that I can, you know, I or any anybody else that wants to ask questions about customers can just go to this one table and do this. So it’s like applying these successively higher order abstractions on top of the, the like raw data that comes into your organization such that the asking of these analytical questions can happen with greater and greater velocity over time, and that’s just greater and greater velocity. But like more and more people can participate in that in that process because we’re we’re actually constraining the surface area that they have to work across. How’s that for a starting point?

Josh: Yeah, well, let me try to disentangle my wirey question there. So it sounded like from. So you explain how you were how you don’t view dbt as synonymous with the company, right? Are you telegraphing there that you may roll out new products on top of dbt?

Tristan: We’re focused on the practice of analytics engineering. Now, I say it that way because there are there are people who their actual job title is the analytic and analytics engineer. And that’s great. And there’s a lot of you know, a lot of them use dbt and wonderful. There’s also a lot of people who use dbt who their job title is not analytics engineer. You know, there are people who primarily spend their time in the lower level, like data engineering work. There’s people who spend most of their time in the higher level data analyst work. And but, but they, they also participate in the analytics engineering workflow. And so that’s that’s where we are primarily focused and that might be other tools in addition to dbt in the future. I can’t see, you know, in the complete fullness of time, but like right now, I think it’s safe to say that, like, we’re extremely focused on dbt.

Josh: Yeah. Yeah, of course. So but the scenario here is like if the critical mass of analytics engineers, however you’re drawing that demographic, if your read on them was that their needs have shifted from like the core capabilities that dbt is covering into some new domain, into some new territory because of some changes in the market, the technology ecosystem, the needs of these folks, then you would move with the demands of that demographic, of the analytics engineers, and that might take you in totally new product directions. It could be data ingestion, it could be closer to monitoring. It could be closer to different types of workflows that may go outside of that core dbt capability zone. Am I am I understanding you correctly?

Tristan: Yeah, I think that’s fair. I want to stay away from saying like like I very specifically don’t ever want to build a data ingestion product. I’m on record as saying that in the past. I will say it again here. I also don’t want to ever build a BI product. I will retire before I. Before we build a BI product. But. You’re. You’re correct in saying that we’re more focused on the needs of this persona than we are in specific product surface area. And this is a conversation that I know you and I have had before that the. The thing about dbt, you know, you take a an orchestrator like airflow. The thing about airflow is that you can do. Really essentially anything that you want in air flow, it it provides you a set of tools that you can kind of use in whatever way you choose. dbt is actually very opinionated about that. The workflow that it wants to see you go through it is it is about enabling a specific workflow. And I think. We have seen it at the outset. This was like at the outset, like in 2016, 2017, our, our opinions, you know, things like. You know, bring the code to the data and not the data to the code. Things like SQL is the language that most data transformation workloads should be expressed in, like, etc. Like all of these things are like extremely controversial and the 2016, 2017 time horizon and they are becoming less controversial. And I think over time we’ll find that actually analytics engineering is not this like subset of all workflows. It’s like a framework to think about how, you know, appreciably all knowledge flows through organizations, at least all quantitative knowledge.

Josh: And just on this this topic of of dbt and Airflow, something that we did catch and I think a recent product product blog or publication you put out around the new Python language dbt models, which seems to be moving closer into Airflow’s territory.

Tristan: I could see why you would say that. To us, the the real question and I referenced this a second ago. We believe in LTE instead of ETL. So data has weight. It actually takes real work to move it from place to place. And so what you really want to do is be able to, you know, move your data some centralized location and then operate on it when it’s there. And so the reason that dbt. Has strictly been exclusively focused on sequel is that that was the language that the major cloud data platforms primarily used. You look at BigQuery, Snowflake, Redshift, like these were the the big platforms when we were getting started that that mattered. And if you wanted to use those, you used sequel. And now that’s changing every one of these platforms. I know for a fact. Snowflake BigQuery. Databricks they are they’re all releasing native capabilities to, you know, operate in non-secure languages. So from DB perspective, we it’s, it’s not that hard for us to support functionality that the data platforms inherently expose where we’re layer on top of the data platforms. And you know, if, if they had had Python natively back in 2016, we probably would have, you know, built it then.

Josh: Makes sense. Well, on the topic of moving with the direction that analytics engineers are taking you and frankly, I not that I’ve all the experience in the world, but I know no other way of building a company than moving with the needs of your core user group and your ICP. But moving with those needs, what are the areas that have percolated within this group? What are the areas that you’re really excited about that you see as critical to to enabling the analytics engineers of tomorrow?

Tristan: Gosh, it’s a great question, and I’m happy to I’m happy to go all over the place there. It’s funny. It’s not actually a question that I often get asked on on podcasts. I’m great and I’m like excited to have the opportunity to talk about it.

Ryan: That’s what we’re trying to do. We try to stump the chop. That’s the main goal of this podcast. Really make you think you’re Tristan no softballs. We don’t have any softballs on this podcast alright.

Tristan: So okay. How do you build first class analytics, engineering infrastructure without. Having the capabilities of the kind of data teams that Uber and Airbnb and Pinterest and companies like this popularized in in the 20 tens. Because if you can afford hundreds of data platform engineering head count, then like, yeah, you can build some good stuff, but we want the rest of the world to have access to this too. So. We really care about fantastic orchestration. A lot of orchestration today is fundamentally a layer on top of crown. It is. You know, invoke this pipeline on a schedule and that is. Kind of. And that’s how that’s how dbt cloud works, too. And not like casting any aspersions here, but but I think that once you move towards a more framework type of world where like the the framework that you’re writing, you’re expressing all of this in actually understands what it is that you’re expressing. And you can start to do more powerful things. You can start to actually express declaratively what the outputs are that you would like. You know, I would like this table to be fresh as of, you know, this window as opposed to I would like this job to kick off on the schedule. So there’s there’s a lot of I think that is that is really interesting from an orchestration perspective.

Josh: Can I, can I pause you?

Tristan: Yeah, sure, sure, sure.

Josh: I want to chew on that for a second.

Tristan: I’m not going to go too detailed here because I want to not like I said, there’s a couple PMs on our team who will be very upset if I burst their bubbles.

Josh: Okay. So you don’t have to go too deep. But what was what was interesting from when I paused what you just said, which I had not heard before, is, yeah, we know of orchestrators that say, I want to run this job at this point in time. What you just said was, I want to get to this result.

Tristan: Yes.

Josh: At this point in time, I want these people to be.

Tristan: If you think again about like the persona question, analytics engineers versus data engineers, data engineers tend to be more technical. Analytics engineers tend to be more and tend to be closer to the business. And so it is one of the reasons why SQL is a really natural fit for the analytics engineer persona, because it’s declarative. You describe what the output should look like. And then there’s this whole optimizer that’s actually constructing the, the best query plan for your that the output that you’re looking for in the same way. But whereas data engineers tend to prefer more control like more imperative languages. So in the same way with schedulers, you can say like, Hey, please do these things, or you can say declaratively, here’s the output that I’m looking for. I think that that is more aligned with the analytics engineer persona.

Josh: It’s interesting because I think we we would see. A similar pattern in our use cases where, yes, it seems there are folks on the team that are more in a give. Kind of position, the data engineers that work upstream that are delivering data into some location and then the receiver, the receiver group being potentially analysts or data scientists, analytics engineer, maybe being somewhere in between that is more results oriented in a way. You know, the folks upstream want to make sure that jobs start at a particular time and they’re running efficiently and are pulling in data as expected. And then the recipient group being more oriented, that results arrive at the at the right time and are complete as as they define it. It’s a very it’s a it’s an interesting it’s an interesting characteristic for an orchestrator, because that seems like a very it’s a it seems to leave a lot on the orchestrator to decide how to run to get to the result. That you declare as opposed to describing how you want the process to start. That sounds like a a hard problem to solve. Is that that’s an area that you’re spending a lot of resources thinking about.

Tristan: It’s an area that we’re we’re very interested in. It’s more like. You know, you asked a question originally. What are the things that we think need to improve for for the analytics engineering in the coming years? I think this is one of them. We’re still in the early stages of like like you said, it’s a nontrivial shift to make. And and and we’re still in the early stages there. But I but I think that there’s no way in which in five years we’re all invoking a bunch of stuff on a cron tab. It’s like not how that’s going to go.

Josh: Do you have a nice marketing term that we can use to describe this new.

Tristan: No.

Josh: Way that we want orchestrators to work?

Tristan: No. We will in the future. But. But we do not yet. The there’s there’s other stuff. It’s like very. So. As as you see the proliferation of the modern data stack. You know, inevitably there’s there’s lots of. Companies and teams who use it for kind of the use cases that it was intended for, which are kind of interactive analytics, like asking a question. Getting a dashboard, you know, this kind of kind of important but not mission critical use cases. They’re like internal focused, like, you know, by type use cases. And but but inevitably, some tales of the distribution will use. We use technologies in ways that you don’t anticipate. And so we had never anticipated that JetBlue would use dbt to deliver real time reporting to their gate agents to tell people where to get their connecting flight. Like never anticipated that in a million years. And but but what happens when you start seeing these types of use cases happen is that like the operational characteristics of the systems that you help customers build like matter a tremendous amount. And that’s not just like, okay, you have to make sure that things are working correctly. There’s high availability, but we also have to make sure that. You know that this is a real data product. It has to be plugged into the same monitoring systems that JetBlue has for their other, you know, life products. It needs to have the same kinds of escalation pathways that, you know, you know, large companies have very regimented requirements for escalation pathways to different levels of hierarchy inside their organizations. And they all do it through, you know, that systems like Datadog and Pagerduty and things like this. And so we we care a lot about as dbt becomes increasingly mission critical infrastructure to to plug in to this type of this type of stuff that again, I just named two different things. We could we could talk about this forever. Like I care about a lot about the development experience. If dbt for a long time has been accessible to pretty technology forward users who are like willing to install a bunch of stuff and learn a bunch of new skills. And increasingly, that will be something that you can just an experience that you can just give to a new member of your team who doesn’t know how to use the command line or get there. And they can they can have as wonderful of an experiences as you did when you knew all of these magic incantations.

Josh: So I have two questions, and as I typically do, I really want to ask both at the same time. But I’m enforcing a lot of discipline here to tease them out. So first question, you mentioned before business intelligence applications. You never want to go to integration services. You never want to build that. Why? And, you know, how hard will you draw that line? And you know what if all the analytics engineers out there tell you we need it, you know what? What guides your your the boundaries that you’re setting here?

Tristan: Yeah. Okay. I mean, partially, I’ve I’ve built products that do both of those things in the past and it’s really hard work. And I actually just it’s not something that I am personally excited to do. Again, like God bless all the people out there who are moving data and creating charts and dashboards. I’d much rather let them do what they’re good at. You see a question about. But analytics engineers and what they need. So one of the things that. I really love about our ecosystem. And and, you know, maybe it’s just because we’re early on in the development of this ecosystem or maybe it’s. Maybe we’ll be able to keep it like this. But it is very focused on modular solutions and constructing best of breed. Technology stacks. So. It is a feature that dbt does not do data movement. That means you can use any of your, you know, data ingestion tooling with dbt. It’s a feature that dbt does not have a BI tool means you can use any by tool with dbt. And that’s what you see. Like dbt is increasingly standard way to do data transformation in a very heterogeneous technology environment. And so there’s a lot of questions about. Well, internally, we have a lot of questions about, you know, where the edges of what we should be responsible for. And we we take it very seriously that like the less we try to do, the better. We we really love trying to solve customer problems through a solution, an ecosystem approach, as opposed to like trying to like launch a new service that competes with five other existing things and try to take market share. Like that’s just not how we work. It’s not how really the modern data stack ecosystem works, though, at least today.

Josh: Very related. But as your community grows and the amount of voices in the analytics engineering space increases, how do you gauge what the community wants? And are there concrete things that processes that you’re finding yourself experimenting with now or or laying out or things that work really well that helps you keep track of what folks are asking for and make sure that that you are building in the in the direction that the market is is moving.

Tristan: It’s a it’s a very, very big question. And I don’t know that we. I don’t know that we have a perfect answer here. We we have a community team that has eight people on it. And two of those people are advocates and community advocates who like their reason for for being at the company is to. Bring the company and the community closer together, like build personal relationships. Know when you know a new meet up, needs a speaker and know who the perfect speaker is for that meet up and you know, etc.. These kinds of connections happen all the time in the community. We’ve crossed 30,000 people in dbt Slack and you know, in their early days when there’s, you know, a couple hundred a couple thousand people in there. If you had feedback, you just popped into, you know, popped into Slack and you just said what you thought in your feedback, but there’s enough humans in there that that’s that’s not always as effective as it used to be. So, you know, we’ll probably do we’ll probably do some more intentional things to try to fill that gap moving forward. So probably have a community advisory board that will you know, have rotating membership. And I. Want to find ways to. Continue to be engaged personally. You know, I used to pop into issue comments. I used to pop into slack threads and and just hang out. I do that less often than I used to. Mostly because I don’t I don’t actually know that people want the CEO to just kind of. Be watching over their shoulder as they, like, give feedback on the product. If I don’t like have a personal relationship with them. So I don’t know. We’re kind of like growing up as a community and we’re, we’re having to figure out all these much more intentional ways to do things that used to kind of happen just naturally without having to think about it.

Josh: As another practitioner in the space, I can say I don’t know if there’s a single other solution out there where I’ve met as many rabid fans and proselytizers as dbt. So you’ve done something right and you’ve enabled a lot of people to enjoy their their work a lot more than they otherwise would have without without your solution. So I’m sure it’s it’s rewarding to see that difference. And we’re certainly excited to see the different directions of the product and a small, shameless plug. But we did just roll out our own great dbt integrations. So we’ll be riding your coattails a little bit there. But now I appreciate in seriousness what you’ve done for the analytics community and excited about what’s coming next for you all.

Tristan: Awesome. Thank you.

Ryan: Tristan, so as we wrap up today, give us how people can reach out to you. Do you have a blog, Substack, LinkedIn? And then are you going to be at any upcoming conferences soon?

Tristan: I will be at Snowflake’s conference and I will be at Databrick’s conference soon. I am on Twitter as @JTHandy and I write every other week on [email protected] So would love You know, certainly subscribe or follow me. But more like say hi. Like if you want to pop into dbt Slack, like feel free to DM me. Tell me what you’ve got going on, who you are and how you found your way here.

Ryan: Well, Tristan, thanks again for joining the MAD Data podcast. Really appreciate your time and hope to go to Philadelphia soon. I hear it’s a great place.