dbt Labs Founder Tristan Handy

In this week’s IA40 Spotlight episode of Founded & Funded, Madrona Partner Jon Turow talks with dbt Labs Founder and CEO Tristan Handy. Here at Madrona, we just announced our 2022 IA40, and dbt Labs is one of our two-time winners. The company has positioned itself as the industry standard for data transformation in the cloud, and it raised $222 million at the beginning of the year, which was led by Altimeter, but Databricks and Snowflakes both participated in the round, further solidifying dbt’s place and the modern data stack.

Jon and Tristan dive into the concept of epistemic truth, how the modern data stack has significantly improved the frontier of what’s possible in data, the collaboration that needs to happen between data analysts, analytics engineers, and data scientists, the right way to use partnerships, and how the best way to try and create a community around your product is to not try and create a community, but you’ll have to listen to Tristan’s explanation. So I’ll let Jon and Tristan take it away.

This transcript was automatically generated and edited for clarity.

Jon: I am thrilled to have Tristan Handy here, who is the founder of dbt Labs. Dbt is an analytics as code tool that has quickly become an industry standard, and it has championed a new type of role — the analytics engineer — whose job it is to provide clean data sets to end users by modeling data in a way that empowers end users to answer their own questions. And with all this, they’ve attracted more than 9,000 weekly active customers and a Slack community of 38,000. So, thanks for joining Tristan.

Tristan: Yeah, thanks for having me. To set the record straight, we are at 15,000 companies using dbt today, which is really unbelievable. I remember in the early days thinking, “Hey, maybe a hundred companies would use this thing.” So this is a very unexpected world that we’re living in.

Jon: Maybe unexpected, but you do have a very special product and community. Tristan, to get us started off on the right foot, can you tell us in your words what exactly is dbt?

Tristan: Dbt has two parts. It has a commercial part, it has an open-source part. Overall, dbt wants to enable data professionals to work more like software engineers — to steward an analytic code base that describes the reality for an organization, or at least as close to reality as we can get, and allows people to move quickly. So it doesn’t unnecessarily force people to go through a bunch of hoops, but it allows people to work with a lot of maturity and governance with confidence that the data is accurate and timely, etc. So, the open source part of dbt is all of the language features. It’s, how do you write dbt code? How does it run against a data warehouse? And then dbt cloud is functionality that makes it easier to run dbt in production, makes it easier to write dbt code this kind of stuff.

Jon:  So, considering the two sides of dbt, how do you think of who is the customer and what problem he or she is trying to solve?

Tristan: Let’s leave the word customer for a second. If I can just talk about users for a second because those two things are not the same in an open-source context.

Our users are folks typically on data teams or who are at least in a line of business that is very quantitative. Their companies have invested in modern data platforms, you know, Redshift, Snowflake, Big Query, Databricks, etc. And they are tasked with either providing clean data sets to folks who are going to answer business questions, or they are themselves tasked with answering business questions and need to do data preparation to get there.

So the core problem, and I ran into this back in 2015, which is kind of where the initial insight came from, but I was involved in launching a product called Stitch, which is a data ingestion tool. When we launched, it was just pulling data from about 10 different SaaS products into Redshift. And I got to use some of this data, and it was awesome. It was amazing to have my hands on all of this without having to do any CSV exports and VLOOKUPS and all this stuff. But the amount of data was pretty overwhelming. I remember having to do an analysis for Facebook ad ROI, and I was looking at literally a hundred tables in this one schema, and I was just like, this should be easy. Like, there should be a table that has campaign names and dates, and it should tell me the ROI. And it turns out that you actually have to make that for yourself. And so, dbt is the tool that I initially built for me to sort through all of these ingested data sets and turn them into the thing that would actually be useful to answer business questions.

Jon: So you’ve spoken about your users, but who are your customers?

Tristan: It really spans from one-person data teams at 20-person seed-funded startups all the way to some of the largest companies in the world with the most data professionals. Super high level, we started the company in 2016, dbt barely exists, we land a small handful of consulting clients, and a small community develops. We continued to bootstrap the business over the course of three and a half years as a consulting company. Over that time period, the dbt community grows to about 4,000 individuals, and there are about a thousand companies using dbt in production. That’s when we raised our first round of funding. At that point, the company had maybe eight or nine consultants and four or five engineers, and that was it. That was the whole company. We did have a SaaS product that was hacked together by these very small number of folks, but it was a way to help productionize dbt. You write all this dbt code that does all this data transformation, and you need a way to actually run it in production on an ongoing basis and to do logging and alerting and all of this kind of stuff. And so it provided all of this around the edges of the kind of open-source experience. It barely existed when we first raised money, and since then, it’s grown very quickly. It’s turned out that dbt scales well into the enterprise, and that’s something that I think you often don’t find because the enterprise needs a different set of features and functionality to deal with the complexity there. But what we found as essentially a developer tool is that as long as we are providing the language constructs that people can use to describe their business, we don’t get caught up in a features and functionality conversation going into the enterprise. So I think we’ve had a little bit of a smoother transition there.

Jon: So, you know, before we get a little more technical, I want to talk about a concept that you’ve spoken about a few times, which is the concept of epistemic truth. Can you talk about an example of how truth has played out with a customer and the analysis that you’ve run, and how the customer has benefited from that?

Tristan: I’ve become very interested in this topic, and I’ve realized there are actually two parts to it. The first one is how can you know that something is true? Originally, I was of the opinion that your e-commerce company processed a certain number of orders yesterday, and that number of orders was simply the ground truth of the matter. And our job was to write analytic code that reflected that ground truth of the matter. What I have come to believe on that topic is that that is insufficiently nuanced. If you look closely enough, there are always these cases of, like, well, does this one count? It was returned? Does this order count, it was, whatever, in some different state? It turns out that the question, ” How many orders did your company process yesterday,” is actually undefined without additional specificity. And so, what we do in our companies is we create these windows into the world, and we kind of socially construct these definitions.

Let’s leave the concept of ground truth for a second. And what I actually believe the job of data teams and dbt to be doing is that we need to steward this social construction process. So, what happens in many companies is that there’s a tremendous amount of chaos. There’s no accepted definition for metric A, metric B, metric C, so as a result, you get a lot of confusion about — “How do we talk about our reality?” There’s no good way to have a conversation about reality when everybody’s using different definitions. And so while I don’t think that there’s a way to reflect ground truth about the number of orders, there is a way to run a social process whereby the end of that social process is, we all agree — even if this is not the perfect metric, it is the metric that we use, and we can all consistently use it to talk about our business. And it turns out that like this is something that software engineers already know how to do. There’s no such thing as bug-free code, but there is code that works in production, and there is a process to get that code to production. And there’s a process to when you find a bug in production, like what do you do about it? So the goal in software engineering is not to architect some perfectly working set of routines. It is to build something that basically works and that you know how to, over time, continue to iterate toward correctness. That’s a big topic. I hope that was useful at all.

Jon: It’s very useful. My question, though, is how organizations have responded to that kind of discipline with the benefit of a tool like dbt? Has that changed the thinking that they did — the decisions that they made?

Tristan: Here’s how I’m going to try to answer this question because it’s a big one. How have organizations responded to dbt and dbt’s way of thinking? I think that that is very mixed. It’s not surprising that it would be mixed because there’s this Harvard Business School article from like the early ’90s that essentially says the primary task of any company is to create and disseminate knowledge. Everything’s changing all the time, so this group of humans who are here to advance a goal, that the most important thing that we do is figure out how to learn new stuff and then spread that learning to everybody else. So, you would then expect — and I would not actually say this is just in response to dbt, but in response to what in the industry, we would call the “Modern Data Stack.”

I think the modern data stack has very significantly improved the frontier of what is possible in data. And it’s not that any one given analysis using the modern data stack was not possible previously. I think about it as this kind of two by two — and on one axis there’s governance. Like, do you have any control over how knowledge is flowing through your organization? Can you trust it, etc? And the other access is velocity. And previously you could have things that were fast and not very trustworthy, or you could have things that were very trustworthy and incredibly slow — but you couldn’t have fast and well-governed.

And what the modern data stack has allowed companies to do, who really adopt it, is to get fast and governed. The implications of this for how organizations operate, I think, will be continuing to play out for a very long time.

Jon: Let’s take in a little bit to dbt and the sort of world around you. Way back, how did you get the dbt community started? How did you kick that flywheel into motion?

Tristan: I think of this as, you know, the best way to see stars in the night sky is to not look directly at them because it turns out that the edges of your eyesight are much more low light sensitive. And I think one of the best ways to start a community is to not try to start a community. Sometimes I field questions from software founders who have gotten from zero to one, and now they’re thinking about scalable marketing channels to continue to grow. And they say, “Ah, I want to start a community.” It’s like, I, that’s not generally how that goes. For us, we were practitioners, we were trying to solve real problems. We were using dbt as a tool in solving those problems, but we were not really just talking about dbt, we were talking about the problems that we were facing in the context of doing the kinds of analytics that digital native businesses do. And so we had a Slack group, and the Slack group was like for our little network of people to kind of collaborate. And three months in, we ended up working with a company called Casper. They were really very central in the New York tech community in 2016. Their data team was like a dozen people. And they hosted meetups and all this stuff. And as a result of this project that we worked on together, they adopted dbt, and they became this kind of central locus. They brought other folks from the New York tech community and told them about this new tool that they were using. And things have kind of spread from there. And Drew and I, who don’t live in New York, we were kind of observing all this from afar. We just continued to be helpful on Slack, and people were trying to get set up and running, and people were trying to absorb the things that dbt kind of assumed about how you were going to work. We just worked with people without any expectation of an immediate payoff there. So if I were going to kind of summarize all that — create some focus that people can kind of organize around and then just provide value. But then do it for a very long period of time. I mean, it was years and years before there were a real meaningful number of people in there.

Jon: You know, one thing I asked myself looking at the history and the growth of all of this is at what point did you start to get access and support from bigger tech players who were in the ecosystem as well?

Tristan: Hmm. Like as users or as partners, or…

Jon: However you would define it. If you think about the hyperscaler clouds — AWS, Azure, GCP — or you think about Snowflake or Databricks or whatever else. Did you get engagement from them? Did you get what you needed? Would you have liked to have more in looking back?

Tristan: For a long time, we thought that that would be a really big accelerator. In the early days, we tried to get the Redshift team to talk to us, and they were like, “Come on, two guys with a little open-source project. Like, sorry, we don’t have time.” And that’s, that’s fair. That’s like probably the right decision on their part. But what that ended up making us do was we learned Redshift inside and out. Like I, I don’t know that there’s that many people in the universe that know the Redshift optimizer as well as my co-founder Drew. That story has played out similarly with, other big tech companies over the years. I think that what we’ve learned, and certainly at this point, we do have fantastic partnerships with really all the major players in our space. But what I’ve come to terms with is that if your product is unique and if it assumes that users are going to need to go through some learning, some mindset shift in order to use it, then really you’ve got to do that work yourself. No other vendor is going to understand how to sell our version of reality — that’s on us. And maybe we can get invited to do road shows with partner A. We can get on invited on stage at partner B. That stuff is really good. It’s good exposure, but like at the end of the day, none of that stuff matters to us as much as being consistent with our own messaging, consistently growing our own community of users, getting them to see the value, and getting them to share that value with their colleagues.

Jon: Got it. That helps.

Tristan: Let me just say, though, we would not be successful without our partners. No enterprise technology company, I think, is really successful without its partners. But I think that sometimes, especially founders in the earlier stages, think that partnerships are going to save them. And that’s not true. You have to do the work yourself, and your partners are an accelerator once you’ve done the work.

Jon: And you’re in the other position now where you’re the captain of an ecosystem, and you can see any number of younger companies — Features & Labels, Continual, Monte Carlo, Datafold — who explicitly are playing in the dbt ecosystem. And they are finding their own path. If you speak to any of them, they’re going to tell you why what their building is important and how they’re making it happen. But as the captain of that ecosystem, how are you able to help, and what should new founders know who are going to forge that path in your orbit?

Tristan: Yeah, you’re totally correct that we’ve had to do a lot of navigating on this front ourselves over the past couple of years. I have never been at a company that is in the position that ours is. So, I don’t know how all partnerships teams think about this, but my guess is that frequently partnerships are thought of primarily from a commercial lens — how do we drive revenue together? And not that that’s unimportant to us over the long term, but we are a community first — we’re open source first. And so, our primary relationship with partners is one of neutrality, which is a strange thing to say, but actually, the last thing that we want to do is try to influence the technical choices of our community members by putting our thumb on the scale for one partner versus another partner because they drive more pipeline. We think that it is a real privilege that so many companies have chosen to use dbt. Dbt has become the standard for the layer in the modern data stack that we are. And, if we are going to continue to be trusted in this way, we have to act in a way that is good for all of the community as opposed to just constantly pushing things toward our own commercial interest.

So that’s, that’s lens one. You know, how do we stay neutral here and create space for these vendors to participate? The second part of this is we want to paint a vision of where we hope and believe that the ecosystem can go so that vendors can try to figure out if they are aligned with that. And if so, how do we work together to get there? Because any vendor that is explicitly trying to build toward the same type of future that we envision, we want to roll up our sleeves and do everything that we can to make that happen with you. We have this explicitly ecosystem-focused view of how the future will unfold. What that means is we cannot sit in a room by ourselves and just decide on a product roadmap for the entire ecosystem. That’s not how that works. We can talk about where we hope everyone will get to and what our part of that can be, but then we need everybody to build all those different puzzle pieces.

Jon: So how do you signal to the ecosystem what principles or visions you have for the future?

Tristan: I get one time a year to talk live to everybody in the community — my Coalesce keynote. I have a newsletter, that I use to test ideas and also ask challenging questions about the future.

One of the interesting things I think about this ecosystem curation role is that many technology companies only want to talk about how amazing their stuff is. But if you think about the future, inevitably, if you want to improve along some axis that then you are implicitly saying we are not as good today as we would like to be along that axis, which is something that, I think can be very uncomfortable for many commercial software companies. But if we don’t actually paint that vision of the future, and if we’re not transparent about the ways in which the lives of practitioners today probably could be better than we’re not going to be able to all get there. I think this is one of the interesting tensions between open source and commercial. Open source wants to be talking about all of the terribleness that we all live in today and how tomorrow we’re going to build the following things to fix it. And commercial wants to be focused on, “Look how amazing the world is today.” So, we have to do both.

Jon: Well, let’s talk a little bit about the, the technology environment. You said that dbt was created to take advantage of all this latent compute available via SQL run times, and now there’s new things like Snowpark or the notebook Runtime from Databricks that you, Tristan, and you dbt can access that same compute now with the flexibility of a procedural language like Python. What are the implications of that for what dbt can now achieve that you couldn’t achieve before under the covers for your customers?

Tristan: I come from a sequel background. I think dbt’s original M.O. was to take people like me who were not fully fledged data engineers but were reasonably technical data analysts and to give them tooling to build mature data pipelines. This made sense because originally Redshift and later — Snowflake, Big Query, Databricks, etc, — they had this, cloud infrastructure that all of a sudden, you didn’t have to think about, how your, compute and storage was provisioned. You just signed up online and clicked a few buttons and, maybe, opened up an IP address in your firewall, and you had infrastructure. This was a permissionless way to get a new set of capabilities into a lot more hands. The challenge there, though, is that that’s only a subset of data practitioners. There are the folks that consider themselves more data scientists or statisticians or other folks who are using more statistical methods in their work. And then there’s also a set of folks who are less comfortable describing all their work in code. If we take seriously the idea that dbt’s job is to create and disseminate knowledge, that’s not a job that is done exclusively by one role at a company. We’re trying to, over time, address more and more of these user profiles. So, while we didn’t start with Python because Python was not quite as turnkey as SQL was, we’re seeing the big data platforms roll out services that make Python more and more turnkey, and so we saw some of these innovations, and we said, “Okay, this is a great time to welcome a new set of folks into the dbt workflow.” And it’s a big experiment. It is actually the first time in six years that we have changed the primary persona of the product. And I don’t actually know if that means that the floodgates will open, and honestly, that was never our experience with our original persona. So, I don’t think it’s going to be our experience with persona number two. But what I do think is that over time we need to take data analysts and analytics engineers and make them share a lot more of their infrastructure and tooling with data scientists. The work that they do is too related to each other to be operating in these 100% separate ecosystems.

Jon: There’s something I don’t hear you saying, and I just want to press on that for a moment, if I may, which is that for the SQL persona, Jon Turow, writes some SQL, dbt’s going to go executed historically in SQL. Dbt now has the ability to execute Jon’s instructions that came in SQL, but by dbt’s choice, could be in Python instead. Does that give you the flexibility to do things that you’ve never done before? Have you started to look at that?

Tristan: I want to make sure I’m understanding your question right. In your example, you are writing SQL inside of dbt, and dbt is then turning around and running that SQL against a data warehouse. In the future, what if you wrote SQL and then dbt turned around and executed Python against the warehouse? Is that right?

Jon: Yeah.

Tristan: That’s theoretically possible. But here’s the way that we think about dbt. I don’t know if this dates me, but I learned to build web applications in the mid-2000s using Rails. I am by no means a gifted programmer — I figured out in my time how to build some basic web applications. But I think the only way that I was able to actually do that was that I had a framework that told me to put these files here, we’re going to wire them all together, and we’re going to kind of deal with the complexity. So, Rails doesn’t actually go about writing your code for you. It doesn’t express your business logic. It doesn’t do any real magic under the covers. It just provides you a framework wherein you can kind of focus on the high-value add activities and not focus on like, how a web request passes from M to V to C. So, we think about dbt in the same way. It is a way to create a lot of leverage for practitioners such that they don’t have to think about, ” Oh, what’s the create table syntax on this data warehouse?” or “How do I ensure transactional consistency” or any of this stuff that’s critical but it’s also kind of boring. We take care of all that stuff. But what that means is that the user actually has to ultimately express the thing that they want. And so with python in dbt, we’re allowing users to express what they want in Python, but dbt itself does not write Python on your behalf.

Jon: You’ve spoken about SQL as almost a TCP/IP layer between components of the modern data stack in the sense that it’s ubiquitously implemented and, therefore, kind of a lingua franca for those infrastructure components. But, of course, there’s the other benefit that very many people, very many information workers, at least can write bad SQL. The stories you’ve told Tristan, and that people told about you, is that you can write queries like music. But I, Jon Turow, cannot. I can write queries that run, and I think we see a lot of queries that are even sort of hacked and edited and remixed over Slack. So my question to you as an industry is, what do we need to do to further democratize and expand access to data and analytics?

Tristan: Okay, let’s start small and tactical. There’s remix culture in software engineering, right? This is a big innovation in music, and it’s where most content on the internet comes from at this point with memes. It exists in software engineering too. It’s like Stack Overflow culture, right? It’s something that is often made fun of, but at the same time, it’s tremendously valuable being able to say, “I have problem X, I am going to go find other people who have problem X” — and there is a way to find those people and to learn about their solutions and potentially adopt them. That’s incredibly valuable. We don’t really have that in data. And I think that there’s a couple of reasons why. One of them is that while you can share the code, you can’t actually understand what the code is doing without data. You can’t execute that code without the data that backs it. And often that data is proprietary. And so, while the code, some seven-line subroutine is not particularly proprietary, and generally employers don’t really care if you share seven lines of code on the internet, you can’t share a single row from a database on the internet. So, it makes it very hard to collaborate in this way.

I also think that there’s tooling that doesn’t exist. Data people generally have been kind of far away from the Git workflow, and so we don’t have the concept of a gist, really. There’s not a lot of like public code sharing in this way, and then commentary on it. This is one potential answer for DuckDB. Like what if something like DuckDB made it easy to kind of package up little data sets that you could run shared code samples on top of so that you could start to build some of this remix culture. Because not everybody has a computer science degree, but it turns out that by using Stack Overflow, you can still build some actual working code, and we need that to start to be true in data as well.

I also think that since dbt kind of took the hard line that we needed to bring Git into data teams, we’ve seen more and more products bake Git in as a first-class element of their experience. One of the elements of the “SQL process” is that none of that SQL that’s kind of passed around feels like it’s permanent, that it’s not part of some mission-critical working application. It’s just like a message that you sent to your coworker in Slack. But if you take that collaborative process out of DMs, and you put it into Git, you will find that just the mechanisms of Git and pull requests and comments will slowly tend the process toward higher quality over time. And I’ve watched individual data professionals go through this experience time and time again. And it has everything to do with the signals that their context is sending to them about, like, does quality matter? And then longer term, we could get into — how do you create a no-code tool that still participates in the Git workflow? Because at the end of the day, not every single person sitting in front of a computer for work is going to learn to write SQL. And that’s okay. And we have to also allow these folks to have experiences that give them the accessibility that they need but do not sacrifice, as tools in the past have sacrificed, that accessibility for quality. We have to be able to have both. And I think there’s ways to do that.

Jon: I just want to touch on something you said and maybe expand on it — there are these signals, either active or passive signals, that happen in the communication between producers and consumers of data or between consumers and consumers of data. You can even think about things like Amundsen catalog types of tools that add a social layer where if I know there are three fields called active customer, but Tristan uses the second one and might use the second one too for a similar query.

Tristan: I think that what we are fundamentally trying to do is not so dissimilar from what Wikipedia did. Whether you want to call it the grand total of human knowledge or whatever it is that Wikipedia represents. The thing that was built there was not some piece of software. It was a sociotechnical system. It was an interlocking between software tooling and community and individual motivations, and the end result was this process whereby subsequently, more and more information was contributed, and that information had a process to go through that could be more and more correct and more and more validated.

So, what I think we need to do inside our companies now is create a similar sociotechnical system. And it’s funny that most tooling providers don’t seem to think like that. They’re worried about capabilities. Does my thing do X? And what I think, actually, we need to start thinking about is — when I build my tool in the following way, what behaviors does that encourage this set of people to undertake?

And it’s actually not possible to know the answer to that at the outset. It’s a much more experimental mindset. And I think that in the past, enterprise software broadly, and data tooling as well, has not tended to think about experimentation as much as the consumer space has. But I think that what we’re trying to do is create this emergent behavior where companies are constantly contributing new knowledge and refining it and collaborating on it. And that’s not just a list of features that’s required to do that.

Jon: Super cool. So, looking ahead, we spoke about who are your users and your customers and what problems they all want to solve. And you’ve really been consistent about data analysis and data analysts and analytics engineers. You’ve separately spoken about how ML engineers occupy a different space in many organizations than their data colleagues do. They have different tasks. They get treated differently. They may have different tools today. But, of course, they still have lots of appetite for distilling truth from data. And my question to you, Tristan, is whether you see ML engineers as sufficiently similar to data engineers that ML engineers should also use dbt, or whether you think it’s such a different persona that they need their own community, their own technology, and their own product?

Tristan: I think that what I feel very strongly about is that the world of the ML engineer, the data scientist, should be less bifurcated from the world of the data analyst, analytics engineer. I’m not a maximalist when it comes to what should the product surface area of any given tool be. I have no need to conquer the world. I don’t need to convince ML engineers to use dbt if that’s not the right answer. Honestly, the thing that feels problematic today is that there are huge teams whose entire reason for existence is to take the upstream mess of data that flows into the cloud data environments and distill it into something useful. And that process typically happens twice — in most companies. A majority of that effort happens to support analytics and BI. But then there’s this separate effort that kind of does much of that again in support of machine learning projects. And sometimes, using today’s tooling that’s actually required.

Sometimes the latency requirements are completely different. There’s different types of transformations that are needed. Whatever. So, sometimes there are good reasons for this, But I think that we need to sand those edges off. This whole refinement of the truth process needs to happen as a collaborative effort. Now, if you take this truth, and you want to run ML models on it, and that process does not happen in the same stack, that seems completely reasonable to me. I don’t think that you’re going to find a lot of folks who are strongly opinionated that like Tesla’s self-driving car algorithms should also run inside of dbt. So there’s a line somewhere. But I think that we need to kind of bring this lower-level processing closer together and then kind of see where things go from there.

Jon: I think that’s a great answer. Just a couple more questions — I want to go through kind of a lightning round. First, either inside your ecosystem or outside it, is there a startup that we haven’t discussed today that you’re particularly excited about?

Tristan: Oh, oh my gosh. Okay. I don’t want to name a specific startup. There are actually two attacking a similar problem today, I honestly don’t know if it’s time for this problem to be solved, but it’s a problem that I’ve been asked to solve for 20 years. It is the ability to ask questions in plain English and get correct answers out of structured data. And the thing that I think these two startups are betting on, and with some success so far, is that large language models are the bridge that we have been waiting for to be able to finally do this. So it is way too early to tell if this is going to be successful. But I do think across the two decades of my career, it’s been kind of that thing that everybody wishes that they had for the data last mile problem.

Jon: We could pile out of that a lot, but I did say lighting round, so we’ll save that for next time. Second question. In the bigger picture, what do you believe will be the greatest source of technological disruption or innovation over the next five years?

Tristan: Hmm. This is a boring answer, but I still think that we’re incredibly early in the cloud transition. All of the work that we do is a part of the cloud story. And I think that people say things like, “Cloud adoptions is at 50% of enterprises globally.” But what does that mean? Does that mean that somebody bought an EC2 instance? That’s not cloud adoption. Cloud adoption actually implies organizational change. And that takes a long time. And I think that we’re still pretty early in that process.

Jon: Next question. What is the most important lesson, maybe from something you wish that you did better, that you have learned over your startup journey so far?

Tristan: I got a coach about three years ago, and it was the single most impactful decision I ever made. At the time, we spent 2% of our monthly revenue — this is when we were bootstrapped — 2% of our monthly revenue on this coach. But it ended up being money very well spent. I think that any leader has to come to terms with the fact that many of your instincts as a human do not serve you well in a leadership position. I felt like I was never good enough for the people around me — like people always wanted more from me or like I made a decision that wasn’t as good or that there’s always things that could be better. And as a human, you end up being very defensive I found myself wanting to explain, “Well, we had to do it that way because…” And a lot of times, your role as a leader is actually just to absorb those thoughts and feelings and just say like, “Okay, I hear you. Let’s talk more about that.” And that’s only just one example of, you know, something that I worked through with my coach. But I think that investing in the human side of leadership is just all too infrequently done and so, so important.

Jon: I will follow up with just one point on this. What have you learned about doing that in a Zoom world?

Tristan: I’m better at this on Zoom. I bet you that many people are better at it on Zoom because I think that sometimes getting into some of the harder human topics can be very intense when you’re literally right there with the person. I actually like having the safety of being like, “Okay, at the end of this, I’m going to close my browser, and that will be that.” I don’t know that that’s true of everybody, but I’ve learned to be really on and present via a screen in a way that I wasn’t actually as good at in person.

Jon: Tristan, thank you so much for your time today. I really enjoyed the discussion.

Tristan: Thank you. It’s been a lot of fun.

Coral: Thank you for listening to this week’s IA40 Spotlight episode of Founded & Funded. Keep an eye and ear out for coverage from our inaugural IA40 Summit. And tune in in a couple of weeks for our next episode of Founded & Funded.

‍