Barry McCardel: The Boundless Demand for Insight

Some of the smartest people I know have come from Palantir, and in particular a lot of really talented data infrastructure people and data scientists. Palantir is obviously solving really complicated problems. Walk through your background and the data lineage. What did you learn, and why do you think it landed you where you are?

So I spent almost five years there. I'd started my career in management consulting and I was doing a lot of data stuff in Excel. I was always the person in my projects who was wanting to build the model. And I was running these illicit Access databases with this purloined PC under the desk at one of my clients. And I was loving that. And a friend of mine from college who was at Palantir was like, "You should just come do it for real at a place where this is all we do."

So yeah, there were a ton of smart people at Palantir. I always felt like I was the dumbest person there because it's like some true geniuses there. And I learned a ton. I think there's the specifics in data, but even just the culture there, I think, was very entrepreneurial, very first principles, very intellectually rigorous. I learned a lot. I made a lot of mistakes. I look back with a lot of fondness for it being a place where they would throw a bunch of 25-year-olds in. I'm like, this is a really hard, unsolved problem. I'm just going to be like, you'll figure it out. And sometimes we did. And that was pretty great.

But I think one interesting thing in retrospect that I certainly did not appreciate at the time was we were really at this forefront of change in data. You have these two trends in the middle of the 2010s when I was there, which was big data, quote unquote. At the time there was this data lake trend, and anything bigger than what was in Excel was considered big data. And we were really at the forefront of how you actually make that type of data storage and scale useful.

And then one of my biggest takeaways, and something we've carried forward in some ways into what we're doing now, is this idea of making data really powerful for people who aren't necessarily technical. At Palantir, our power users, our champions, our heroes were soldiers or oil rig workers or people on the floor at an aerospace manufacturer. These are the people that we were trying to empower with data. And these are people who are not writing a lot of Python code. These are not people who even are necessarily spreadsheet literate. That's not a part of their job. They're really smart people. They're trying to solve a task and they're analytically minded. How do you bring the power of all this data and processing that we were able to bring to bear and make it into something that's useful for them to solve their mission and their task? And so that was really cool. I look back with great admiration for that. And I have a lot of peers and friends from Palantir who have gone on to start other really cool things. I think it was a great breeding ground for that.

Correct me if I'm wrong, that was where you and your two co-founders all met, working at Palantir. Is that right?

That's right. So Glen was my intern in 2014, so we've been working together for almost 10 years, and Caitlin, I started working with a few years after that. I'd worked really closely with both of them and came to respect them. And we were reluctant founders. We were not the type of people who were like, "Oh, we want to be founders. We just need to go find an idea." It was this obvious idea that we all got excited about. And I reached out to them and we started talking, and I don't think I would have started the company unless I had been able to work with them on it.

You've talked about enabling the non-technical person who has a job to solve. It also feels like there's an evolution within data science more broadly, where it used to be this ivory tower of R&D teams that were very divorced from the business problems to solve. Do you feel like Palantir was part of the evolution away from that as a company, or was it something you saw independently? How did you think about your place in that change?

I think that was actually a really big part of the ethos at Palantir, this idea of bringing the data to the people actually trying to make the decision and do the thing. Sometimes we would come into a customer, and we had this very forward deployed engineer model where we would go and work really closely with a customer, unusually closely, like badge access to their offices. And whenever we came into a customer, there was like, "Yeah, we want you guys to go work with the data science team. And they sit on the 13th floor in this other building, or they sit in the innovation center." And the innovation center, it's different than our other offices. It's got beanbag chairs and post-it notes. And that's how you know the innovation's happening there. And then we're like, "Yeah, but where are the people making the decisions and actually doing the thing?" "Oh, they're on the other side of the campus. But they don't talk. You want to go over there?" And we're like, "We want to go over there. We want to go talk to the people doing the thing." And I think that was not always popular.

But that ethos of wanting to bring this power to the people making decisions. And today our primary users at Hex are typically data scientists, data analysts. But I think we see this very tangible difference of people who are in those roles who are really connected to the business being the types of people we think usually are able to do the most valuable work in Hex versus folks who are doing pure R&D or being in that ivory tower.

I want to talk more about the product and what you do exactly. But first, when you started thinking about who your ideal target user was, how did you begin to think about targeting those people?

So at Hex, our move is we're excited to go work with those data users. Our core heroes, champions are a little bit different than Palantir. Palantir, we were very solutionized. It was, here is a solution for someone doing a very specialized task. I'd say Hex is more general purpose in that we are focused on being a tool that any data practitioner who's doing this type of data science, exploratory analytics work, anyone who's asking and answering questions of data and wants to be able to make those results more impactful. We want Hex to be really valuable for them.

Now, I think what's interesting is we first come in to companies targeting those really high-end data practitioners, right? Data scientists, data analysts. We change their workflow, we change their lives. But then I think the biggest impact and effect is not just making those people more efficient, but it's making their work more useful for the rest of the organization.

The traditional way a lot of those people are able to share their work is, I'm going to write a SQL query and download the results to a CSV and then paste it into a Jupyter notebook. And then I'm going to work in this Python thing. And then I'm going to export that to a CSV and then put it in a dashboarding tool. And then I'll screenshot a chart and put it in a PDF of a doc that I'm going to send in an email. And that's how I'm going to communicate my work. That's insane. It's crazy. You see the workflows people do and it's like, wait, what are you doing? And I used to do this. I know what they're doing. It sucks. It's really hard and it's brutal because even if you get that chart out, the person looking at it is like, "Oh, good chart. But what if we shift this thing a month?" Going and trying to redo that whole magic trick is very difficult.

And so I think with Hex, the idea is, can we give these data practitioners a tool that they can adopt and they can use that integrates their workflow, so that all feels much more seamless, and then makes it easy to share and collaborate with others, their stakeholders, and even make it just so if they want to change something, they can just go ahead and do that and interact with it in a more direct way. If you think about the data team ivory tower, this ability to connect the data practitioners with the stakeholders and the folks in the business they're trying to inform more directly and help them come together in one place, I think, is a big change in how insights and data work can help influence decisions better. That's something we're really excited about.

It feels like there are two challenges you guys undertook. One is increasing efficiency, and I think you have this great chart somewhere on your website visualizing all the different tools and the back and forth, so streamlining that is a huge value add. The other is collaboration. Figma is an easy analogy, where collaboration was such a huge piece of the unlock, allowing multiple different stakeholders to be comfortable going into one surface area. Why didn't you guys just stop at making data people's lives easier? Why was collaboration such a necessary additional component to solving the problem?

I think it's that question of how do you help data teams have maximum impact? And, Kyle, maybe the simplest answer is that's the pain point I was feeling right before I started Hex. I left Palantir, I went to a healthcare startup, and we had a great data team. And we were doing all this cool work and pretty modern data stack. But then most of the actual interesting stuff was happening in random SQL scratch pads and Jupyter notebooks and scripts and screenshots of charts and PDFs of decks that were sent in emails or whatever.

I actually started this journey as a buyer. I was looking for something like Hex. I was like, surely someone has solved this. And then we tried a couple of products. They weren't quite right. There were people like, "Hey, if you cobble together these five open source things and you get all the versions right, and you have someone maintaining it, and Jupiter and Mercury are in alignment, then maybe that'll solve it." And that didn't work.

And so that pain of that collaboration, both within the team itself, the Figma analogies, like two designers trying to work together. In Hex, you and I might be data practitioners, but then how do you connect to stakeholders and make them part of the data process and make the insights and outcomes of that more useful? That's the part that felt super unsolved.

And you brought up Figma. I'd heard a stat somewhere. It's like 40% of their paid seats are designers or something like that. And part of that is because they bring these other people into the design process in a way they weren't previously invited. The old school design workflow that I used to live a lot was you're in Sketch or you're in Illustrator. And it's the same thing as I was describing with data. I do the thing in Photoshop and then I bring it into Illustrator and then I export it to a PDF and I send it in an email, and then you're looking at it and you're putting stickies in it and comments and then you send it back. And it's version five, final, final. And there's a file on Dropbox and it was insane. Looking back, it's like, wait, we've worked that way. And I think data is still there in a lot of ways. And that's the thing that we felt like, hey, we can solve that. We can bring some insight to that. We can make this better and make this more useful for people.

With collaboration in design, the joke is that you wouldn't have two designers in there both trying to drag a shape in different directions. This is a throwback, but I remember watching NCIS with my dad, and there's this episode.

Yeah, exactly. Two idiots on a keyboard, right? It's such a good scene. The number of times I've sent that clip around.

That's right. It is the quintessential idiot collaboration image. For people who don't know, these two people are getting hacked or whatever, and they're trying to fight the firewall. And there's two people on one keyboard, both going at it. I think there's a woman on the keyboard trying to solve it, and then of course a guy walks up and he's like, "Oh, let me help." And then they're both typing on the same keyboard. It's comical. I always figured the writers had to have such a good time with that.

Right. And then I believe the scene resolves with the older guy coming in and just unplugging it.

Yeah. Problem solved.

Chef's kiss. It's so good.

Within data, it feels kind of similar. You may not have two people getting in to analyze a specific problem. One person gets in to do that work, you've made their lives easier, and then the collaboration function comes in when people are trying to get in, observe things, make comments, reactions, maybe make decisions. So fast forward five, six years from now, and somebody else is quoting the Hex statistic the same way you just quoted Figma. There's a ton of people using Hex who are not data scientists. Who are they? What are they doing? What is that interaction like?

Sometimes we got called Figma for data. I'm waiting for the day when there's a Hex for something else. I'm not saying, you've made it, right? I think the collaboration patterns in data, there are good analogies there. How often are you having two designers both playing chopsticks in there, very often? But I'm in Figma all the time with our team, leaving feedback, we can be in there together. There is a kind of magic to that, like, I can be there with you and we can be talking about a thing together. And Hex has the same real-time multiplayer comments, a lot of that same effect brought to data.

Data analytics workflows then have this additional step often, which is, I want to publish this in a way that's fixed that other people can use. You think of dashboards, reports. I want to publish this version of this thing in a way that actually then is going to be the thing that's going to be used and consumed and live. And so there's almost these two collaboration patterns. There's you and I actually collaborating and working together on an artifact. I call it the editor-editor loop. And then there's the editor-consumer loop, which is a little more one-directional. And that of course happens in things like Figma too. There's stakeholders that have viewer seats in Figma that aren't necessarily editing or creating themselves. But in data, I think that's a big part of the effect. Your company might have its collection of dashboards or something.

I think what's interesting to me is this longer-term opportunity to really democratize a lot of those analytics workflows. And that's something that's been interesting to us for a long time. I was talking about at Palantir, we're able to go work with people who aren't necessarily data practitioners. Everything happening in AI right now, I think, opens up some very obvious, but also very nuanced and difficult opportunities around how to potentially open up these analytics workflows to a broader set of people. Is it important that you know Python, the whole Pandas syntax, anymore? I don't think it is. Is it important that you know intricately how to do certain types of things in SQL? I'm not sure that is the skill. But I also don't think that means that the robots are just going to go take away all the jobs, nor necessarily that, okay, we don't need a data team anymore because everyone in the company can be a data scientist. I don't think that's it, but I do think you're going to see much broader access and democratization of being able to get in and ask and answer questions.

So you were asking me this question of a few years from now, what do I hope the stat is? I would hope that there's something not dissimilar of, remember when only a small number of people could do these things? Or remember when, to ask another question of the data team, you had to open a ticket and they had to send you something? I think there's going to be a paradigm shift there that we're really excited to do.

On the current AI boom, some people think it's a matter of hours before 90% of the jobs are replaced, and then you've got the people who say this is glorified autocomplete. Where you guys sit is really interesting because it goes back to the technical versus non-technical user. There are the technical folks who are experts in SQL, the statisticians, and I've heard you talk about the data analyst as a very naturally curious role, a person whose job it is to understand business context and have a hypothesis. How do you thread that needle between those two and who you're serving today, as you think about who AI is going to impact the most and how to make sure you're well positioned for that?

I think the alarmist version is, well, the AIs can just write SQL and Python now, so why do we need the people who write SQL and Python? And I think that's really reductive, because I think the people who write SQL and Python are also doing a lot of other things, like thinking. And if you think about that workflow for a data user, it's a naturally creative role. You're forming a hypothesis, you're following a line of inquiry. You can even say you're making beautiful art with a nice visualization, right? I think it's a great use of human time and ingenuity.

I also think data workflows are full of a lot of tedium, fixing dependencies and casting column types and hunting down a missing parenthesis in code somewhere. And that's the stuff that data teams really don't want to be spending their time doing. There's a lot of munging and a lot of plumbing. You go talk to data practitioners and they're like, "I'm a glorified data plumber." And that's not how they want to be spending their time. It's not like they got into data to do that, right? They got into data to do the created interesting stuff. And I think AI has the prospect of freeing us up to do that.

There's an interesting story from the 1800s. In 1865, there was an economist, William Jevons, and he had this observation that as the technology for using coal to create power got more and more efficient, as steam engines got more efficient, our net consumption of coal actually went up, not down. Which, looking back, you can see how that was counterintuitive, because it's like, wait, we're getting more efficient at burning coal. Why are we burning more coal? Well, it's because as it gets more efficient to use that coal to generate power, we kept finding new things to do with it. Very unfortunately for our atmosphere and our carbon footprint, humans were very creative. We didn't know, but now we're trying to fix it. But we kept finding new things to do with it, right? It was like, oh, we can power a train, but now this is getting efficient enough, let's just put a generator down the hall and use this to power this loom or whatever. And the billion other things we've come up with to do with wattage since then. That's what's called a rebound effect in economics. As the cost of doing something becomes lower, actually often the net consumption of it will go up because people are finding new utility for it.

And I think that's what we're going to see with a lot of things with AI. And I think it's what we're going to see with AI and data, which is this idea of, as you make some of these data tasks more efficient, yes, humans will spend less hours on each of those tasks, but I think we'll get a lot more out of them. And that's because I think there's this boundless demand for insight. In retrospect with the coal thing, it turns out there was a boundless demand for energy. And I think we'll see this with data, where there's this boundless demand for insight, where there's not some finite number of questions that companies have that they want to get answered. It's not like the number of data analysts or data scientists an organization have, that's the exact supply-demand matching of the number of humans we need to answer the number of questions we have. More often, it's just like, I don't know, that's the number of folks that the CFO would let us hire, right?

And so if you take these things and you make them more efficient and easier and more accessible, I think we're going to get more, not less. You're going to have these data teams have a ton more leverage and a ton more impact and a ton more centrality in how organizations understand their world and make decisions. That's really exciting. And I think the idea of "it's going to take our jobs" is very reductive. And also, we can look at these examples from the past and see reasons that it could actually be the opposite.

Taking that analogy further, if those steam engines had gotten less efficient, you'd think either we need to stop doing this because it's really expensive and complicated, or we need to fix the engine so we can keep doing more of what we want to do. AI is still very early, but in the modern data stack people are more looking for how to improve the efficiency than being blown away by what it is. That phrase, the modern data stack, is like the top 10 baby names, but for blog post titles. Believing that the data stack can have 40 different independent categories that all have massive companies and multiple winners was probably a pretty ZIRP-y phenomenon. There's a lot of waste in that pipeline if we're constantly switching tools. And you have Datadog, where in their earnings they show over the years how they've eaten more and more of their own space. It feels like that's going to happen with the data stack. How do you guys think about that? What do you want to own today, and how does that change over time?

You mentioned Datadog, but there's a lot of other categories. I think we're starting to see that consolidation, the gravitational pull start to outweigh the energy pushing out as the interest rate force becomes back to earth. I think in data, as in a lot of places, there's not 40 categories, there might be six. And it's okay to have a smaller initial category or an initial niche, but you have to be able to determine where a lot of those are tributaries into a bigger river.

For us, we had an opportunity to go and build something that really spoke to the workflows that we and a lot of other people were struggling with, that were unsolved, around, call it the data science or exploratory analytics workflows. There was nothing that we thought was doing a great job on modernizing that, nothing that we thought had a complete enough picture on that. And for us, that's a great starting point. We've built something that we're very proud of. It feels very differentiated from other tools. We get great feedback from hundreds and hundreds of customers we have now who use it.

I do think there's going to be more consolidation. You might see some degree of vertical consolidation, but within some spaces we'll also see an amount of horizontal consolidation. And for us, we already do that, where there's these standalone SQL editor tools, and there's a Python notebook tool, and then there's a Python notebook into a report kind of tool. And you can use Hex and go pretty end to end on that. You can use it just to write SQL if you want. You can use it just to build these more report-type things. You can use it just as a Jupyter notebook replacement. But what we find is being able to bring those workflows together allows someone to really go end to end. We're able to actually replace multiple tools usually when we come into a new customer. And that can take us to a lot of new places over time.

I think the thing that's interesting to me right now is, you're right that there's this gravitational force exerting of higher interest rates. There was a Cambrian explosion over the last few years in the data stack, as in other spaces. I think AI is going to also then be this new wave of dynamism. I know it's very hypey right now, but there's also a lot of things when you look in data, even just outside of Hex's purview, where it's like, I can't imagine we're going to be doing it the old way in five years. Writing data pipelines and ETL, how is it not going to be the case that you're going to be able to just point at source data? I want it to look like this, and I want it to be refreshed every 30 minutes. And I want it to spend no more than this many hundreds of dollars a month in warehouse credits to do it. Go. How is it not going to work? That's very obvious to me that that stuff will work. And there's just going to be a change to how those workflows do. And some of that will likely benefit incumbents. Some of that will challenge them. There might be new categories that pop up around new ideas for how that works, but I think we'll come back together. And so we'll see. But I think the consolidation wave is going to come and it's going to happen. You're seeing it at every layer of the stack. For us, it's helping customers get more out of our product and provide more value across workflows in our product.

Walk me through how that translates into the customers you have. Maybe a customer that personifies it, the perfect customer for you. What were they doing, and how did you fit in? And in general, when you get into an ideal customer, what do you expect expansion to look like over time?

We've got some great customers who love Hex. As the founder, I look at our product and I only see all the problems. But it's fun to talk to customers and they remind you we've done a few things pretty decently. My team reminds me all the time we should celebrate that more. They are right. If any of them are listening, I hear you.

I know you just had a kid. I think it was your first kid, right? I've got three kids, and sometimes you feel a little bit the same with your kids, where all you see is all the things they've shattered and the screaming and the messes. And when people compliment your kid, you're like, "But you don't know them. They're crazy." But you do love them. So I get how you feel.

Yeah, that's my relationship with our products. I think especially because it's the product I always wish I had, so I'm constantly just wanting more from it. But you're asking a question about ideal customers and how we come in. There's a customer we landed recently. I am forgetting if we have logo rights, so I'm going to just bleep them out for a moment. They're an autonomy and mobility company. They have a legacy dashboard tool, a very popular solution for dashboarding. And they brought us in alongside it to start because they were doing actually most of their interesting data work outside of dashboarding. It's also funny, BI is really just reporting and dashboarding. And that is all at once very important and also not the most interesting thing that data people are doing. Hex caters to that. So they brought us in to do that exploratory data science, collaborative analytics work that their data team was really spending a lot of time on.

And we landed with maybe less than 20 seats initially. And now there's dozens and dozens. We may be over 100 soon in that account, because it just spreads because people share it and then someone else picks it up and starts using it. What you'll see often is the first adoptees will be the data scientists, for whom it's an immediate replacement for this legacy local notebook workflow that they were doing, a Jupyter or Python notebook. But then you start seeing software engineers and PMs and marketers who start using it because they know some SQL, and Hex is great for, you can write a whole notebook just in SQL and visual cells. It's really fun. And so there's this spread we see, and our expansion rates are pretty good, I think because of that.

And then over time we start to see customers questioning, "Hey, do we need these other tools?" And we don't go in being like, "Hey, get rid of Tableau, replace it with Hex." I think that's a really bad idea. Tableau is really good at being Tableau. They've been doing it for 20 years, and you can't out-Tableau Tableau. There's companies who have tried to do that and it hasn't worked well. We are like, "Hey, there's a different way we think some of these workflows should work." There's actually a different population, different audience that we want to really excel for. And I don't mind if a customer has a legacy dashboarding tool sitting around that is doing some things well. That's fine. But we are really excited when we feel like we unlock a lot of new capabilities and a lot of new frontiers of creativity for users who are doing the really important work that we want to support. So that's our focus and how we're thinking about it.

Pricing turns into a complex thing when you're trying to bring a lot of people in.

It's tough, it turns out.

The other day I was chatting with a company built around the number of integrations they enable, and you don't want to disincentivize people from adding more integrations because the more you have, the more powerful the product gets. For you guys, with a seat-based model, a collaborator who wouldn't usually have a seat might hesitate because it costs more. How do you balance driving more usage while also making sure you're capturing the value you're creating?

We're an application layer business, so we're a seat-based business. That's what makes sense for 90-some percent of apps, I think. We're more like a Figma than a database, where they all charge by consumption. And in an app-based business, you get this highs and lows sawtooth effect where you'll see a lot of seats get added and then they get purged. Every seat-based business will see this, where people get seats and then someone will go in and be like, "Oh, these people need these seats?" And it incentivizes a lot of app companies, I think, to go for these dark patterns of, make it really easy to become an editor and then make it really hard to disable an editor. You can play those games.

I always feel best when we are trying to just be right by our customers. I want to earn every seat. I want it to be hard to decommission an editor, not because we hide the button, but because people are getting value out of the thing and people will scream if they get a seat taken away. And I want to be able to stand behind every bill we send out. You don't want to feel like you're ripping people off. And again, every SaaS business has their own version of these dark patterns. I think for us, we want to earn that.

And so when we see a customer who will go in and purge a bunch of seats, or very unpleasantly in the last year you've seen situations where there's been layoffs and stuff like that, we always just try to bias for being really generous. If we get a customer reaching out, like, "Hey, my bill is unexpectedly high. These editors got added. I don't want them," we just try to bias toward being really generous there. "Oh, no problem. Cool. We'll rebate you that," because we don't feel like we earned that. Now, as the product evolves and becomes more charismatic for more types of people and more types of workflows, we want to go earn the right to have those people become devoted users.

That's a very good way to earn trust. I remember one time I was at a store with my brother, and I asked a clerk if they had this thing. He said, "We do have this, but it's probably not exactly what you're looking for based on what you're describing. This store across town does have that." And walking away, I said to my brother, "That's dumb. That guy should be trying to trick me into buying this." And my brother was like, "Well, aren't you going to be way more likely to come back here?"

That's how you want to feel. We have a sales team, and even what I was saying earlier about, some customer will come and ask you, "Oh, is it good for this?" I don't think it's good for anyone to try to wedge yourself in for a thing that you're not going to be great for. And I have literally pointed people to other products in the past, being like, "Hey, for what you're asking for, I think you're going to want this. It's interesting to us. Someday I want to come back to you and ask you about this thing, but you should go use that thing right now." You do this long enough, you see enough cases where karma comes around. That's the right thing to do.

Maybe a final question for you. At the foundation level, there are so many people who could benefit from what you do today. Some companies do incredibly well as distribution monsters: they take something they're really good at and try to get it in the hands of as many people as possible. I think about something like Zapier, where the product today isn't super different from five, six years ago, but it's constantly getting into the hands of more people. Then you think about something like Databricks, which is so expansive and is trying to do a ton of different things. Fast forward three, five years from now. Is it taking what you're doing well today and getting it into as many hands as possible, or is there a much more expansive vision?

A little of both. I think you have to do one before the other. Databricks, for a long time, was hosted Spark. That was the story, right? You're using Spark, trying to scale it yourself. "Hey, we'll help you." And now, when you go to them, the story is much more than hosted Spark. In fact, you probably have to hunt around to find, that is the primary offering, but that's how they got into a lot of places and how they earned the right to do more.

So I think today my focus is on, hey, we've got a set of things we're excited to go bring out into the world and improve. We want to get that in as many places as possible. And then, yeah, over time, there's a lot of other types of things that people do with data. There's a lot of other types of workflows people want to achieve. There's a lot of other types of users that have a desire to participate in these things. We have a lot of things we think about, but I've learned the hard way over the years doing Hex, and before that, that focus is just such an important thing. The times I'm least proud of are the times where we lost focus on trying to do a few things really well. So yeah, I think in the short term, we feel like there's a lot of room for us to really do a great job in what's in front of us. And then there's a lot of other things we can do over time, but we want to earn the right to do this.