The Death of Data Gatekeeping: AI Makes Everyone An Analyst | Hex Cofounder

The fastest way to really annoy a lot of people is to have a system that's giving them consistently wrong answers. I think that the percentage of actual decisions that are made every day that are informed by data is really, really low. As sexy and cool as the things like the Notebook agent and Threads are, the thing I wind up gravitating to is actually the things we're doing around context management and observability and governance because that's the stuff that are going to make those answers trustworthy. Right, right. Palantir has generated a lot of successful founders because it is selected for and then cultivated people who are really interested in, I'm just going to go out, find a problem and run like hell and figure out how to solve it. Whenever you have these technical shifts that sort of settle in, you're just going to have a consolidation. There's going to be a few sets of people who really are able to win and accrue a lot of value and then other people who will get acquired or pivot or figure other things out.

Barry, thanks for being here today.

Yeah, thanks for having me.

Awesome to have you here. Um, so I wanted to kick off on a meaty topic. You talk to a lot of different data teams at different enterprises, and Hex is obviously a leader in the data space. The application of AI to data feels like the Holy Grail.

Yes.

Can you say a little bit more just to kick off on how you think AI is going to change the data space.

Totally. So it's interesting when you talk to people at enterprises, organizations, companies of any size, they've spent like 20, the last 20 years has really been chasing this promise of data democratization. I was in the analytics software space 10 years ago and data democratization was the buzzword everyone was saying.

Totally.

But it's not really happened. It's like we spent the last 10 years, the big change has been, it's been easier than ever to bring all your data together. You have the cloud data warehouse, you have technologies like Fivetran and DBT. So now we can get all of this data and then it's like, well, what are we doing with that? We're still just putting dashboards on top. Dashboards are really good for what happened and KPI trends. I love a good dashboard, but I would say dashboards raise more questions than they answer. Yeah, for sure. There's always this dream of, well, wouldn't it be great if everyone in the organization could use data to ask and answer questions? I think that the percentage of actual decisions that are made every day that are actually informed by data is really, really low. If you think about all of the different things that you could better inform with data and then the number of people that go through the whole workflow of, well, let me open my BI tool and find the dashboard and then find the right data and drill down and do all the different things It's very hard. And so obviously with AI, it's like the appeal of just being able to ask a question in natural language and get an answer.

Game changer.

It's so obviously exciting. And in fact, there's been demos and concepts and promises of this well predating LLMs. And so now with these AI technologies that are really working, we do have this potential and now a reality that we're starting to bring to bear. Of a world where everyone in an organization can ask and answer questions with data. And it's just enormously exciting.

Yeah, absolutely. Although to the point that we kicked off with, that this is the holy grail and it feels like it's becoming achievable. What are still the, or I guess what historically have been the blockers? What are they today and how is Hex helping your users overcome them?

Yeah, well, I mean, historically the blocker, pre-AI, the blocker and going back in time a little bit, we built Hex to solve a lot of the data problems we had felt as builders and users of data tools. I've spent my entire career building and using data tooling and was painfully personally aware of all the problems and gaps and issues and all the things that maybe more traditional BI tools and dashboards weren't solving. One of the big things that we had really focused on early on was this ability to go much deeper into questions. So a traditional dashboard, it'll show you a KPI, it'll show you sort of a one-dimensional thing, but if you want to start going and asking, well, why did that happen and what else was happening and what does that suggest about what's happening next? You'd wind up in this toolkit that was super fragmented, very messy. You're writing a SQL query here, you're downloading the results to a CSV, you're putting it in a Jupyter Notebook. None of these things are built to be collaborative, so you're trying to send these files around and you're sharing with a screenshot of a chart, put in a PDF of a deck, sent in an email. This is super painful, insane workflow. And so we started Hex to really solve that. And then if you think about all of the work that goes into doing that, even in something like Hex, which we made much better, there's still just a lot of steps to go and find the right data and get the right view on it and build a chart and get all the settings just the way you want and explore different paths and pathways. And with AI now, you can have a partner that basically makes that whole process much, much faster. And the interesting transition that's happened in the last couple years was going from this conception of, well, hey, we could just do text to SQL to a much richer and deeper sense of what these systems are going to be able to do for us. I think we're already seeing this now, but it'll just become more and more apparent. There's kind of three dimensions to this. There's going to be breadth, which is you're just going to have way more people in the organization be able to ask and answer data questions because that friction and that activation energy goes down so much. The ease of opening up Hex or opening up— we have a Slack bot now. You can just go into Slack and ask a question. It's just 100, 1,000 times easier than going and navigating through a tool and doing all the clicking. So you're just going to have way more people that are able to ask these questions and then they're going to be able to go much deeper. I think the cartoon version of it is these one-off trivia things like how many widgets did we sell last quarter? That's good information to have. Often you want to know how many widgets you sold last quarter, but once you have that information, humans typically, we're very curious animals, We want to know the next things.

Yeah.

We want to know, well, in which different categories and which salesperson was driving that? What channel were they getting that from? And what were the factors driving that? And what have been other quarters that we've seen a similar pattern? And there's all these follow-up questions you have about that widget number. And so depth is a huge deal. And I think maybe underappreciated way in which AI is going to really change the way people are using data and then speed, which I think time to insight is a thing you talk a lot about in the analytics world, how long it takes for people to actually get something. We always thought pre-Hex it was just this insane process as I outlined of trying to get answers. We collapse that down. We can collapse that down even further with AI where we can have an AI agent partner with you to go find those answers really quickly. But I'm interested in a world where that time to insight actually goes negative. Where—

Yeah.

As we start to learn more, as we start to learn more about organizations and teams and individuals and what they're interested in and what they're curious about and what matters to them, we can go and actually surface things to you before you're thinking to ask about them and not only surface something like, hey, this metric is deviating. We can attach an analysis as to why that might be and suggest some follow-up questions and bring that to you notification that you can have a whole interaction with without having to go through a really complex workflow. And that future, we think of it as ambient analytics feature that is extremely compelling and just very, very different from the way people I think had conceived of what data tools or dashboarding products could or should be not that long ago.

Ambient analytics. I like that. Coined here by Barry McCardel. Side note, I'm very excited for a16z to roll out the heck Hex Slackbot. That's what we need.

Yeah, you guys are actually great Hex users.

Yes, we are.

Very ironically, it took a little while for you guys to get all the AI security and data access stuff. Which I guess makes sense. In some ways, you guys are a very good example of a complex financial services firm. You have a lot of sensitive data and you really care about it. I do think that actually is, jokes aside, really exemplary of what seeing in the market, which is every enterprise in the world, especially those with a lot of data like A16Z and many, many other enterprises, the appeal of being able to use AI to analyze data is so obvious and so compelling. Totally. And it's finally working. There's an activation and deployment cycle we're going through, but that's happening so quickly now. Very pleasantly surprised. We walk into these really large organizations, really large enterprises, and the cycle of us having an initial conversation to them wanting to do a pilot to them buying the product is extremely quick.

Wow.

Compared to what it was before because I think the value is just so obvious to people.

Yeah. Well, I actually maybe related to that, but I wanted to pull on the thread, and this is pun intended, of The UI that's, the changing UI around how we explore data, right? And the reason the pun is intended is you guys obviously released a product called Threads. And I, you know, I loved your point that the first iteration of a lot of AI as applied to data analysis was really text-to-SQL, right? There were a bajillion of these startups that popped up. But, you know, as you think about time to value shortening, like, you know, even going negative to, you know, to borrow from you, I think Threads is a pretty big product along this journey for the user. So maybe share a little bit more about, first of all, what Threads is for everyone who hasn't used it, but how you think about that evolution of getting the user closer to bringing in data to actually making decisions.

Totally. So Threads is a conversational self-serve product surface area in our platform where you can come in, it's very legibly chat. Something very approachable. Users can ask and answer questions and they're tapping into all of the power of Hacks. Now behind the scenes, it is leveraging the whole platform we built. And going back a little bit, I think in the first leg of the journey for Hacks, we were mostly thought of as a super powerful, very capable data tool for more sophisticated, more technical users. A lot of people think of Hacks as a notebook built for data scientists and data analysts. Over time we've done a lot of other things, but actually those roots are extremely helpful for us because agents, the way our product is architected, just being in the right place at the right time kind of thing, works really well for agents. If you imagine, those of you who haven't seen it, anyone listening who hasn't seen it, the Hex core product, it has this notebook paradigm where it's very iterative. You have a SQL query and the results of that can go into a chart and you can visually filter that chart and the results of that can go into a Python cell, which can go back into SQL and it can chain together. This is a pattern that works really well for AI agents where it can do a step, it can look at the results, it can reason about what to do next. It's why part of one of the reasons we've been able to bring AI into the product in a way that's really compelling And we first did that with the Notebook Agent over the summer where we did that targeting maybe those more technical users that are maybe comfortable with SQL or Python, but that we built it in a way it was very purposeful where it's a framework that now we're able to expose to lots more people. And so Threads is that. Threads takes the same underlying framework using all of the tools and all of the power of the platform and bringing it to a much wider audience in a way that is governed and built for trust. And so as an example, if you have a data scientist using Hex, Hex is going to be able to use any of the data in your data warehouse and it'll be able to write arbitrary Python and do a lot of really complex things. If there's a user using Threads, it's going to be much more constrained where it's only going to use endorsed or model data or it's not going to go and write a bunch of arbitrary Python code that you're not going to understand. And that experience is very approachable, but also very powerful. And we can expose that both through our UI, but also we're bringing that to other places now. So we have a Slack bot, as you mentioned, which is really cool. It's almost become the primary way I'm using Hex day to day is I'll do a lot on my phone, which is ask Hex, ask a question, and I can have a whole conversation with the product that way. Then we have an MCP server and we're going to announce integrations with other tools over time where we want anywhere where you have a data question to be able to tap into all the power of our platform and all the context we have to be able to answer it really well.

Yeah, interesting. I love that you brought up the Notebook Agent from over the summer. What did you learn from building the Notebook Agent that you applied to Threads and why do you think now is the right time for a conversational interface?

We learned a lot building a notebook agent and going even further back, we had actually first tried to build, I think what now you describe as an agentic analysis system, 2 years earlier. So it was the summer of 2023. I wrote a feature spec that was called Chained Analysis and the whole idea was It was sort of agents before agents and it was way too early. The models were not ready for this, but we spent the better part of a year banging our head against the wall trying to get it to work, trying to get it where you could have a user prompt and the system could go and stepwise do an analysis path for you. And again, the models just weren't ready for that. Our ability to wield them wasn't there. There was a lot of infrastructural stuff we had to get right. And 2 years later, it's finally possible. And so the notebook agent was the result of a lot of lessons we learned over that whole time, but also just the new model capabilities, whether it's tool calling, reasoning, the way you end up structuring your context. Now getting into things like subagents for doing data discovery. There's just a lot of these pieces that we had to really iterate on to get the Notebook agent feeling really good. And the experience is legibly, people call it cursor for data where it's like you already have this really powerful environment Hex to do data work and now there's this agent assistant that is aware of the whole project. It's aware of the relationship between all the different analytical steps. It can view the outputs of charts, it can view the outputs of queries, it can reason about the relationships between these things. We are exposing even more information like how long a query is taking to execute and past queries that look like this. And now we can, again, it was very easy in a way for us to build Threads because it's just the same underlying agent with a simpler, more focused and constrained UI. And what's really cool about this is we make one of those surfaces better, the other one gets better as well. We think of it as one core agent layer we're building with these different consumption surfaces on top, not completely discrete products.

Yeah, I love that you brought up the just sort of being ahead of the pack but then waiting for the model capabilities to evolve. Um, and I was going to ask you what evolved to enable this, um, but just maybe on that topic, what I, I guess of the list that you mentioned, what was the biggest thing that you think led to a step change improvement? And in terms of what still needs to improve, um, what would you like to see come out of the models that would, you know, I think fit your Hex's roadmap?

Well, the biggest thing that happened, and it happened late last year and then with successive steps got better and better, were the generation of models that were able to do these agentic reasoning steps. So there was the O series of models from OpenAI and then you had the Claude 3.5, 3.7, 4, 4.5 now series of models that have come from Anthropic that have embedded that thinking capability. There's open source models of course that have have done this. And that revolution over the last year has really, it's almost building products with these tools. It almost feels like this discrete generation of, people think about LLMs, it almost feels slightly discontinuous just in terms of how capable and the types of things you can build with these. There was a generation of products you could build that were very one-shot.

Yeah, totally.

Hey, write me some Python to do this and it would just write you that Python. But now having models that can reason and iterate and loop and you can give them dozens of turns to go and think about what they're doing. It's a whole new thing. And so that's what's unlocked AI coding with products like Cursor. It's what's unlocked a lot of the AI customer success things like Decagon and Sierra. And now that's coming to data. And so applying that to data is actually, there's a lot of specific challenges to that, including one example. We actually have a bunch of blog posts about this from research we've done. We're just sharing this openly. As one example, the context volume in data is very, very large. You think in coding there's a really large code base, but any given step in coding, you have the text of the file you're working on and then the agent could go and grep other text files. In analytics, you have things that you might want to put in context that are hundreds of thousands of tokens because they're maybe the whole result set of a query. Or how you represent charts is actually really interesting. How do you encode that image in a way that the agent is going to understand and you're not going to blow up your context window? So there's just a lot of very specific challenges. And so we spend a lot of time with our partners Anthropic and OpenAI, which are both model we use in our product, trying to help them understand these challenges and influence maybe some of the things that they're doing where we want to be able to see both. It's a little bit contradictory maybe. We want to see higher speed because there is a time sensitivity when you're watching a thing reason that we just want to be able to have lower and lower wall clock time for users to be able to go from the question and curiosity to get the answer.

Yeah.

But also to be able to have larger context windows and more tools and capabilities for us to do context management because of the unique challenges in analytics when it comes to the volume of information you might be trying to expose to a model.

Yeah. On that note, I mean, you might be uniquely positioned to answer this honestly. So Gemini 3.0 just dropped today. They all have their leaderboards, evals that they put out there. But do you have, I guess, do you think that they're truly differentiated on any important vectors when it comes to data analysis?

We see them being quite differentiated. We run all, every new model that comes out, we run our evals. We have very rigorous internal evals. As it turns out, the open source evals are not good. And that's no disrespect to the people building those. Actually, there's a lot of smart folks who have worked on these benchmark sets. We have a unique purview where we work with 1,700 customers.

Yeah, exactly.

And growing, including some of the leading companies in the world. Anthropic uses us, Cursor uses us.

Right, right.

There's these really large and very leading edge companies who use this. And so we get to see the real world examples of how people are trying to apply AI to data. And so our ability to build evals and understand what is actually useful in these contexts is pretty unparalleled. And so we are able to benchmark all of these against pretty rigorous understanding of how people really do data analysis in the real world and there are real differences in how these models work, how they operate, when and how they will take a new turn on something, when they'll come back to a user for extra thing, for extra context, when they'll do tool calling, how they do tool calling, the ability to factor out things like subagents. There are certain models that are way ahead on these and one of the things you mentioned Gemini, one of the really interesting things I thought was They released the nice model card. It's always the same, right? The new model that they release on the far left, the numbers in bold, and all their competitors. One of the interesting things though was that Claude was still out ahead on coding.

Yep, saw that. Sweet bench.

Sweet bench, that's right. So why is that? Well, first, is that interesting for us? Yes. Hex does, in the course of our agent doing these analysis paths, It will write SQL and write Python. So the ability to write code well and reason about it is really important. But I think it's a very interesting question. Why is Anthropic still out ahead on that? And I think it's very interesting to observe the data flywheel they've built. They made a bet on getting out ahead on coding and their Claude very quickly became known as the model that was the most capable at these software development tasks. And that meant people started using Cursor with Claude.

Yep.

And it started, I mean, they were able to go build a great product in Claude Code and now they have a data firewall where they have a lot of people passing a lot of tokens through and a lot of people building coding use cases on top of their platform that they're able to just get better and better and better. And if you look at Google, they've got their internal developer community, but No shade to Google, they're still, I think they would admit, much more nascent in terms of having a lot of external developers relying on Gemini to do their software development work. I think it's a really interesting example of where these data flywheels and token farming flywheels can emerge and it'll be interesting to see, can other people catch up once you've created a flywheel like that?

Dun dun dun. It will be very interesting to see that. I guess maybe bringing it back to capabilities that models have unlocked for Hex. We've talked about Notebook Agent. You've also added semantic modeling agents. I wanted to understand a little bit better, how do you think the semantic layer changes in the world of AI and the role of the semantic layer, et cetera?

Zooming out for a moment, AI has been able to generate SQL for a little while. In fact, it was funny when people first saw ChatGPT, it was on everyone's top 10 list of potential use cases. It was writing blogs, medical advice, these obvious use cases. One of them, writing code. One of them, everyone was like, "Oh, this can write SQL? Oh great, this will do all our analytics for us." And lo, there was 100 startups doing AI for data chat. Unfortunately, a lot of them have already gone through a full life cycle, let's say. Because what they found is it's very hard to do this accurately. Writing syntactically correct SQL was simple enough and pretty quickly the models got pretty good at that. Writing semantically correct SQL, i.e., queries that are going to represent the correct way to understand and think about the world, is much harder. Obviously, as in many domains with AI, the context you give the model is really, really important. Ultimately, actually, I think the thing that makes great AI products is not just the UI, which is important, or using a bleeding-edge model, which is important, but it's how you are doing the context engineering for that. In analytics in particular, there's a few different ways to think about giving context to models. One of them is what you mentioned is called a semantic model. Semantic model is kind of a maybe fancy term. People haven't heard it. We think of it really just as instructions for use for a database. So you have a database, you have tables and columns, you have the names of the tables and columns, but you don't really know what they mean or their relationships to each other. And if you have a really simple database, maybe you're able to reason about it. And we do have customers that have simple enough database structures where our our agent can actually now do a really good job reasoning about how to use it and that works fine. But for most complex organizations with real-world databases, it's messy. They've got a lot going on and a lot of encoded business logic that needs to live somewhere on how to reason about the relationship between all these different entities. So that's where a semantic model comes in. And there's a lot of different people that have tried to do and are trying to do a lot of different things around semantic models. We're actually pretty agnostic where someone wants to manage that information. If you're building your semantic model in DBT, that's great. We can import that and adjust that and we want people to be able to use that context in Hex. But we did build another agent in the product to be able to help create semantic models, which is great, but we see that as just one step in a bigger job to be done and context feedback loop. I actually think that as sexy and cool as The things like the Notebook agent and Threads are where you can type a natural language question and get this data answer back and it's really cool and everyone's like, "That's the holy grail. That's really great." I love showing it off. When I'm demoing to real data people, the thing I wind up gravitating to and showing them is actually the things we're doing around context management and observability and governance because that's the stuff that are going to make those answers trustworthy. The fastest way to really annoy a lot of people is to have a system that's giving them consistently wrong answers. And so we're really interested in and we're spending a lot of time focused on toolkits and workflows and capabilities to allow people to see what are the questions people are asking, are they getting good answers, and how could those answers be improved? And there's a lot of really nice UI things and cool things we're doing, but there's also some really cool applications of agents to this. So We now have this online eval system where every time someone asks a question in Threads, we have another agent that reviews the thread.

Love it.

And says, was this a good answer? And we can look at a lot of different things. So we can look at, did the user appear to be satisfied with the answer? Did they give negative feedback? Did they appear to be annoyed? We can inspect the actual thinking tokens from the model and we have what we call the Confusometer, which is—

Very technical term.

Very technical term. Our AI research team came up with that, so they're very smart. But it's the confusion meter, which is how confused did the agent appear to be as it was conducting this? Because you can literally see in the thinking tokens. If you've ever looked at the thinking traces of one of these models, it'll sometimes be like, "Wait, no, that's not the right way to look at this. Okay, let me look at this. Well, that still doesn't make sense." And even if at the end it gives you some answer, That sort of verbose confusion we found to be very correlated with maybe something that's not going to be a great answer to that question. Anyway, we take all of these different factors and can look at that. We want to provide all of that as information back to someone on a data team for them to be able to say, where are people getting good or bad answers? What topics? So we do topic classification, I see a lot of people are asking questions about revenue attainment, but they're getting generally bad or confusing answers. And then, oh, that's because we don't have the right context there.

Yeah. Interesting.

Or people are getting two different types of answers in this domain. We should probably go and build the context to be able to steer the agent toward one of those answers or the other. That workflow I think is incredibly super important and there's this really great compounding effect that we're seeing our customers develop. I just saw a quote from a customer earlier today who was like, "I'm in the context studio," which is what we call this UI, "every day." Because they've now deployed Threads out to everyone in their organization and their job is now like, "Great, I need to help understand how I can make all the answers they're getting better and better." Which bringing a full circle was really the thing that a lot of data people always thought they were doing or always wanted to do. People use DBT, pre-AI, people use things like DBT to try to structure tables, in a way so that people could go and find them using the BI tool and click around them and get good answers.

Yeah.

Well, now the way that people get those answers is way better. And we think that the way that people are going to be able to engineer that context and help guide and improve and partner with people to get those great answers is going to be way better too. Yeah. And so that all comes together and semantic models are one tool, but we're really interested in, can we be surfacing those things to data teams and saying, Here's a suggestion of something you could add to a semantic model based on what we're seeing and different questions people are asking and the answers they're getting and accelerate that flywheel. We think that's a huge opportunity.

And are data teams the ones who are doing a lot of the AI governing from that perspective now?

Yeah. Interesting. Yes. And I think that is a big part of the future of a role of a data team. We have an amazing data team at Hex. I love them. They're including—

On brand, on brand.

On brand. Well, it is. It is. And one of our head of data actually used to be a customer and she came over because she was like, I want to work somewhere that I'm going to help define the future of my craft. And so our data team, I like to joke, is a little overprovisioned. They would disagree. I think they were like, we need more people. But we have a great team and part of the reason we've invested so much in that team and we love them so much is because they get their dog food and it's a great role because you're a great place to be on the data team because you get early access to all these great new features. It's also sometimes annoying place to be on a data team because you're dogfooding all these very early things. But watching the way that their job has evolved has been very interesting. We rolled out the Notebook Agent and Threads obviously before we rolled out to anyone else internally and Now they're busier than ever, which is great. They're spending a lot of their time doing deep dive analyses that they didn't have time to get to before because they were getting bombarded by one-off questions that now could be answered by Threads, which is great. But they also, a big part of their role is sort of this compounding virtuous cycle of what are all the questions people are asking? How can we make sure that they're getting good answers and canonize that context in a way that can happen at scale. One of the people on our data team, she's like, I want to feel like I'm like a spider on a web. And when there's a question or a new topic that's popping up in the org, I want to be able to get an early detection of that and make sure we're there to make sure we're bringing the right data to that new thing. And so that's, I think, an evolving part of the role. And we're going to see data teams understand their jobs more and more as this context engineering. I think that's really exciting.

Yeah, I, um, I actually love hearing you walk through all of these measures or guardrails, whatever term you want to use, on ensuring you're actually getting the correct answer. If you were to put data analysis on a scale of Waymo being here, right, you make a mistake, someone dies, um, just how important correctness is, to Midjourney maybe over here, like you have a funny colored hat, that's, that's kind of a feature, not a bug, like where would data go on that?

It depends what data you're analyzing. I've seen domains where getting the wrong answer to a data question, someone could die.

Fire the missile.

Yeah.

I used to work at Palantir.

But even outside of spooky NatSec stuff, there are places like— I also worked when I was at Palantir, I worked in oil and gas and there are real life and death decisions around decisions that have really big impacts if you get something wrong when working in these domains. So jokes aside, there are places where data analysis is really mission critical. There are also places you could say, hey, it's a little more trivial or whatever.

Yeah, maybe the average take.

That's a good way to put it. But I think in any domain, one thing we see a lot is people get fixated on an abstract concept of accuracy. I talked to a customer recently who was like, Well, what accuracy score is your guys' thing at? Because we've tried to do this internally and we were able to get it to 71% accurate. And there's another vendor who's telling me they're at 92% accurate. What's your number? And I'm like, it's kind of a, I was like, no offense, but it's kind of a nonsense question. Why do I say that? Well, one is what are you evaluating that against? Again, going back, we have a very unique and very rigorous set of evals that are The other thing with an agentic system is what do you even call accuracy? Maybe that sounds a little obtuse, but just to give you an example, if I'm like, how many widgets did we sell last month? Okay, that's something we can really easily eval.

There's a right answer.

There's a right answer. Okay, why did we sell that many widgets last month? Well, that starts to get harder. And these are stochastic systems. They have a degree of randomness and now they're multi-turn. For sure. So each step has randomness. And so evaluating that is really tough. I don't say that to dodge this question of accuracy. We think we have a very accurate system. We're very proud of it. We spend an enormous amount of time on how we can have our system be better and better at providing great answers, but the word we use is trustworthy. We want you to trust that and that's more than just accuracy. If you even think about your relationship with a human analyst, you have some prior on their accuracy. If you knew Susie the analyst, tended to not be very accurate in their work, you would feel like when you got a thing from Susie, you'd be like, well, okay.

Yeah, but check that.

Yeah, double check this. Right? But it's more than that. Right? Because when you sit down with a really great analyst or data scientist partner, they're able to explain how they got to that. They're able to contextualize it for you.

Right.

There's a lot of other things that go into that and that they're well managed by someone who's overlooking or maybe double-checking their work and making sure their techniques are methodologically sound. So the point is there's a lot that goes into to that. And so we think it's really important that people get good and accurate trustworthy answers, whether they're working in something that's truly life or death or not. But the way to get there comes from both the context, but also building a system where people are able, the end user is able to understand how did it reach that answer. The system is able to properly contextualize that answer for them. But then the data team behind it are able to observe and see and iterate and improve and evolve because, and I guess the point is there's no system in the world that's going to be one-shot, 100% accurate out of the box.

Yeah.

And we think that this is over time a very iterative process and a constantly evolving process of how you're going to have trust in data and We're trying to build a system for that.

Yeah. No, completely. And I think you brought this up earlier, but the fact that context matters too, right? What additional context can you bring and how does that change the trustworthiness, right? It's not a— you can't just rely on the model to get you an answer in your world, right? And that's part of your moat, of course, as well versus the labs doing data analysis and ChatGPT, et cetera.

Which can work great for certain things, but one of the big advantages we also have and I know our customers really appreciate is Hex is where they're— we have 1,700 customers that are using the product and they're using it to do a lot of different things. But in all these places, Hex is where data analysis lives. It's where the results of these analyses live. And if you're asking a data question, maybe the best answer is one that already exists. Maybe it's an app or a dashboard that was already published that can give you the answer. Or maybe you want to chat with that app or dashboard to go deeper on it. Yeah. And that is really valuable context as well. And there's, there's even the sort of meta context. There's the collaboration graph around that. Who published that app or dashboard? When was it last refreshed? Who else has been viewing it? What apps or dashboards have you been viewing? What questions have you been asking?

Yeah.

That we can then build some memory from and better understand the things that you're interested in or the way you want information presented to you. There's a lot there and fundamentally we see our job as not just building great and beautiful UIs, which we're very proud of, and not just building these cool agent features into them, but thinking about this whole thing as a system where we can help the data teams and all the people that are trying to support to help create this trust in data. And I think obviously The whole company is just obsessed with this and we think there's a lot there.

Yeah, totally. I actually, I want to switch gears a little bit, but it ties to this last point that you just made, which is this is a full system. And you said something earlier in this session about being in the right place at the right time. So you were not founded in 2023 or Hex was not founded in 2023, 2024, right? I believe 2019. And so you'd done a lot of building pre the advent of LLMs. But I think one of the things that I admire most about you as a leader and Hex as a company is just how you have navigated and embraced this new wave of technology into the product and made it very native to Hex itself. But in a way that feels like a full loop, a closed loop system. And so I wanted to talk maybe about the building piece of this. Because it is something that I think is in general hard to navigate for a lot of companies that maybe weren't born in 2023 or 2024. And you sort of famously, or, you know, maybe somewhat controversially put out this piece on how you guys got rid of your AI team earlier this year. But can you just say what you meant by that and how you've approached a pretty generational shift in how we think about technology?

Yeah, so we did exist pre-LLMs or at least pre-ChatGPT, but we started playing with LLMs. I remember I had access to the beta.openai.com, I think, whole interface where they had a little playground and you could play with GPT-3. I think it was the DaVinci model. It was really great. I was showing it to people as almost like a party trick. The interface sucked. It was like free chat, but look, you can type this Do completions. And it was like, I just kind of got obsessed with it.

I remember this, by the way, because I was at the Hex office, your old office, and you were showing it like a party trick.

Yeah, right. I clearly showed it to a lot of people. And I was just kind of obsessed with it and really interested in it. And we actually had a hack week in '22. I think it was our first hack week, actually. At that point, we were really only in market selling the product or really a real— we really had PMF for a very short period of time. I remember I made one of our engineers, I totally forced him to do this integration with the OpenAI API to do SQLGen. Everyone was like, "Oh, neat." And then we kind of moved on. All of this to say we were really early. Basically right after ChatGPT came out, I was like, "Okay, we got to actually really make this much more of a priority." And we launched a first generation of our AI features just a couple months later. We called them Magic. It was a cool branding, Hex Magic, our Magic AI features. Magic Generate, Magic Edit, Magic Charts. Really cool. And this stuff was great. We hired a Magic team. We had Magic Eng Lead and Magic PM and Magic Engineers and it had its whole own identity and almost sub-brand within the product. And to be fair, I think that made sense at the time because the technology was new, it was evolving quickly. I also think it was candidly too early to really have fully working in data. And so even It made sense to almost have this be a learning and research thing. But earlier this year, I think it just became really clear that that was completely the wrong way to organize this. It became really clear that the agentic models were really working. It became really clear that this was going to be the future of the way— It had been clear to us that it was the future of the way these workflows should work for a while, but it was really clear that the future was now. And we had speculated in the past about a world where we'd get rid of the magic team, but it always felt kind of far away because it was like, well, that'll be when Models are really ready and we're really ready. And earlier this year I was like, well, we're ready now. And so we dissolved our standalone AI team. And one of the analogies I used was like Sketch had a cloud team. And for those of you who remember Sketch, you'll appreciate this because, but maybe for those of you who have never heard of Sketch, it actually proves my point, which is Sketch was the de facto product design thing. Pre-Figma. If you were building products in the mid-2010s, you knew Sketch. It was this beautiful, exquisite Mac app, really lovely, very full-featured. Everyone loved it, but it wasn't cloud-native, it was local, but they had a cloud team. And it was always like, who's doing cloud? Well, those folks over there, I think they sit up on 3 or something. I was like, but Figma never had a cloud team. Figma was just cloud. It was just, there's the water they swam in. They had an infrastructure team that thought a lot about cloud infrastructure, but everyone else built on that as primitives. And I thought as a young company, we have a decision to make on which side of that line we want to be on. And as much as anything, it was signaling internally that this is really the future of the company. Earlier this year we dissolved the magic team. We still have an AI platform team that works on shared infrastructure around certain things, but from a feature and product perspective, every product team now is fully empowered to go work on these AI features. Every PM, every designer, every engineer is expected to have full awareness and fluency with these things. This has just worked extremely well. The thing we say internally is magic is dead, long live magic. Everything's magic now. And when I published the blog post about this, I think it was a couple months ago now, I was a little apprehensive to publish it because even just in the 6 months since we had made that change, it kind of just felt obvious that this was the thing to do. I was almost embarrassed that we had held onto a standalone AI team that long, but I was shocked at the number of people that came out of the woodwork, other founders texting me. I was at the A16Z event a few weeks ago and people were coming up to me and asking me about it. And so If other people are listening to this, I would really encourage you to think about that analogy, the different analogies to different things in the past and where does it make sense to have a dedicated AI team versus where does it make sense to have every team be an AI team? And that doesn't mean that all they work on are AI features. That was one of the fears when we did this was like, well, we'll just never work on deterministic features again. There's all these things that our users want today. Well, our teams actually do a really good job, but the point is that you manage it out of one one backlog and one queue. You want to work on some non-AI thing because you think that's the next most important thing to build for our product? Great, go do it. But even the way we build those is different now because we have people thinking in terms of context and tools. Because people have been exposed to this, when we build new features, people are actually thinking about, okay, well, how is the AI— how is it going to interact with us? How are we going to expose this to the agent? How is this going to show up in different surfaces? And it's a subtle thing, but I actually think that it's a compounding value to having the whole company oriented around this.

No, I think that's why Hex feels like, I mean, you called it a system or a platform versus an existing product with AI bolted onto it. I think that's the key difference, what you're talking about.

Yeah. Which I think the first version of our magic features and even some things today still feel a little bolted on. The example is the analogy to Cursor, the first time you use Cursor, you're like, okay, well this is just VS Code with AI bolted on, but became more evident over time that what they had built was this sort of agent layer under and around the coding experience. I think we've done something very similar with our own product with data where we now have this agent layer that is becoming more and more intrinsic to the way the whole product works. I'll speak for myself and my team, and I know we hear this from a lot of our customers, it's just hard to imagine Hex without it now. I don't want to use my own product if I can't use the AI features because they've become so good.

Yeah. And so much of the story and roadmap is still unwritten. I've heard you say before that building with LLMs feels almost like research, not just product execution. You're actually pushing the frontier on what can be done, how you do it, how your users will use your product, use AI. How do you plan around that now? And maybe related to that, how do you guys think about what to build around versus optimize versus wait for the model to improve if there is something that you need it for the product, but it's not quite ready from a model capability perspective?

It's a really tricky question. We've gotten this wrong plenty in the past. I think the first and most important thing for anyone building software today, which I say software in general because every software now has AI integrated in it or well, is to really have a lot of intimacy and understanding with the model capabilities and deeply understand it. The labs are moving very fast, pushing out new things. Every new release of Claude, every new release of GPT models, they've RLD'd it, to death with new things and you can kind of see and extrapolate clearly they are trying to, they're really hammering. I feel bad for these poor models just getting beaten to death with RL on certain tasks and you can kind of look at that and almost extrapolate and say, okay, clearly this is a line that the labs are excited about. They think there's alpha, that they're going to be able to descend some gradient here of new capability really well and you can kind of ride that horse a little bit. And so as we've really made this more central, the thing we start to think a lot about is what can we infer both implicitly from what they're doing or explicitly through having great conversations with them as close partners of ours on where these things are going and where we should be investing. And that means things we want to build right now because it's going to be useful today, but hey, when this new capability drops, it's going to be even better. Or things where, hey, It'd be a lot of engineering to build this today, but it'll be sort of more trivial once the model capability evolves. One example is a subagents pattern. It's a thing that was very hard to do before recently. Now the models are getting better at it, easier to build basic versions of it. There's still some things that don't work, but that's clearly a horse that people are riding. It's like, okay, we can go and mount that and we adopt an architecture, we know that it will just get better over time almost for free. It's like, yeah, just be on the tail end.

Yeah, totally. I guess on this topic, I think one of the other maybe initially contrarian things that you guys did and that you've talked about in the past was you actually decided not to charge for your AI features. And people are—

I remember some investors and board members who questioned me quite a bit about that.

People on your Are you an AI company if you don't have AI revenue?

Who would have done that though?

Who would have? But of course, your response I think was very prescient where you're like, are you an AI company if you don't have AI in your core product? And why would you charge extra for your core product? But just say more about that thinking. And I think over time, that was over a year ago, maybe 2 years now.

It goes back to exactly what I was saying about the the way we structure the team and not having a discrete project. It was like, having an AI add-on suggests that there's a version of the product that you want to sell that doesn't have AI in it. And maybe that seems obvious today that that would be a thing, but we just believe that as the capabilities get better, you're just going to want these things. And it's just going to be really obvious that this is the best way to accomplish these use cases. Again, it connects back really directly to what I was saying earlier where it's like having it as an add-on implies that that is some other thing that you offer and sell other than being very intrinsic. And I always said charging for AI in 2024 felt like charging for cloud in 2014. It was like, sure, you could have. There was probably a revenue grab to be had and there was probably a lot of SaaS companies that did, where they're like, okay, we're going to have a cloud add-on and we're going to go charge people extra for this cloud add-on. But to the extent there was revenue to be captured there, it was very short-lived. And my suspicion, it was quite Pyrrhic where like, great, congratulations, you went and got another 10% lift in revenue. But by doing that, you warped— there's a lot of warped incentives around that. You're conditioning your customers that it's a separate thing. You're telling your internal team that it's a separate thing. And so we were like, and this has gone, to be fair, I think I've been vindicated because I think this has gone out of vogue quite a bit. When I wrote this blog and when we talked about it, this was a couple years ago, every SaaS company in the world was launching blank AI. Slack had an AI add-on, Notion had an AI add-on, Loom had an AI add-on. These are really good companies and they saw the need to go and charge extra for this thing. Well, all of that has kind of been wound back. People are realizing, no, this is just the value of the product. Now the interesting thing is in the time since, tokens have gotten way cheaper, but we're using a lot more of them with these agent features. And so a thing that we're very open to, and we actually have customers even asking us for in a very funny way, is moving to consumption where people are using a lot of these agent features. We're very open to that. I think But it's very important to me that the AI capabilities come baked in with the core thing you're buying. If you're using a ton of our agent things and it's costing us a bajillion dollars in inference, sure, we think that's a very fair thing to go and charge you overages for that and we'll probably do that eventually. Most people are moving toward that. But there's no separate AI add-on and I've even put down a mandate and an edict, we just won't sell the product anymore to people who don't want the AI features turned on. That's probably 7 figures of revenue we'll walk away from in the short term. I'm like, I just don't want new customers coming on board that aren't adopting these features and aren't aligned with where we're going. At very least, I'd feel bad for them because they're going to have a bad experience. They're going to get a worse product. A lot of the new things we're building are very AI-centric. They're going to watch the feature releases and changelog come along and be missing out. I almost want to force people, if you want Hex, you have to fully adopt these things. It creates all the right alignment and incentives even if we leave some short-term cash on the table. That's fine.

Yeah, for sure. And I was going to ask, how do you think companies should capture value in the case, let's say AI becomes ambient to borrow your phrase? It sounds like though you answered that where down the road usage-based pricing. I mean, we are seeing a lot of companies who started subscription add that obviously.

Yeah, there's a lot of different things. I'm not the world expert on pricing. I do think A very simple tone because I'm a simple tone, so I need simple things. Framework that I've adopted in the past is I think there's a distinction between apps and infrastructure in pricing generally. Set AI aside for a moment. You can sort most enterprise software into apps or infra. If you look at a database, it's very discernibly infra. If you look at something like Figma, it's very discernibly an app. What are these things? What discriminates them? Well, in an app you have usually a rich UX, you have a concept of my stuff. It's very sort of a personal thing that you're using and interacting with as an individual. And typically those are charged for by seats. If you look at infra, infra is typically headless or a very minimal UI. There's not a strong concept of my stuff. If you buy a database product, it is unlikely to have a strong sense of a user account or artifacts you're generating. And that is typically, they don't care if you're just using a service account. That typically charges on consumption. And my mental model for this is there's certain things that used to be apps or app-type workflows that were very, the unit of value was how many humans are using it that you almost can look at as a little bit more like infra now. So a good example is the customer service products that are, a lot of them are doing outcome-based pricing. My mental model for that is that the customer service software space used to be per seat, per customer support agent. And it was seat-based app software you sold. Well, now you can take that and turn it almost into infra. Now it's almost more headless. It's like, great, I'm going to buy this agent and it's going to go do support for for me. And that moves it from something that's strongly seat-based to something that's more consumption. In our world, I think there's still a lot of things that are strongly seat-based where you have a concept of your stuff. In fact, I think the TAM of the number of seats we can and should sell to our customers is larger than ever. If I can tell you, hey, I can make it so anyone in your organization can ask and answer a data question with very low activation energy, you're going to want to give that to a lot of people. I think what's interesting is you're going to see more variability in the intensity of use where you're going to see not just the power users, you're going to see a long tail of maybe less frequent intense users. Hopefully our features are so good that it makes them more frequent data users. But the question is how you map price to value along that line. And I think there's a world where even still as an app, even still as a company where we may keep seat-based pricing as core, maybe you play with those levers a little bit and you have more of a consumption element for the people that are real power users to make it easier for more elastic for people to give more seats to lots more people. So I think this is a super interesting time on every dimension of software, including pricing. And I could go on about this for a long time, but right now our focus, I think we're like other companies and I mentioned Figma a couple times. I think they're taking basically the same approach. The focus is just build. Let's just go build the world's best AI features in the space. We're going to keep running our core business the way we've been running our core business. And the cost of these things is moving around so much that we want to turn some more cards before we go into a lot of extra optimization on how we're charging or how we're optimizing for margins and stuff like that.

Yeah, makes sense. That is one of my favorite delineations of usage-based pricing and seat-based pricing that I've heard though. So I think the Simpletons approach works very effective. I want to turn over to some topics that are not, gasp, AI.

Oh no.

But I think we would be remiss not to talk about and get your views on. So if we think about the modern data stack and we rewind time 4 years ago, there was a chart actually that some of my partners, Matt, Jennifer, Martine, did at the firm. Flooded the world.

I remember this. I think there was a couple generations of it, different marketing generations.

There were. That's right. That's right. Of course, over the last 4 years or so, that's slimmed down pretty significantly. You remain one of the leaders in that stack.

If you publish it again, there's just a few logos and they're all very big.

Yes, exactly. Yeah, yeah, we did a V4 of that. But I think the big news from a few weeks ago is that 2 of the leaders on the modern data stack, Fivetran and dbt, have since come together. Would love to get your view on that, what you think that means for the modern data stack, and maybe the role that you see Hex playing in it today versus 4 years ago.

Totally. I mean, the modern data stack was a term of our— there's a contested who first coined it. I think Tristan at dbt really popularized it among other people, but the way I thought about it was it was this new sort of architecture for data within organizations where the idea was just bring everything to the warehouse. And the core insight was you have cloud data warehouses now that storage is cheap, and compute is really scalable. And in the old world, you had to be very judicious with how much data you were sending to the warehouse, you were doing ETL where you're trying to only bring the data you really need because space was at a premium. Literally people forget about this, but you had physical servers you were running and you only had so much space. Now then you have things like Snowflake and Redshift and Databricks and Athena and all these new architectures where it's effectively infinite storage and just You're only limited by how much you want to pay for it. And that unlocked this new assumption, which is just bring all your data to the warehouse and make the warehouse really the center, this cloud data warehouse is the center of your analytic workflows. And that new abstraction or focused abstraction really unlocked a lot of new opportunities. So Fivetran and dbt were both really built around that assumption of you're going to want a lot of people moving their data there and a lot of people transforming their data there. And by doing that in the cloud, there were sort of these new ways you could deliver that. There was a lot of excitement around it. There's a lot of companies that got funded and started and grew. And I think what wound up happening is it won. I don't think it was the modern data stack anymore. It's just the data stack. It just won. It's not some future thing. It's very rare I go into an organization and they don't have some architecture like that. The largest enterprises we talk to, really big international banks, will still be like, oh, well, we've still got some stuff on-prem, but they're all trying to migrate it to the cloud or they're all moving in that direction. So I think whenever you have these technical shifts that sort of settle in, you're just going to have a consolidation. There's going to be a few sets of people who really are able to win and accrue a lot of value and then other people who will get acquired or pivot or figure other things out. And so it's pretty natural and I think the 5-chain DBT thing to me is actually, you can understand it in that context and you can be like, hey, this is just what happens when these markets mature. I think the other way to look at it is it's the first glimpse of what I now call the postmodern data stack.

Postmodern data stack. Heard it here first.

Well, no, other people have joked about it, but actually we're doing an event next month where The CEO of Fivetran is actually going to give a talk about the Postmodern Data Stack. So talk to him about this. The Postmodern Data Stack, which I don't know if that name will really stick, but it's saying, hey, the way we were talking about this in the modern data stack era was that you're going to move all your data into a database. If I ask you where your data is, you might say it's in Databricks, it's in Snowflake, it's in BigQuery. I've got my data, I'm going to give it to someone and they're going to have custody of it. There's a new kind of way to think about this though that's like, well, I'm going to have my data and I'm going to store it in a commodity storage like S3 that I have sovereignty over and I'm going to store it in an open file format like Iceberg. And what that allows you to do from an architecture perspective is instead of being like, I'm going to give my data to a database, that company is effectively going to have custody over it. You say, no, I have custody over my data on my cloud account and I make query engines. I think of those data warehouses as query engines that then will compete or that I can use modularly to query that data in different places because I'm storing it in an open file format and I can just tell all those databases to point to that file. And this is where the revolution around Iceberg is really starting. And I think it's just very, still very early. And if you back up, you have the Data platforms, they all want to own and lock everything in themselves. They want to sell you everything around this. I think what's interesting with dbt and Fivetran is their bet is by coming together, they're going to be able to make it so it's easier for companies to adopt this new architecture where if you can use Fivetran to bring your data into S3 in Iceberg format and then point your query engines at that, you're going to be able to use dbt to look at all the different places your data is going, how it's being transformed, be able to do cost optimization, be able to understand, hey, where could I move this to another query engine? And that package is an architecture customers are going to be able to adopt to effectively get leverage on the cloud platforms, the data platforms, which wind up with a very large— I mean, they have really good product margins. Some of these are public companies. I won't name names, but one of them, I think last I looked, had a 76% product margin. For every dollar I give to this data warehouse company, 24 cents goes to storage and compute and networking and 76 cents goes to, I don't know, their sales team, private jets. I don't know what you spend that money on. I think there's a big surplus there and the reason I'm amped about this, to actually bring it back to AI, is because I think that one thing we're going to see with agents and analytics is just a lot of queries. We see this already. We see this with our own warehouse bill. Internally. Our agents will fire off a lot of queries and it's not because they're doing wasteful or inefficient things. It's just we can issue queries and do analyses faster than a human. We can do multiple things in parallel on that human's behalf. Naturally, you're just going to fire off a lot of queries and this is going to raise people's costs in querying their data. And I think it's going to create a cost pressure that will need to be resolved because people, I think at the limit you want to effectively be able to run infinite queries over your data to constantly be looking at it on the user's behalf. And so I am very interested in anything, any pattern that will wind up reducing that cost because it'll make our product better. We want that to be cheap and easy and ubiquitous, very easy for our customers to feel very comfortable firing off a ton of queries because that'll allow us to deliver a really great experience. And I think the Fivetran DBT combination, I don't know what they're going to call it. My proposal was Fishtran because dbt was originally founded as Fishtown Analytics. And I was like, well, technically it's Fishtown and Fivetran coming together. So we'll see if that sticks. But I'm really excited about that idea because I think that's a bet on this new architecture that could really help people ultimately bring their costs of query down quite a bit, which is I think good for everyone except maybe the cloud data warehouse monopolies.

Well, speaking of consolidation, Hex has also made some acquisitions, and so I wanted to just bring up HashBoard quickly. Maybe share a little bit more about the HashBoard acquisition, and was that a bet on owning the whole data insight layer? So if you think about all the way from exploration to analysis and sharing.

Yeah, yeah, you're right. We've been Part of this, we're fortunate to have a business that's doing well and Hashboard, I'd known the CEO Carlos, who's great, who he and I got to know each other in the early days of our companies and they did a really good job building a great BI tool that their customers really loved. And in the course of doing that, had built a great team and learned a lot of things and we started talking, this is just under a year ago, about potentially working together. I think one of the big pieces there on both of our parts was clearly the AI elements of this were going to be so important. We had a team that had a lot of experience and maturity on that and it was something that they recognized as the future. And so it was a cool opportunity to be able to come together and take everything we'd both learned. And yeah, it's a great example of how you bring in people who have spent a lot of time thinking about a problem and really set them loose and give them more resources than they had before. If you set it up right, you can get a ton out of it. So it's worked extremely well. Their team feels very well integrated now and I'm very grateful to them for taking a bet joining us. A lot of the stuff I was talking about earlier with Semantic Modeling, Context Studio, a bunch of things we've done with Fizz, there's all sorts of stuff that that team has really helped accelerate. Yeah. You hear these horror stories about M&A, so I was kind of nervous about it going in, but I'm glad to have bucked the trend.

Yeah, no, no, absolutely. I think the foresight to join forces with them has accelerated all of these really exciting efforts that we've been talking about on this pod. This is sort of a non sequitur, but I wanted to switch gears to to just maybe two topics that are seemingly unrelated, but they have to do with your presence on social media. So the first one is actually a tweet that you wrote. This was a few months ago about, you know, obviously you mentioned that you'd spent time at Palantir and it's sort of all the rage now to talk about hiring FDEs or deployed engineers. And you have this great tweet, maybe I, I'll let you repeat it so I don't butcher it. But I'd love for you to talk more about— you're like, hey, don't copy this model. But please share the—

The tweet I wrote was kind of pithy and a little— it was— let me see. It's only forward deployed if it's from the Palantirais region of France. Otherwise, it's just sparkling salesy.

There you go. Yep. That's the one.

Okay. What did I mean by that? And I actually wrote a whole blog post on my on my blog, barry.ooo, if you want to go check it out, my personal blog about this because I wanted to expand on why I wrote it, the sort of truth within the joke, which is, yeah, there's a lot of people doing forward deployed engineering or thinking they're doing forward deployed engineering. And my goal with this was not to gatekeep that term really, but to just help explain to people to the extent you want to replicate some form of what Palantir did well, you should really understand what it was. And it wasn't just having solution engineers or sales engineers that they just called for deployed because it sounds sexy, which does sound sexy. It's cool. I mean, if you want to call your sales engineering team for deployed, that's cool. No problem. Just go do it. But I don't think you should— there's a kind of cargo culting version of it where it's like, therefore I will then have Palantir's level of success or I'll get the same things right. What Palantir did really well was send people out into the field to go build software. It was this radical deference to the people that were going to go literally get on planes and literally go to where the users were, whether that was anywhere in the world, including famously war zones, but also just factory floors building planes or oil and gas fields. There was just all these places we sent people to go and actually get really close to the problem. The way most software companies work is they have all of their PMs and engineers and designers sit in a well-air-conditioned office in San Francisco or Palo Alto or New York or wherever. Going and visiting the customer is almost like a very special— it's almost like an occasion. It's like how many times does the average software engineer go and actually get in a customer's office? It's quite rare. At Palantir, it was very, very common And it wasn't that we just had solution engineers, which it's common in sales to go visit a customer, but it's very rare if you're the one actually building the product. And as it turns out, if you take the people building the product and you go and you send them to where the problem is, you get them on a first name basis and they really understand the problem. They see what the user's workflow, they see the resolution of their monitor and see that these little things actually really matter to building great software. That is a way that you can build these things. What Palantir did really well, they had a bad rap for a while, we had a bad rap for a while of building custom software and it's true. For a while we were building a lot of one-offs, but as we developed the Foundry platform when I was there in the mid-2010s, what wound up happening was this pattern where we had a core platform and then you had these FDE teams fan out to go to all these different customers, find a new problem that wasn't solved by the core platform, build a solution for it, and then the ones that worked would get pulled back into the core platform. So there was things for real-time time series analysis and streaming. There was an incredible team that went out to an obscure part of the world and sat with these engineers that were trying to solve a problem that required that and built a solution for it that did not exist anywhere else in the company. And then it turned out that that was also going to be useful for another customer. And then it turned out that that was going to be useful for another customer. Then piece by piece, that becomes part of the core platform and those FDE teams are fanning out to find the next generation of problems. It's not just like, hey, we're going to come in and do a 6-week implementation with you, customer, where we're going to slightly customize the product and help you configure it, which I think is what a lot of people are calling FDE. It's like we're actually going to take the real engineers really writing production code and go and put them out in the field. And that's just a very different pattern. And I've seen very few companies adopt that. And to be clear, we're not even adopting it. I'm not elitist about it. We build a SaaS product that we want lots and lots of people to buy. And we have solution engineers who go and help them customize and customer engineers who support them. And we don't call anything at Hex for deployed engineering because we just have a different conception of what that is and what that means. I think it's a great pattern. I think you can be really successful doing it, but you need to really understand all of the benefits and all of the trade-offs. If you're going to have all these teams in the field building things, you're going to have a lot of chaos. You have to be ready as an organization to say, bring it. I thought it was such a cool thing. In retrospect, there were frustrating moments. In retrospect, I'm like, whoa, it's actually amazing that the leadership of the company was not just tolerant, but like reveled in all these teams sometimes doing duplicative stuff. It was like product development by Darwinian jungle combat sometimes where he's like, oh, well, we're building this thing at this customer, but I heard this other team is also doing it. It's almost competitive and it sounds like it'd be super dysfunctional. And in a way it was because you wound up wasting a bunch of time.

Right, right. It's like the ByteDance model.

Yeah. But what it did was actually like, it was this amazing function of like, the search function basically. You had people out probing and trying a lot of new things and sent these super smart people out in the field, discover the problem, go build something great. And the things that worked really wound up working and the things that didn't got thrown away. And in a way it was almost this venture model. Yeah. And I think this is why Palantir has generated a lot of successful founders is because it is selected for and then cultivated people who are really interested in I'm just going to go out, find a problem and run like hell and figure out how to solve it, really understanding something. So that culture I think has served obviously Palantir very well. It's been a very successful company, really successful since I left. So that's an indicator.

You set them up for success.

I don't know. I was always the dumbest person in the room, but it's also created this amazing diaspora that's off doing really cool things, I think because of that culture and training, even if they're not doing the FDE model specifically.

Well, actually, you anticipated my next question, which is, um, you know, obviously Hex isn't— you're not sending your engineers to Moscow to build custom Hex apps.

I don't think Palantir ever sent anyone to Moscow. That would be among the last places I would expect Palantir people to travel to.

Wrong country or wrong city to pick. Juno, Alaska or something like that.

It was actually Anchorage and Deadhorse, the two places in Alaska where I went.

There you go. All right. But I was curious what you took from there that you do have at Hex today. And it sounds like some of this is like, hey, go find a problem, figure out how to run at it.

Yeah, there's a concept, another blog post I have on my blog, is something I stole from or borrowed, adopted, embraced from other really smart people that I learned a lot from at Palantir is this concept of commitment engineering. It's a thing you do with customers where you're almost building with them. I think it's really common for early founders to be like, okay, I'm going to go build my thing, then I'm going to go talk to customers, I'm going to try to sell it to them. And they're going to try to charge them money right away, but then you may have these design partners and the relationship is always really uncertain. And one of the things that's hard is you wind up building for a while in the dark before you actually get the RL reward of revenue. You know, like just AI. It's like, you know, the search. And commitment engineering is this idea that we would do a lot of where we did a lot of pilots, a lot of free pilots, volunteer. And we kind of had to get really good at this thing, which is like, I'm going to go to a customer and I'm going to try to get them to make incremental commitments to me. Even before they're paying for a thing. So as an example, it'd be like, hey.

Fascinating.

I want to talk to you about a problem that you have. Will you take 30 minutes and chat with me about this problem? You're making a commitment to me. If you're willing to do that.

Yeah.

You've expended, maybe it's not money, but you've expended your time. Right. It's valuable. Right. And then I do this call with you and I learn about your problem. I go visit you and I talk about this problem and I say, hey, I want to come back in a couple weeks with a first prototype of something that'll solve that. If I come back with that, will you spend 45 minutes with me? "Um." Now if you say, "Yeah, absolutely. It sounds great." Cool. We're onto something. Made another commitment.

Right.

And if you're like, "Oh, uh, in a couple weeks, ah, busy. You know, I'm so busy. And, uh, yeah, you know, I don't know if we have a lot of time for that, but maybe send me like a little thing about it. Maybe I'll look at it." Ah, not so committed. That's a signal to you that you can say is like, is this really—

Right.

Am I on the right track here? And you can just Create these loops forever. I come demo this thing to you. I say, great. Well, hey, I'm going to— thanks for all the feedback. I'm going to go work on that. I'm going to come back in another couple of weeks with the first version. I'd love for you to actually use it for real. Will you do that? Oh yeah. Will you bring this to your team meeting and demo it to them? Will you introduce me to your boss? Will you advocate for this to your boss? Will you give me a quote? Will you— whatever. There's all these commitments you can have. The last one can be like, will you give me money? But if you've done those loops all the way, It's actually that last thing is quite easy. And this pattern works really well. And this is what I did with a lot of our early customers that we had a pretty good network in the data space and I would just go to them and ask for the commitments. Like, hey, can I come to you with the first version of this? Can I demo this to you? Would you mind showing this to your team? And you just get a lot of signal along the way. And I think some founders are even subconsciously scared of that because they're afraid they're going to hear no. You know, you don't want to hear no, you want happy ears. And it's very easy to hear someone say, yeah, this is neat.

Yeah.

This is really neat. And be like, guys, I just came back from this meeting with the user. They said it was neat. Let's go full speed. I think that's a way startups waste a lot of time. Most startups find themselves in some version of that. And if you force yourself to like work on these commitments with people, I think you, um, you, it's a way to seek truth and really understand, are you on the right path? We had to do that a lot there, and I think every company can learn from that, even if you're not doing forward-deployed engineering or whatever.

I love that commitment engineering. I'm going to go back and read that blog on it. Last question, it's a fun one, but at the same time, of course, it's in the zeitgeist today, which is around launch videos. I love Hex launch videos. Literally, I'll sometimes watch them late at night and I'm like, laughing and my husband walks into my office like, what are you laughing about? I'm like, ah, Hex product launch video, right? Like, you know, your Threads one, you're like joking about Dune in the beginning. And, you know, I'm not trying to suggest that launch videos are a new concept or anything, but Hex, you've always been great at them. You're sort of the central, you're one of the central characters. It has your sense of humor written into it as well. And I'm curious, especially in this day and age where it does feel like, you know, there's sort of this messaging of, for founders, go direct, right? Tell your story. Um, and then, you know, with that, like all of these mediums on new media to express your story and be more in front of the camera. And, um, part of the company brand becomes the— is the founder's brand to some extent. Um, of course that's a choice that one makes, but how did you guys think about that and what's your process for creating a launch video? And if you're to tie it to the more serious question of brand of the company, would love your thoughts on that just because I view you as a leader in that space.

Leader. I know people are doing some really cool videos these days. I don't know for, you know, so you got to keep up. Yeah, well, I think we've always just tried to have fun. I think that's kind of underrated and I think that, uh, SaaS marketing for a long time, it was just goddamn boring. It's like every, every logo is blue. Everyone said the same things, the same buzzwords, the same stuff. Even picking our color palette, we like, we have this like pink color that we use a lot and it's like, it's different, weird, even a little bit. Like, and I think it, I just kind of have this feeling that it was like, okay to have fun and that people actually wanted that. Now as you move up market and you move into enterprise, it's tempting to kind of like, you want to even button things up a little bit. You can't show up completely unhinged. But I also sometimes think about the people at these enterprises, they're humans. They find this shit boring. Who goes to a conference or is doing a vendor evaluation and doesn't find everything they're being put in front of them goddamn boring? Yeah, totally. So I used to have fun. And so videos are a good way to express it. I used to think I wanted to be in film. I did concert and movie production in college and graphic design. Oh, okay. Yeah. So there's a running joke.

This is a skill of yours. Yeah.

There's a running joke at Hex that it's all just a vehicle for me to make swag and videos. The other joke is it's really just a vehicle for me to build the product I always wish I had because it is very selfish product and that was just the thing we wanted to use. But I think actually those things come out. I think the fact that we have passion for what we're building and that we have a creative and weird team and we have some freaking weirdos at Hex and I think that comes out in this amazing way that I hope people feel and hope makes us stand out. And even if someone's not buying our software because of it, Maybe just make them smile or inspire them or make them think differently. And I think that's a beautiful and great thing to do in its own way. So how we come up with them, I don't know. We do have this running thing that's almost like an office drama, like kind of The Office, you know, that I guess I'm a character in. We've got a small recurring characters. We do these kind of skits and yeah, it takes a couple hours to do because we just lock ourselves in these rooms and just do a lot of lines. It's a lot of ad-libbing. It's not really that scripted. Walking out every time we film one of these, I'm always so skeptical or pessimistic. I'm like, "There's no way. We didn't get it." Then we see the first cut, we're all laughing.

Nailed it. Yeah. It's like an SNL writer's room or something.

Well, we're not quite at that level, but maybe. But I think I would encourage people just to have fun. It's okay to have fun and it's okay to be weird. I think people are looking for that. I think software is weird now. Technology is weird now. All these new fabulous computers can just talk to us and do things and think. This is so strange and it's exciting. And I think people have an opportunity to embrace the weird and the fun. And as long as I'm CEO, we're going to keep doing that even if we have to button things up here and there.

No, no, please don't. You guys are damn good at it. Please keep it up. Thank you so much, Barry, for joining us. This was an incredible conversation.

Good fun. Thank you.