EP 102: Armon Dadgar (Co-Founder, HashiCorp) Reflects 48-Hours After Selling to IBM

26:04And so we'd go work with these people and say, hey, here's this tool we built, Terraform, what do you think about it? Right? And, you know, for some of our tools like Terraform, people were like, this could change the world, right? Like, this is super interesting. Yeah, it has these feature gaps. Yeah, it has sharp edges and bugs and whatever. But you could see the excitement and people were willing to like try and be a part of that journey to make these things work because they could see the opportunity with other tools like surf for example that we built that we had to sort of kill because it didn't find fit you know people were like what does this do exactly and you're like okay if the smartest people we know are like what does this do and what's the problem it solves it's a bad sign yeah so i think part of it was it's your internal conviction that you know hey do we think this is right part of it then is external conviction from a number of people that you trust their opinions basically right and then the third layer of it becomes obviously sort of the i'll call the telemetry data of downloads traffic whatever but that's going to be what we find is consistently a trailing indicator like it's not going to be a leading indicator of anything so you know it was some magical mix of those things and then frankly it takes just a little bit of unreasonable conviction right like terraform is a great example we had multiple conversations with our board where they're like it just looks like this thing isn't going to go anywhere why don't we kill this product and move our engineering resources elsewhere right which is crazy you look at it now and you say it's like our most broadly well-known product uh but we had many board discussions where they're like why do you even bother and so so did you mentally like in going through i mean once once you got some level of validation from the cool kids uh that surf wasn't the right fit but terraform was super interesting and had featured apps, did you pick some point in the future to check in?

27:53And I'm sure incrementally along the way, you're checking the downloads and all that stuff. But just psychologically, so that you're keeping your own sanity, how did you go about picking a point that was far enough in the future that you felt like you could get there, but also within a reasonable enough time frame that you're not wasting your time? Yeah. I mean, it honestly wasn't that long. I'd say with both of the products we ended up shuttering, it was about six months. So we gave ourselves six months. We sort of launched it. We said, we'll iterate on a few versions of it. We'll talk to users, customers.

28:24We'll get their feedback. But like time is not your friend as a startup. So we were like, okay, you got to make a decision and move on because you don't have unlimited resources. So Surf was pretty quick. I mean, I remember it was about six months after we launched it, me and Mitchell sat down and we're like, we think we got the abstractions wrong. And again, this goes back to are you obsessed with the problem or the solution? And so I think as we went and started talking to all these customers, what we validated was, yeah, the problem is real. Everyone kept articulating, hey, how do we think about network automation?

28:52How should we handle large-scale fleets where you have failures in the cloud? So everyone kept re-articulating the problem, but then when we would explain our solution, they're like, eh, it doesn't make sense. So we were like, okay, what are we obsessed with, problem or solution? And so we said, it's the problem. So we said, great, park surf. We went back to the drawing board, and what we ended up building was the successor to surf as console, which console is now a very successful product for us. But again, it was because it was an obsession with the problem, right? We said, you know what? We were excited.

29:18We loved the solution. In fact, surf is still one of my favorite pieces of technology, but it was the wrong solution for that problem. So as these things are being launched into the wild and getting put on GitHub and all of that, how much of your time or how much of the success that ultimately came was rounding out the edges of the product and sort of spent, you know, making it more feature rich for the, for the people when they came to realize this was the future versus grassroots evangelism, DevRel, all of that. Cause I assume you pick, you felt like this was the path of progress one way or the other.

29:57And so in, in, in getting there, which one do you attribute more of the success to oh man um those are almost intractably linked um because i assume that the dev rail is feeding into the product development and all that exactly i mean it was like that feedback loop was so so critical because you would go to whatever a meetup group a conference whatever it was and you would talk about the product and then someone would ask a question it was like hey does the product solve x or can i do y with it and immediately you're like well that's a great question or feedback we should feed that back into roadmap and you're like it doesn't today but give me a month and the next version will.

30:34Right? And so that feedback loop became super critical to know what to actually build was tied deeply into the developer evangelism of it. So it's almost hard for me to untangle the two because it's like you can't build a product roadmap in a vacuum. I mean, you can. It's just going to be a bad one. So I think it's like, and because we were so driven by developer grassroot adoption, it was like that was what drove our roadmap for many years. Was the North Star or the the ICP as you were thinking about it, were you solving at that point in time for the, for the cool kids and thinking that what they do today, everyone else will do tomorrow?

31:12Or were you also trying to get in front of the, not the disparaged JP Morgan and bank of America and I don't know, LVMH and other big enterprises as well and trying to cross validate the two. So actually I think the two are pretty linked because I, you know, if you, if I look at any of these big organizations, I don't think about them monolithically. Like within them, there's the cool kids within any of those banks, right? That they're defining how the bank is going to do this at scale. You know, but they might be the first hundred people where the bank has 10 ,000 developers. So to me, it was super important to get to those people.

31:44In fact, some of our most valuable design partners were those, you know, the cool kids inside of these big enterprises, the Ebays, the PayPals, the JP Morgans. Because it's like, if it's going to work for them, that's going to set the tone of how the rest of the bank is going to operate, right? so actually the the interesting thing is almost never for us not i won't say almost never rarely was the cool kids like the small startups in silicon valley because their scale challenges weren't anything close to the enterprises you know you think about most of the startups it's like great you have 50 servers that's true yeah you go to talk to a bank that has 80 data centers and a quarter million right like it's just a very different scale of infrastructure so for us it was how do you get to the cool kids in those enterprise customers because they're the ones that actually have the scale problems, right?

32:29I heard you say that you actually knew your first 1 ,000 customers by name, and I'm not sure if that's a hyperbole to describe like being super close to the customers or if you actually did know the first 1 ,000 by name and how staying close to them, I guess one, is that a factually true statement or sort of a allegory for how you went about thinking about staying close to it? Honestly, no, so I'd say, well, my face memory is better than my name memory, but I would probably recognize our first thousand users by face, if not many of them by name, because some of them have come to events like HashiConf eight, nine times.

33:05So no, it's very much factual. I think people often ask me, what are the tricks to building community? Like, what's the shortcut? And I'm like, it's pounding the pavement, it's miles in the air, it's conversations had with people and hands shaken, right? Like, there's no shortcut. So when I look at the early years, it was me and Mitchell spent a quarter million miles on a plane going to meet with customers, going to conferences, speaking at meetup groups, just pounding the pavement, right? Because when you think about getting to those cool kids, building trust and getting them to say, hey, I'm going to bet my company's infrastructure on a product you released three months ago that barely works.

33:44That's a very high level of trust. And that person needs to have very high conviction that they're not making a career ruining mistake, right? Because this isn't like, oops, it failed. You know, it's like, it's your core infrastructure. Sure. Right. So it required very high levels of trust and conviction. And I think oftentimes, you know, a deep personal relationship with some of these folks. And I look back to actually some of the organizations like Twitch, where, you know, I'll never forget, we had this one meeting where, you know, Twitch was one of our first large scale deployments of console.

34:14And at the time, the largest test we had done was to run console, maybe like 200, 300 machines, which to us was big infrastructure at the time. And we had this meeting with Twitch. They're like, hey, we really like this tool. we've tested it we think it will solve a big problem for us will it work for us if we run it on 3 000 machines you know at the time this was like 10 times bigger than anything we've ever run on and my answer you know trying to be as honest as i could you know i don't you know i don't want to promise things we can't deliver i said i don't know and you know that was fine they were like okay we get that you know you know and they're like can we work through this with you do you have commitment to help us be successful i said i don't know but you know we'll make you be successful.

34:52And so we worked through all the technical details, etc. Now I won't forget after that meeting, the team lead of that pulled me aside and said, you know, that was a great meeting. We're super excited about the technology, but if I give you one piece of advice, you shouldn't have said, I don't know. What you should have said is we're committed to make it work for you. Because he's like, this is such a critical layer for us that this is make or break for us as an organization. And so I don't know is not a confidence inspiring answer. Right? And we get it. You were trying to be technically honest and not, you know, blow smoke.

35:21But, you know, I think what we needed to hear from you is a conviction to our success. And so that was a profoundly impactful meeting for me. And it changed the way I interact with a lot of our customers, which is, it makes you realize the bedrock of a lot of this stuff is trust. Someone saying, can I trust you that I'm going to make a bet with my career that this is the right technology? And you need to look them in the eye and say, yes, you know. And, you know, it's been a great relationship with them. They were, you know, huge user advocate, customer, you know, still are, right? So, but it was just, it was a meeting like that that was really very impactful in how I think about, you know, how you engage with customers.

35:53Yeah, it goes back to what, what are customers actually buying? And it's some combination of the software, the service, the trust, the confidence, all that stuff is intertwined in so many different ways. Exactly. Yeah, enterprise is so much of it is really about trust, right? And that's why I think there's honestly no substitute for some of these meetings being in person, right? And why, you know, it's valuable. It's been so many, you know, miles, frankly in a plane is it's like you got to shake their hand look them in the eye and say you know your success is my success how did you staff against six different products at launch like what was the actual uh org structure around it did you have like gms of different products or did each group have different product engineering teams responsible for it how did that actually work i mean it evolved a lot i mean in the early days it was crazy i mean we had 15 people with six products so you didn't need a gm when you had three people on each product yes yeah um you know so i think you know from the early days we were just we were thin but we were a lean and mean team and we worked really hard to like how many libraries can we share how much code can we reuse across projects because we didn't have the resourcing given how many products we had obviously as we got bigger we could put a lot more staff on each of these products so it got a little bit easier and then we went through an evolution right for a long time we were functionally reorganized right so we had you know product engineering design as sort of functional groups then right around our ipo we reorganized into more of a gm model so then we actually had product gms for their infrastructure lines security line applications networking etc and then very very recently actually as of february of this year we actually reorganized back uh into a functional model right and so i think it's each one of those things i don't think there's ever a right org structure it's about what are you trying to solve at any given time right so for a long time we were lean and mean, so functional was the right model.

37:46Then at some point, we got a lot bigger, and it was about how quickly could we make decisions and allow the products to run with independent roadmaps. So it made sense to flip into sort of a GM-ish model. And then now, as we think about sort of as we're delivering more of our products and services as a cloud service and through an integrated platform, it's about how do you drive a set of integrations and consistent workflows across the products so it makes sense to flip back into a functional model so you can think more horizontally rather than kind of vertically. So I think at each point in time, we were sort of solving for a different problem and the org structure was designed to help solve for that.

38:17When you move to a GM model, how do you think about the shared commonalities and services that you want to have across an organization versus the autonomy that you want to give that group to make decisions? How did you guys kind of balance that? That's a super tricky one. I think one of the keys for us is we actually had a few horizontal groups. So we had the four product verticals and then two of our key horizontals. One was a platform team. So they owned all of our shared non-functionals around, you know, our cloud service, billing management, you know, user identity, things like that. So a bunch of core services were owned by a platform organization.

38:54And then we had a shared security team who was responsible for things like application security and compliance and all of those kinds of things that are sort of shared concerns. How did you end up with six, then nine, and not three or 16 or 26 Six on the product set standpoint. What was the landing point there? I realize some were deprecated along the way, but how did you sort of land on that? So we started out basically when we started in 2012, 2013, we basically sketched out what we thought was an original portfolio of six products. And the way we got there was basically we said, okay, if we segment the entire sort of SDLC, the lifecycle of building and managing a cloud application.

39:35Software development lifecycle. Software development lifecycle. We sort of saw that there's these six big buckets for us at least. They were like, okay, you need Vagrant on dev tests, you have Packer on image management, you have Terraform on provisioning, you know, Vault on security, console on networking, Nomad on app deployment. So we started there with those six and said, these are the big pillars. Actually, ironically, we didn't start with Vault there. I'll come back to that one. We had Auto there and we had Surf. So we had these other pieces and we said, okay, let's go build the initial portfolio of six.

40:04So along the way, for example, like I mentioned, we built Surf, we realized it was wrong. And so then the successor to Surf became console. So you went from the vision of six to now you have seven, right? And then we had this other product auto, which our view was like, hey, as we started building seven, we're like, this is really complicated. Customers are going to struggle to integrate seven different products. What if we had an integration product that glued them all together? So that became an eighth that was then auto, right? So we had these eight. So we sort of built those out and then realized, well, auto and Surf actually, you know, didn't have the product market fit.

40:35So then they went away. So it really came back down to the six. That was the core portfolio, if I want to call it that, from sort of 2015 until about 2020. So for five years, we were just focused on no more net new product, add depth and breadth of capability to existing portfolio. Along the way, though, as we were talking to customers, we kept uncovering new problems, right? So we said, hey, we built Vault for secret management, but what about human users? How do they get access to systems? That created the opportunity for us to add a new product boundary that we released in 2020. And then we sort of revisited the auto problem again it was are we obsessed with the problem or solution auto the solution was wrong but the problem of how do we simplify you know the consumption of cloud infrastructure was still real so that's why we ended up building waypoint in 2020 as well to say okay this is kind of v2 of auto how do we simplify it for developers who don't care about the details of cloud they just want to build an app so we said let's try again with waypoint so we ended up with adding those and then we ended up acquiring a company blue bracket looking at hey great we have this vaulting solution, but how do people find all the secrets in their environment?

41:36So it was a logical adjacency. So it's some combination, I would say, of part of it was vision-driven of what do we think are the key building blocks. Part of it was just customer-driven of their coming to us and saying, hey, we love vault, but can you help us find the secrets we have in an environment? And so, you know, some of that became more natural to do through M &A versus build. The transition point of going from hunting, if you will, to farming, like the hunting being building, shipping, all these new different products, farming being, rounding them out, getting them to full feature, figuring out monetization and all that.

42:12Why and when did you make that transition point? Yeah, I mean, I think really we made the flip in sort of late 2015. So I think that was a milestone for us where we said, you know, when we raised money from our investors, what we told them was basically, we're going to spend the first few years of the company flushing out the portfolio, focusing on community adoption, and kind of getting to, I'll call it the MVP of the vision, right? You need these six pieces to sort of be able to draw the line end-to-end on app delivery. So he said, we want to be able to draw the line end-to-end, and then we're going to focus on fleshing out commercialization, et cetera.

42:44So we basically promised our investors that's what we'd do. And so first few years, that's pretty much all we did. Every few months, we were launching a new product. We got to our first ever HashiComp, which is our big user conference. that's when we launched the last two products in the portfolio and so that way we had sort of completed the arc and i'll never forget literally the week after the conference was when the board emailed us to say hey that was a great event uh love the new products love the energy of the conference can you tell us what hashi corp the business is now because we know what hashi corp the like open source projects are yeah but what's hashi corp the company and that's the moment in time where it really kicked off a soul search for us to say okay great what is hashi corp the business look like as opposed to HashiCorp, the set of, you know, open source projects that represent the vision.

43:28I heard that along the way, fundraising maybe got far easier when Docker came into existence and people were just like, okay, well, you're a derivative or a competitor of Docker along the way. And so I guess I'm curious, as you look back on the product journey and the desire to go into monetization, at what point in time was it that Docker took off? And how was that trend beneficial? Like, did it give you more time just to focus on the open source and do this stuff? Or did you need to react to the commercialization because of Docker and what was going on? Yeah, totally. You know, it's funny how these things work out.

44:13Yeah, when we did our series A, that was probably the most difficult fundraise we ever did. Because people were - That was Mayfield? That was Mayfield who led it, yeah. But we talked to pretty much every, you know, Silicon Valley name brand. And the challenge was people were like, they're like, infrastructure for enterprise, like, this is a cold dead space. Nobody cares about this. Like, why would you bother? Plus, you guys are multi product. Like, are you crazy? Like, plus, we were remote at the time. So we're like, you're a totally remote company. You want to do open source, you want to do multi product, and you want to invest in a dead space.

44:48It was like every red flag. You were how old at the time? 22. 22, yeah. And they're like, and you guys, yeah, exactly, graduated three minutes ago. So, you know, I think most investors looked at us like, you know, we had a third eye or something. So I think it was a super difficult fundraise because nobody cared about this space. You know, ultimately, we got there with Mayfield, and I'm super thankful because they were, you know, deeply technical. They understood the whole vision. And, you know, we had a great partner, Robin Vassan, who led the deal, who was very connected to the developer community.

45:20And I think he had a thesis that's like the adoption of these tools is going to be led by, you know, practitioners. So that's why open source is super important. It's like remote is going to give you access to talent in a way that you won't have if you were Bay Area only, which most startups were at that time. And it was super competitive in that market. And he's like the portfolio approach will actually be a strength over time because you're going to build a trust and be able to layer multiple technologies. So, you know, I think he really saw why we had conviction about those things. And he was close enough to the developers to sort of help make that bet.

45:51And so I think it was Mayfield and GGV who led the A and really sort of were bought into that vision. Now, I think as you got to the B, it's exactly what you said. It was like it became way easier because Docker exploded on the scene. So all of a sudden, Docker had this organic, explosive, you know, growth by the developers, you know, in terms of driving adoption. and you know that drove you know a crazy you know skyrocketing valuation for them and an ultra competitive fundraise round and so all of a sudden you had folks that felt like hey we didn't get into docker what else is the other docker yeah right and so it's like this boring enterprise infrastructure company that was hosher corp that we didn't want to talk to last week all of a sudden they're like wait you're doing enterprise infrastructure that's so cool yeah and so overnight it changed what the perception became uh and so it became much easier all of a sudden uh to actually go and fundraise because people cared about the infrastructure space all of a sudden um but it's just interesting uh yeah how much of an impact that made yeah well and that was when we participated right that was in redpoint yeah i came came on board so we're appreciative uh of that yeah it's every successful company i think maybe with one or two exceptions has a very difficult fundraise.

47:06And it's a very humbling experience, I think. And I think every company, I don't wish it on anyone, but it does ground, I think, entrepreneurs when the things are going well. It gives more pragmatism of like, hey, well, I remember what this is like the other way. And so let's be a little bit more rooted in the partner we pick, the valuation we set, the ambitions we want to go about. I don't know if that was your experience as well, even when you were the coolest of cool kids and everyone was trying to give you money. Did that first experience impact the derivative ones? Oh, absolutely. I mean, I think there's a bunch of interesting lessons.

47:50And I, you know, with a bunch of the founders I work with, I share the advice with them, which I'm like, there's only a few pieces of advice I get, which is one, it's much easier to get a divorce than it is to get rid of a board member yes that is very true so i'm like there's legal recourse to get rid of divorcing and there's not with board members exactly so i'm like you know however much time you start picking your spouse think just as hard about picking your investors so you know because i think a lot of founders going to be like well i'm just going to pick whoever writes the biggest check you're like you don't know if that also means you picked the biggest asshole he's totally totally right or what their standing is within their firm or uh you know whatever what their motivations are network what's expertise do they have how what are they underwriting to and what false uh pressure or things are you going to get put on the business because of that exactly so i'm like rule number one to me is like make sure whoever you pick you're happy working with them for another decade yeah you know because i now have board members like glenn who sat on our board for more than a decade yeah right and it's a great relationship and i'm like man imagine how painful the last 10 years would have been if you had an adversarial relationship with your board right Right.

48:57So I think rule number one, you have to like the people that you're working with, right, and have a deep sense of trust and respect mutually. Right. Two is I think it's super dangerous to maximize valuation. So we were always very conservative about that. Yeah, we had offers for, you know, bigger checks at every round, but we never optimized for that. Because going to the point you made is like, well, what outsized expectation does that set on our execution? Right. Because yeah, you can go, you know, you see it, you see these companies will take a billion dollar valuation at pre-revenue. You're like, okay, well now guess what the expectation is for your growth, right?

49:31Like now it's all or nothing. You got to go all in on, you know, on growth and hope you hit a stratospheric number or you're going to have massive down rounds that kind of has implications for all your employees because you're going to issue options to them that are all underwater. It's going to be super demoralizing. You're going to have to do a down round. And if things go sideways, it eliminates your optionality on what the outcome could be. Because an acquirer is going to come and look and say, a billion dollars for a zero dollar revenue company? Like, are you insane? Yeah. Right? And I've seen that, right?

50:00Where great companies and great teams, frankly, get stranded because their valuation is so sky high that there's no exit. Like, no acquirer wants to touch them and you're not far enough along to be public. So what happens? You know? So I think there's super high risk in just saying, I'm just going to chase maximizing valuation. And at the same time, I think that impacts who you think about as being the folks you want to work with. Yeah, whenever I say this, it sounds very much self-serving and like I'm talking my own book. So it's appreciated when founders actually validate these things as well.

50:33So thank you for that. I guess it's hard to know the counterfactual on the product and the coupling and the integrating into the suite a little bit more. You obviously don't know the road not taken on it. I'd be curious on the very bundled side of the house. and we talked a little bit about this earlier, and then the other side being totally federated, independent, separate products in there. I don't know where you think of where you landed. It sounds like there were shared workflows and services between the two. Where were you on that spectrum? And what were the, I guess, we've talked about some of the benefits, but what were the trade-offs or considerations that might be non-obvious that were negative in some way?

51:20Yeah. You know, it's super interesting. I look back and I'm like, are the things I would do differently now? Probably. With hindsight, you always have that luxury. I think some of the biggest trade-offs is things like, what is your development efficiency? Obviously, we had to duplicate some work because you now have more products rather than less. Two is you end up with more inconsistencies because you're like, well, this product did it slightly differently than the way that product did it. But if they happened to be the same product, they'd be more consistent with each other. And three becomes complexity on the user and customer side, which is, hey, we love Terraform, now we want to dot Packer, but it's a different tool, versus if it was just part of the same logical platform, right?

52:00So I think it creates some of that customer friction. So those are probably the negatives. The positives, though, is it allowed us to experiment and go a lot faster with these things, and almost treat them like a little bit of a laboratory. We can say, hey, you know what, why don't we try this thing with Packer, and if it's successful, we'll bring that feature to the other products. So it allowed us to actually do a lot of that sort of, I'll call it, you know, experimental laboratory stuff, right, where we'll say, hey, we have a new configuration language, for example. Today we use what we call HCL.

52:25It's the HashiCorp configuration language. When we first used that, we did it with one product only. It was Terraform. And it was massively successful with Terraform, so we ended up bringing it to all of the other products. So it gave us this ability to kind of experiment with things that would be a lot harder if you have one platform, because the cost of experimentation would be very high. You can't be like, add this one thing to your one new product. It's like you have to replatform the entire thing to it. So I think the flexibility of having multiple insertion points was valuable because it was a simpler conversation the ability to experiment was valuable right and the ability for us to iterate a lot faster versus it being sort of a larger platform was great because you're in you're in a market that's highly competitive and dynamic and evolving all the time so that speed and agility was super important so i think there's some trade-offs now as i look at it we're now starting to converge you know we actually just did a marketing rebrand on monday to the sort of notion of an infrastructure cloud we're really positioning two logical subsets of our portfolio, infrastructure lifecycle management and security lifecycle management.

53:23So what we're starting to do is say, hey, how do I take the logical parts of the portfolio that are infrastructure related, converge them together? How do I take the security parts of my portfolio, converge them together and deliver them as sort of a logical platform? But the advantage is now it's like these are not products that are going zero to one. We've gone through that. We did the iteration on product market fit. We know they have fit. We know they have logical synergy with each other. And we've done a bunch of these experiments. So now it makes sense because you're just in a different place in the market, right?

53:52Ten years ago, the market was figuring out what did it need. Now the market knows what it needs, but they're asking us, hey, can you simplify to make it easier for us? So I think that's the other trade-off is you kind of have to understand where are you in a market lifecycle, right? And I think you see the same thing, for example, in a lot of the data AI space, right? You know, you think about Databricks early on, they started off by saying, hey, we're going to make it really easy to run spark because that's the market pain and then over time they were like well the market also needs a data lake and the market also needs an ml ops pipeline and the market also needs these other pieces but because it's such a dynamic market you couldn't have known those things up front you had to wait until the market needs were clear build a bunch of independent things and then bring them together in a logical platform right so that's like a great analogy to me in a slightly different market than infrastructure where as a market's evolving it's not obvious to anybody you know what are going to be the important pieces so having slightly more decoupling lets you go fast versus if you're trying to build a platform doesn't make sense platforms make a lot of sense once a market is stable take workday it's not a market that is you know you're like i don't know what hr needs it's like well it's been the same thing for 50 years yeah so you know you need payroll you need benefits you need performance reviews whatever so you start by building it as an integrated platform because you know up front what all the requirements are.

55:05It's not a particularly dynamic market. So I think that is important. I see often founders make that mistake where they try and go platform too early. I already see it now. There's probably 50 AI, Gen AI platform companies and you're like, guys, you don't know what last week looked like was different than what next week looks like in Gen AI. So how are you going to build a platform? You have no idea what the features are even going to be. Interesting. So it's like you kind of have to wait until some of these markets play out and then over time a platform becomes a natural aggregation. One of the decisions on the product side that you all made was giving independent names that were disassociated from HashiCorp.

55:45I guess one, I assume, how did HashiCorp, the name, come to be? I assume it's a derivative of Mitchell Hashimoto, but how did you guys actually land on that? So the name is really funny. So when Mitchell started, he basically had a bunch of contracts that were ready to go to do some consulting work around Vagrant. So he needed a corporate vehicle to basically sign these contracts under. And he had been doing personal consulting under his LLC, HashiCorp, because it was just a one-man LLC just for his personal consulting stuff. So he's like, oh, well, I have this LLC. I'm just going to sign this first few contracts for Vagrant under that.

56:16And then together, we can brainstorm what we actually want to name the actual company, right, rather than just my, you know, one-man LLC. And I was like, yeah, that's fine. Let's just get going on those contracts and like, we'll figure out the name. So we spent a few months thinking about like company names of like, well, what would we want to name the company given this bigger mission and what we want to do and you know at the time if you remember this was when it was very like in that everyone's startup name was missing letters and like your logo was like a cute animal or whatever and we sort of hated all of that we're like so the brand ethos was always luxury defense is always what we went for right like we wanted to feel like mission oriented in the way like you think about a defense company is but luxury in the sense that it's like attention to detail craft polish so we wanted something that would convey that so our logo always was you know symmetric sharp edged right it was not a cutesy animal and what we liked about hashi corp is it started it sounded vaguely you know vaguely dystopian right like you think about like tyrell corporation or like you know fuji heavy industries right it has like that kind of a vibe to it and so we liked that because it kind of fed into that sort of luxury defense vibe so we spent a bunch of time thinking about names we couldn't come up with anything that we liked better and at some point we were like honestly we have more important things than the name like whatever let's get on with the product stuff.

57:32So it just stuck. That's funny. So it was just one of these like happenstance coincidence type of things. Well, and then on the product side, it's interesting because in some ways, I imagine I've had this experience before where people won't know HashiCorp, but they will know Vault or Terraform. All the time. I'm sure you've lived that way more. And so I would say conventional wisdom to disassociate your company name from your product name. That's certainly unusual. That is not what I would say most Silicon Valley venture investors would recommend. So what were the considerations and the puts and takes on that?

58:12Yeah. So it's funny. So it goes back to what I talked about earlier, which was like we wanted the optionality to divest without us hurting the brand. So we actually took it to an extreme in the early days. In the early days, each of the product websites was totally distinct. They had different fonts, different colors different branding different logos the only way you could tell they were hashi corp was like the copyright in the footer in gray text was like copyright hashi corp like it didn't even say hashi corp anywhere on the websites and so this was very much a deliberate strategy because we're like well we want to launch this thing what if auto fails then we can quietly kill it and nobody will realize that it's sort of related to the rest of the portfolio now you flash forward a few years and we had exactly that problem we'd go to customers and they're like well i've never heard of hashi corp and we're like well we make you know vagrant pack or terraform closet and they're like oh we use all of those things and you're like and you don't know us and they're like yeah we didn't realize there was one company behind all of them yeah And so we're like, okay, this is we've created a problem for ourselves.

59:06So this was probably around 2017 that then we did a major flip on the brand to say, okay, all of the websites we're going to update to go to a consistent look and feel. We're going to bring them into sort of a single color palette. We changed all the logos to make them much more, not the same, but to follow an isometric grid so they all have a similar pattern to them. And then all of them got relabeled. So instead of just Terraform, it's always HashiCorp Terraform. It's at a vault. It's HashiCorp vault. So the websites became a lot more HashiCorp branded. and then they had a common HashiCorp banner that would link back to the homepage.

59:38So we made a big deliberate flip around 2017, 18-ish to bring them all into much more of a consistent framework. But even now, years later, we saw people who were like, oh, I've used all these shows and never heard of HashiCorp. So it's one of these things where it's like the early decision actually gave us the flexibility to be able to kill products like Surf and Auto, and it worked. We were able to kill those things without it causing a reputational issue for us, right? Because in the early days, we wanted to be able to do that experimentation. the downside is it created some of this brand you know recognition issue that for the most part i think has been resolved right like it used to be every meeting they had no idea who we were you know now it's like i don't know maybe one in 50 that they don't know that it's all linked back to hasha court but you know it took years so so maybe not something you would overly recommend it made sense at the time is that a fair uh distillation of all that it's probably caused some more headache than benefit.

1:00:29Absolutely. I think we were more worried about the brand impact than, frankly, the reality was like, people understand you're a startup, you're experimenting with things, not everything works. We would have been better off having it all under the Hachicorp brand to begin with. Makes sense. Your market had some, being open source and being your monetization model and all that, there's maybe a little bit of uniqueness to this, but I actually think the point is probably broadly applicable in that your users were often different than your customers in some ways. And I don't know if that's the nomenclature you would use for it, but the number of people that were using one of the products versus paying for one of the products were wildly different.

1:01:11And even if you're at an organization or you're an entrepreneur listening, and it could just be your buyer is the C-suite, but your individual user is someone different. And there's trade-offs and considerations for who you're serving, how you reach them, all that. Can you maybe talk to me a little bit about that and landing on how you built product for who and where, and then ultimately monetizing and how you thought about that for who and how? Yeah. I mean, I think this is what makes open source monetization hard. And I think a lot of companies get this wrong is exactly, you're right. Our user is not our buyer typically, Our user is developer, downloaded our product on our website or GitHub or whatever.

1:01:53They're just trying to solve whatever pain point they have. It's their boss or their boss's boss who is saying, how do I have a consistent multi-cloud strategy? How do I manage the risk of my developers doing something stupid and creating a security vulnerability for me? How do I manage hundreds of applications in a cost-effective way? That's a buyer consideration. It's not a user consideration. so we very much took the split approach of saying our open source and our community focused efforts are focused on the user how do we solve their problem in a way that's elegant that they're going to like but our commercial focus is actually on what the buyer's concerns are which is how do i think about managing risk managing cost managing sort of complexity at scale it's a different set of concerns and then our sales motion is really geared around get to those champions who are your user have them sponsor you to get to whoever it is the director of infrastructure or VP of infrastructure.

1:02:45And then you can position to them the commercial value prop, which is, hey, your developers already love us. What if you standardize our technology, we can solve all these other problems for you, right? And so it was very much a bottom-up motion in terms of the adoption is bottom-up, but we have an outside enterprise sales team that drives those conversations at a director of VP C-suite level. I assume from where the business started, and at one point you were pursuing your PhD, right? Or you were going to go down a path of academia. That was the intent. Yeah, I didn't get very far. You didn't get very far along the way.

1:03:16I assume you didn't grow up thinking you would have insights around enterprise sales and platform sales and all that. Maybe as you dove into that or got exposure to it, what was the most surprising learning or something that was just counterintuitive to you that would be interesting to someone listening about, you know, big deal sales and all that? Oh, man, I feel like I got multiple MBAs worth on this. You know, I think there's maybe two things, which is like one is, I'll show maybe the most surprising thing, and then two is like, how do you actually learn this stuff and sort of make it work?

1:03:52Probably the most surprising thing to me, I'm like, guys, it's 2020. Does anyone really like buy software over a steak dinner at a golf course? Like, you know, surely that was like, I don't know, 80s power lunch with two martinis. You know, you're like, that's what I, you know, my mental image of this stuff is. And then you know i literally cannot tell you how many steak dinners i've had over the last 12 years it's probably i will have cardiac arrest 20 years early as a result gout yeah exactly and quadruple bypass i'm sure um because it's still done over steaks dinners at a golf course right and i think it goes back to the earlier point which is it's about trust and so so much of this is it's not about the steak dinner right like that's kind of irrelevant it's about you're taking this customer you're spending time with them you know they're yeah you're going to do the meeting in the day where they're gonna say tell me about the features in the business case and we'll go over pricing sure but it's the dinner where they look you in the eye and say can i bet my career on you because that's what's happening right there's a vp who's saying i'm betting my career on you can i do that help me feel good about that right and that's what that dinner is and so you end up realizing that yeah you talk about software you talk about cloud but at the end of the day the adoption is deeply human right and that's why that won't change and And, you know, I think, you know, rumors of us moving everything to, you know, we're all going to be doing sales deals over Zoom is, I think, vastly overblown because at the end of the day, it's about human trust.

1:05:13Right. And so I think to me, that was the interesting lesson where I was like, ah, that's like such a kitschy, you know, nobody does that anymore. Tactically, obviously switching the language from Twitch of like, we will make you successful versus I don't know. It sounds like that was one way of actually operationalizing that. It also sounds like lots of red meat helped along the way. But were there things stylistically that you figured out helped in building that trust beyond just FaceTime and being there in person and presumably being honest? But it sounds like maybe not overly honest. Yeah.

1:05:51Honest with a touch of, you know, confidence inspiring too. Yeah. And, you know, I think the other interesting thing is these markets are very predictable in terms of who are first movers, who are the risk takers, and how does the dominoes fall? And what I mean by that is, you know, once we had brought in some senior executives who had built go-to-market motions, right, and we can talk about, you know, bringing in Dave as our CEO, one of the things we end up realizing is there's a playbook to this stuff. So for example, you're going to go enter Singapore as a market. There's a sequence of buyers, right?

1:06:24So you're going to go in and say, hey, the first organizations I'm going to go sell to are a specific set of banks because they're the risk takers. They're the front edge of technology investment. And when you land those few banks and those few telcos, everyone else in that Singapore market looks to them. So if I can land them, I go to the next customer along and say, hey, you know what? The bank up the street, they're our customer. And they say, oh, really? Okay, well, if they're doing it, then great. We feel comfortable. so you end up realizing there's this very repetitive domino effect right in the same way if you can go land goldman sachs and morgan stanley then you go to the next bank along and say hey by the way goldman and morgan use us and say oh really if it works for them then it's going to work for us right and so there's this sequencing of you know you've these early adopters they set the the sort of trend if you will for the market but they're also the ones that other people look to later on in the curve to de-risk their decision right because a bunch of the middle enterprises are not going to be the first movers and the risk takers.

1:07:18They're going to kind of look to their peers. So that was the other interesting lesson is that it can't be prey and spray in terms of a sales strategy. You have to enter these markets and say, okay, I'm going to go win this account. I'm going to go win, you know, Barclays Bank because they're going to be the first one in the UK, but they're going to let me get to Lloyd's, right? And Lloyd's is going to let me get to, you know, so on and so forth, right? And these markets are just very predictable and sort of the sequence of who are the early movers. The go-to-market staffing across the different products, you mentioned like there was kind of a throughput of a DevOps buyer, but some things are more security oriented, as you alluded to.

1:07:57Some things are more, you know, software development lifecycle oriented as well. And so did you all end up building different sales teams to focus on different products or did everyone sell all the things in the bag? How'd you think about orienting the sales team? So we went through a number of evolutions on it, right? So originally, we were too small to have, you know, any really notion of multiple sales teams. So it was a single core sales team. And we had a single common pool of solution engineers, our technical sales folks. And that was really the early days. Most of our focus was Terraform and Vault at that point, right?

1:08:32As we got a little bit bigger, we actually introduced the notion of an overlay sales team. So then we had a specialist set of sellers and a specialist set of SEs just focused on networking with console because ironically even though infrastructure and security seem more distinct it was actually networking that was the you know more distinct of a sales motion um so our overlay was really focused more on console at the time and then over time we realized actually the sales motion side of it is pretty similar it's the technical side that's more distinct right so then we sort of folded the sellers back into the core and now we have a notion of what we call sort of generalist se's versus specialist solution architects so we have our solution architects that sort of specialize in different domains, infrastructure, security, et cetera, networking.

1:09:14And so that's kind of the way we sort of specialize it today. We've, shifting gears a little bit, we alluded to different points along the journey, but you and Mitchell were at the University of Washington together and best friends over the course of four years. He started working on, you guys were at Keep together, then he started working on Vagrant on the side. Is that the right? So Vagrant actually started at University of Washington. Oh, he did, wow. Yeah, yeah. So Mitchell came to me with this idea. He was like, hey, I want to build this thing Vagrant to simplify setting up my developer environment.

1:09:45And he was doing all this stuff to try and isolate the app. And I remember because like this was maybe 2007 or 8. And he didn't know about virtualization at the time. I was like, hey, have you seen this tool VirtualBox? You can actually create like a VM on your laptop and like you could probably put your whole dev environment in the VM. And I remember Mitchell's like, oh, that's really cool. I'm going to go like research it. the next morning when I saw him, he's like, I rewrote all of Vagrant around VirtualBox, like, this is going to be the future of how this stuff happens. And, you know, to Mitchell's credit, it was the future of how that stuff happened.

1:10:14Wow. And so that started then, and then did he recruit you to Keep or? He did. Yeah. So that was the whole, you know, the funny thing was basically we both moved to the Bay Area, but for two very different reasons. Mitchell went to join Keep. I went to go get my PhD at Berkeley. And Mitchell would pester me nonstop. You know, he would text me a thousand times a day being like, hey, you have to interview, you have to meet the team, you have to kind of, you know, chat with them. And I was like, I don't want to go to industry, I want to go to academia, but I'll make you a promise. I will do one interview if you stop pestering me about this.

1:10:49You know, and so I should thank him for being so persistent, you know, because I did do an interview with that team. It was my first real startup exposure. So it was the first time I met a team that was like, you know, it was at the time seven or eight people, you know, a very cool kind of environment right in Soma really like uh you know a fun building culture and I was like this is really cool I could really have a lot of fun here so I ended up deferring at Cal for a year uh to join the startup so I never even started there I just deferred to join Keep a year later they called like you have to make a decision are you coming back I'm like I'm having a lot of fun Berkeley's not going anywhere so I ended up dropping out to stay at Keep uh and then you know a year after that you know Mitchell left and then I left shortly thereafter after the HashiCorp.

1:11:30Huh. So, so, uh, you all spent, I mean, friends for, uh, what now 17 years or something dating back 07, 08. Yeah, exactly. Back to 07. Yeah. And, uh, and you worked together from 2012 to 20, I mean, I guess in some capacity still today, but, but formally, uh, through keep and HashiCorp, how long was that journey like formally working together? I mean, it was two years at Keep, and then Mitchell left late last year, so 23, so call it 10 years at AshiCorp. Okay. In what ways did you all complement each other? Were there clear overlap areas, or was it kind of perfectly symbiotic? You know, I think we had both different strengths that we brought to the table, right?

1:12:20You know, Mitchell was always a developer's developer. He still is. and so you know I think he brought a magic touch in terms of developer experience really being close to how should the tools feel how should they work what's going to create a really magical experience and he pushed us really hard on a bunch of things like you know that time to value has to be less than five minutes for the tools and how do we make it really a single command line to really start you know using the tools and seeing it and so there was a lot of things Mitchell really pushed us on from a user experience to kind of really you know surprise and delight was kind of the way we thought about it.

1:12:54I've heard he credits like his Apple retail store experience for some of this, like having worked there, I don't know, high school or college or something. Yeah. So he worked there during college. And I think Apple's very religious about some of this stuff is that notion of you surprise and delight. And so he brought a lot of that ethos to the product building. And then on the other side, I was always more of a distributed systems junkie, right? And like, that's what I wanted to go get my PhD in. And, you know, I've always, you know, that's why I did my undergrad thesis work in too. So I was always a junkie on the distributed system side.

1:13:23So I sort of was focused on the back end, which was the architecture of the tools. How do we design them in a way that will be, you know, easy to operate, scalable, you know, you know, elegant in terms of how they work. And Mitchell was on the front end of like, how do you make the experience, you know, easy to use, magical, beautiful. So it's like, it was a perfect sort of, you know, compliment of like, I'm going to make the back end of this thing work, you're going to make the front end of it beautiful, you know, and then we can create a really compelling set of products. And then as we kind of, as the company grew up, our roles sort of very much changed.

1:13:51Mitchell stayed, I call it very much like chief scientist, chief engineer, however you want to think about it. He was very much embedded, hands-on programmed, you know, five days a week. He was very much not even a 10X engineer. He was like a 100X engineer. And then I ended up taking much more of the management responsibility, right? Because just as, you know, a small startup, someone has to be, you know, someone has to be at the helm. And it was one of those things where I would never say I loved it. I would not describe myself as an operator, but it was like, I maybe disliked it less than Mitchell.

1:14:17Yeah. Well, to that end, so you all passed the CEO title back and forth. It seems like playing hot potato for a little bit on who is CEO. And then you decided to be co-CEOs. And then at some point along the way, maybe the totality of the journey, were you communicative with the board and the investors? Hey, neither of us really like that job specifically, and we're going to want an outside CEO? Or was that an evolution of playing hot potato back and forth? No, it was definitely an evolution, right? So for the first year or two, we were so small that CEO was a nominal title. At some point, once the team got to 10, 15 people, you need full-time management, right?

1:15:02It just can't be chaos if everyone does whatever they want. So at that point, it was when we were hot potatoing it back and forth. And then at some point, me and Mitchell had a conversation where we're like, okay, Mitchell, it's clear you hate this role. Like, why don't I just step into a more of a full-time management role? And so, you know, we sort of formalized that. Maybe we were around 12-ish people or something. And prior to that, you guys were like switching every quarter or something? Every month. It was like, you're CEO this month. I'm CEO next month. It worked about as well as you thought it would.

1:15:31Yeah, it sounds like a very, yeah, something that I would not recommend to people. You know, there's a reason it's not a widespread pattern. Yes, yeah. so we did that for a bit it clearly didn't work then i was like okay mitchell you hate it i'll just do this and then sort of that was sort of the pattern until maybe we got to about 40-ish people and that was right around our series b when we started deciding to say hey you know it became clear to us that and this was right around when i said we were started that soul search right the board started to push us and say what's how you grew up the business and so we went through a number of different decisions one decision was hey when we grew up are we an smb oriented company or are we an enterprise-oriented company?

1:16:11And I think pretty quickly we made the decision we want to focus on enterprise because that's where the budget is, that's where the problems are technically interesting. So let's focus there. So we made that decision. Then the second sort of question became, well, what's the products? And I think we struggled with a bunch of commercialization models, right? Because open source is not a well-understood model. So we went through a bunch of different things, ultimately landed on sort of an open core model, which has been sort of the predominant way we've monetized up until we introduced cloud services.

1:16:38but then the third question for us was like well who leads this company because now we're saying we're going to build an enterprise sales motion and build an enterprise go-to-market as two people who have never worked for an enterprise sold to an enterprise like you know could we figure it out from first principles maybe but that's a pretty high risk approach so that's when we sort of engage with the board to say hey we think we need help on a leadership side it wasn't necessarily that we were looking for a ceo but we were like we need someone who has done this right and so we weren't sure what we wanted is it a cmo coo president cro you know whatever so he brought in an exec search firm uh and that's what we told him we want that and the search firm had no idea what to even do because they're like you want a coo cmo cro president like Like, what are you, like, these are different jobs.

1:17:31We need a grown-up that knows enterprise. That was our job. That's a hard spec to hunt for. So to their credit, you know, they didn't tell us we were total idiots to our face. I'm sure they thought that. But they basically put a whole bunch of different people in front of us with very different profiles, like a CRO, a COO, a CEO, whatever. And we ended up hiring a CMO for a number of reasons that didn't work out, right? So we basically said, okay, back to the drawing board. And then having spent a little bit more time, we're like, okay, we're being a little bit unreasonable. What we really need is actually two very different people.

1:18:06We need a VP of sales who comes from an enterprise background. And then we need someone who understands the marketing side of it. And then we're open to that. Is it CMO, COO, president, whatever. So we said, actually, let's run two separate searches. Because now it's obviously much more constrained. So, okay, we can do a VP of sales search. Those people are easier to find. It's a well-defined profile. So we ended up finding this guy, Rob Abbott, who ended up joining eventually to be our first VP of sales. And then in parallel, we were looking for much more of a focused someone with a marketing expertise who could help scale the company.

1:18:40And through that process, we ended up meeting Dave McJanet, who coincidentally knew Rob Abbott quite well from their time at Hortonworks. And so when Rob was talking to us, he was like, hey, I'm thinking about taking this job at HashiCorp. He called Dave. I was like, what do you know about these guys? like, you know, am I crazy? And we'd had a chance to meet Dave, you know, previously when he was joining GitHub. And that was a part of the marketing search, although he wasn't, he wanted something bigger at that point in time. Is that right? Well, Dave was at the time he had gone to be CMO at GitHub.

1:19:12So he had done the CMO, he was CMO there for a little bit. And then Rob called him and Dave was, you know, transitioning out of GitHub. So he was sort of an EIR at Greylock at the time and so when rob called him he's like oh yeah i know the hashi corp guys i talked to them like you know 18 months ago he's like let me re-engage with them so then we already had this parallel search going for marketing so we re-engaged with dave and then it became this sort of you know two in a box basically we ended up saying okay what if we hire both of you guys you've worked together before you know each other dave brings a deep set of marketing experience rob brings a deep set of sales experience and they know how to work together with each other and so it almost became a package deal they started within two weeks of each other um and it just so happened that rob knew dave and called him and that sort of reignited that search basically in seeding that role the responsibility the title did you have the ego element of like oh i'm giving up this this ceo title and this is the canonical thing for silicon valley startups and i'm gonna give it to someone else to come in or was that not something you were thinking about?

1:20:21So I would say it was a it was a struggle but not for maybe the not for that eager reason. I think when we started the search we were actually you know the conversation me and Mitchell had was hey what title are we open to and are we open to CEO? And the reason that was important is because the search firm was very clear they're like if you're open to the CEO title that opens up a different pool of candidates than if you're not open to it. And so I think for me and Mitchell the conversation became is like, again, what are we committed to? Are we committed to the title or are we committed to the success of the idea and the company?

1:20:52What's more important to us? You could have the title and the company doesn't succeed. Is that more important to you than not having the title but you see the company succeed? And what was very clear to both of us is we didn't care about the title. And in fact, the CEO job is a terrible job. I don't wish it on anyone. So, both of us were like, we're more than fine being CTO or you know vp edge or whatever else it needs to be neither of us felt that strongly about the ceo title so that was actually not the hard part the hard part was you know and very much i think at the 11th hour we got cold feet on on the dave decision it was you know it was you're giving control away of your baby yeah you're bringing in your boss you know fundamentally in some way you know you can think about me and mitchell's reporting to dave um and they have a seat at the board and so So it's like they're not like any other employee where like if it doesn't work out, you can cut your loss and move on.

1:21:44Getting rid of your CEO is an ordeal. So I think that's what gave us cold feet at the 11th hour was like, hey, are we going to lose control of the business? Like what if Dave's not a good fit? What if there's a cultural clash? What if we don't agree on strategy? And I'll never forget, I had a great call with Glenn Solomon where I called him and I'm like, you know, I can't do it. I don't want to give up control. You know, not for the title, just like what if something goes wrong? and Glenn walked me off the edge because he's like hey listen at the end of the day this is you and Mitchell's company right like it doesn't work without the two of you and so if it doesn't work with Dave like you have our backing there's like there's not a world in which we'd like are going to pick you know to keep Dave over you and Mitchell if things go sideways like it doesn't make any sense um and so that was a super important call that I will never forget because it was like okay having that support and that assurance of the board was like what got us over the hump because we felt great about Dave.

1:22:36We were like, we think he's the right guy, but like, but what if? Like, what if it doesn't work? And what happens? And so it kind of got us over the hump. We ended up making that call and bringing Dave in. Honestly, I look back, it was probably one of our best decisions. And so it was a year long kind of vetting process for someone? It depends how you, are you measuring from the first time of the exact search or the second time? Yeah, well, I guess when you were most amenable to a CEO coming in. Yeah, that process was probably, yeah six six to eight months probably was there anything beyond just time uh that got you comfortable with the person specifically in dave or like what was the actual vetting process yeah i mean the early date the early dates i use dates because uh that's how it felt like you felt like you're sort of dating someone right because you're like let's go to dinner let's grab drinks Let's like spend time together to understand like, how do you see the world?

1:23:32Drive-in movie. What? Drive-in movie. Yeah, exactly. So, it very much felt like we were dating for a few months, which was funny because at the time I was dating my now husband. I'm like, sorry, I need to go see my other boyfriend. Yeah, exactly. So, you know, it did have that vibe. But then what we said is like, okay, well, how do we make this real? Because you can only get so deep at a dinner. And so, then we started setting up a bunch of whiteboarding sessions where we're like, let's just bring Dave in and read him into the real problems. Like, hey, Dave, this is a product strategy question, or how should we think about marketing this, or what's the right positioning for some of these things?

1:24:06And they were true working sessions. Like, as if he was an employee, like, we're just going to give you all the context. Let's work through it as if we'd work together to understand what's our true working style in some of these things. And like, you know, can we add value to each other? Do we conflict if there's a conflict? How do those things get navigated? And I think what became very clear is Dave has a very similar working style to we do. And it was just like, okay, this is just very easy, right? Like, it's very collegial, there's high respect, there's high trust, like, you know, it was a very good dynamic.

1:24:38And those were honestly more valuable, frankly, than, you know, the dinners. Interesting. I heard on Dave's side, at least, he kept asking you all the same questions over and over again. And it wasn't because he forgot what you had said previously, actually quite the opposite. He was trying to validate that you all actually saw things the way that you had said it previously and you were putting on a dog and pony show. Can you maybe talk about like from his vantage point? And because it's obviously a mutual sale that's going on. Yeah, I mean, I think Dave was colored by some of his experiences.

1:25:18He had other companies and maybe, you know, most recently coming off of GitHub. So I think the things he wanted to pressure test with me and Mitchell was like, where does our actual conviction lie in building a business versus building a cool thing that we like? Because again, it goes back to that thing is like, are you obsessed with the problem or are you obsessed with your solution? Because I think from Dave's perspective, he's very much a market sort of driven person. He's like, I see the market need here. The problem space is very clear the opportunity is really clear what's unclear is are you and mitchell gonna die on the hill of you think surf is the best thing since sliced bread or if it doesn't work are you willing to cut losses and be pragmatic so i think what he wanted to understand is where's our passion lie if we have conflicts on some of these things can we resolve them in a reasonable way are we like no every hill is a hill we're gonna die on right and you know get a sense for us of like okay is it you know how flexible is the passion in terms of being able to direct it to customer interest and what's our appetite to build an enterprise sales motion because i think that was one of the challenges they had at github was it was like hey we're bottom-up developer-led we don't want to build an enterprise sales force right and that was a big point of conflict for dave was like well then why am i here that's like you know either we want to build an enterprise go to market or we don't right uh the halfway house doesn't make sense yeah um and so i think that's what he wanted to pressure test was like hey if we bring in sales people and they start to change the culture because it's going to be an enterprise sales culture how do you feel about that right if we need to evolve products if we need to reposition things right like so i think those are the things he kept asking over and over i think just to get a sense of like hey how pragmatic are we and where's our conviction on these things i uh can you maybe take me through your personal journey once dave came in like what what did you go do then after that and what did mitchell go do then after that yeah so i think what started to evolve is like dave's focus very much became go build to go to market motion because when he came in it was ground floor basically like effectively call it no marketing, no sales.

1:27:17We had one or two sales people. We had some marketing that we kind of put together, but it was nothing polished or enterprise grade. So he was like, I'm going to go focus on building that out and building the executive team. So then he started to bring in our head of finance and customer success and support and HR and all of those things. So he's really focused on build the E-team, build out the marketing function, start to build out the sales function. We had Rob Abbott at the time who joined his sales, so he was hiring and building out a sales motion. So they were really focused on that side and he kind of deferred to me and Mitchell to say you guys go figure out the product strategy but we worked very closely with him on thinking about how do you monetize open source what's the you know enterprise of capabilities we should be thinking about building but he sort of deferred the roadmap the execution on the the actual product side to us and then between me and Mitchell you know Mitchell is very much I'll call it like you know our chief scientist right so if we needed to like hey we really need this you know you know sentinel policy as code capability for Terraform.

1:28:10Great, go put Mitchell on this thing. It's a strategic high priority project for this. He's going to go help build it. First, I spent most of my time with sort of product management and engineering leadership on like, what do we need to go build? Who do we need to hire? How do we sort of staff for these things? So it ended up being a really nice balance where each of us had a pretty clear swim lane of like, where can we add value? And there was really not much overlap. There's this adage I hear from experienced CEOs, operators like yourself, that they definitely regretted hiring too late for certain roles.

1:28:38I've heard you allude to this at different points. If you were a founder thinking about hiring for a specific role, how would you go about deciding if it's too early, glaringly too late, or the right time to bring in someone experienced into a specific seat? Oh, man, it's so hard. It's such a hard question. I think by the time you're thinking about it, it's a good sign that it's too late already. That's my general experience. By the time I'm like, we really need that person, you're like, yeah, that means we needed them six months ago. That was my general experience of it. I think the other thing that's really helpful has been finding mentors who have seen the movie before.

1:29:27That was, I think, the thing we really didn't have prior to Dave joining. Obviously, we had people in our network, but it wasn't the same. They weren't close enough to the business. I think once we had Dave in, he's like, well, I've seen this movie from zero to IPO multiple times. And he's like, he could just be like, oh, we need to go higher ahead of customer success. And you're like, really? We have like four customers. Like, do we need a head of success? Like, what are they? Who are we making successful? But, you know, he was able to see like, yeah, but you have to build this machinery because it's going to take time to bring that person in.

1:29:54They have to build and train their team. You have to build a process. So by the time it gets going, it takes, you know, nine months a year for that machinery to exist. And by then you're going to wish you had it. so I think having some people in the boat who've seen the movie super super valuable and then one of the first things he did was really build out an e-team who had all seen the movie right so you know finance and hr and success and sales etc marketing who had all done it and so those people knew the playbook of like okay at what phases do you need it so I think our biggest misses were probably in that earlier phase prior to when we didn't have dave where it's like we me and just didn't know first time founders we'd never seen the movie by the time we figured anything out, it was often, you know, it was often late because it was glaringly obvious.

1:30:33One astute observation that I guess I practice it implicitly with companies I'm on the board of, but I never heard it articulated as crisply as you had, is that the leaders that you found to be most successful in their specific roles were the ones that could also forward plan or project their org charts and be able to talk about how everything fit together. Can you elaborate on that point and why that's the case? Yeah, I mean, I think what's so hard is if you haven't seen the movie, there is these breakpoints in scale, right? The thing that makes sense, zero to 50 is different than 50 to 100, different than 100 to 300, 300 to 500, 500 ,000, so on and so forth.

1:31:17And so, especially for a company that's in hyper growth, you're not in any of those phases very long, right? They are sort of blitzing through them. And so, the problem is, if you're trying to discover the right structures by first principles, you're almost two phases behind at any given point. Because by the time you realize something is wrong, it's already too late. And then by the time you figure out what the right answer is, you're already in the next phase. And so, you're almost always going to be two steps behind, right? Versus, I think, the people who've seen that, they're saying, yeah, I'm hiring at 100, but I'm designing for 500, right?

1:31:49And they kind of know what it looks like at each of those two phases ahead because they know it's like there's just a time like by the time you hire the right people bring them in put the right structure in place fast forward six months okay you know next thing next thing and you need someone who can get you more than one phase at a time right because otherwise everything's constantly in a broken state did you did you find people that hadn't been there done that that were able to still be cognizant enough about that in their scaling journey as well or was that a requisite of people that had had the experience?

1:32:20No, I'd say we had a bunch of people that successfully scaled through a lot of the phases. So actually, like a great guy, John Benson, he joined as our first SE. So he was an individual contributor, having never worked in DevOps or infrastructure or cloud. So he joined as an individual, was really committed to learning the domain. And then he just kept scaling with the business. Over time, he ran the SE team. Then he ran sort of the worldwide SE team. eventually, you know, he stayed with us from basically the early days when we were, I don't know, 20 people, all the way through to post-public, you know, he ran a team of, you know, 250 SEs globally, right?

1:32:55So, I think there was, you know, individuals like him. We also had another, you know, Kevin Fishner, similar kind of a story, moved through many different roles, became Dave's chief of staff. You know, so we had a bunch of these folks who kind of blitzed through multiple things, even though they hadn't seen the movie. I'd say that's rare. There's not a lot of people who can make it through all those phases. There's a lot of people who went through a number of phases with us, but then you eventually outgrew them and had to swap, you know, other leadership in. I think the key to some of those people being successful was A, you know, very high levels of sort of IQ, clock speed, grit, you know, commitment to learning, but also finding them the right mentors, right?

1:33:32People who had seen the movie and could help mentor them and say, hey, here's my problem today. Here's how I'm thinking about it. What's two steps ahead? So a great example actually was John Benson, our head of SC, his mentor was a guy named Peter Pelosi who now runs our global sales team. So he ran it at Splunk at a much bigger scale, 10 times our scale at the time, or maybe even bigger. And so he was sort of a mentor to John Benson and then ultimately helped John's scale. And then when John was like, hey, I've been through this ride for, you know, almost 10 years through IPO. I want to sort of go take a break.

1:34:04Peter was like, hey, well, I'm interested in the role. Right. And so it worked, but it was like, you know, Peter would have been the wrong, maybe not the wrong person, but, you know, his scale was much bigger than what we needed at the time. He was able to mentor someone who could get there. But ultimately, we grew to a scale where then Peter was able to come and have a big impact for us too. In terms of hiring people into the organization, I heard you say that you over-indexed on culture fit. What does that actually mean? That could be a platitude that a lot of companies could say, like, we're very proud of our culture.

1:34:36But I get the feeling that you all, in particular, sought out people that fit in with your culture. And so I'm curious how you go about operationalizing, trying to discover if culture fit exists in an interview process. Yeah. So this was actually a really important one for us. I think maybe it was the, might have been the chief people officer at Netflix once said this, which was, I think, 70 % of culture is who you hire, 20 % of culture is who you promote, 10 % of culture is who you fire. I thought that was a really good distillation of how does culture get operationalized. because it's like you can put all the posters you want on the wall.

1:35:15Like, that doesn't matter. But at the end of the day, it's like, how do you make it real? And it's the people that you're empowering, right? Because they're going to lead by example. They're going to set a tone, and that's going to cascade through the organization. So we really took that to heart. And I think there was a number of influences we had. One, which you might find strange, was actually Bridgewater, right? Sort of somewhat of a famous, notorious hedge fund. But one of the things I think that they do is they're very principled. They actually have a book that they give even to guests, like when we would visit them as a vendor, they would give us their book of corporate principles and they had like 300 of them or something.

1:35:47And they're very, very detailed about their culture and how it should operate and how they want it to sort of look and feel. And we're like, there's a lot of really great tidbits in that. So I still have their principles book. And so we looked at that and we looked at a lot of the sort of culture-driven companies that we admired. And we sort of said, well, what's unique to HashiCorp? What resonates with us, right? Because it's not something that you can just pick what sounds good. And the internet has to be something that you can resonate with and live as a truth. Because otherwise the company can tell us like, okay, if Mitchell and Armand don't live it, then why should any of the rest of us?

1:36:18So we sort of distilled down for us what we ended up calling the principles of HashiCorp, which was sort of a distillation of a bunch of like leadership principles that we liked and thought would be valuable. And that became a hiring guide. So the reason it actually existed was for our hiring managers. So long before we published it on the internet, now we share it publicly. for many, many years. It was just something we gave to hiring managers to say, hey, when you're hiring, this is what you're screening for. And we actually had designed specific interviews. So if you had one person who was your technical screen, one person who was sort of the culture screen, it was the principles fit where we had specific questions about, hey, ask me about a time when you had to be pragmatic about a decision that you had to change your mind for what you originally thought because we wanted to test people on are they dogmatic or pragmatic?

1:37:00Could they talk about it in a product context, right? So we really built it into our hiring and then we factor that into things like performance reviews. So when we do performance reviews, we look at it through the lens of our principles. Even today, all of our annual reviews, you know, we talk about the principles of the company. And then if people weren't a fit, we were aggressive about pushing them out because the problem is it would just cascade, right? It creates collateral damage. So that's really for us was super important. It was like you bake it in deeply to your hiring process. It's still a part of our hiring process, right?

1:37:29You bake it into your promotion review process and then like you fire aggressively when people don't meet it, right? And so that's the only way you make that stuff scale, right? Because as I joke, I'm like, you can't have HR police. Yeah. Well, and that's one of the things like once I wrote culture police here, which I guess maybe I stole from you somewhere, but once you hire someone in, um it's they passed the the considerations on the way uh on the interviewing process and then it sounds like the annual reviews and stuff mapped against the principles as well but how did you uh go about operationalizing the the where there's smoke there's fire and potentially cancerous parts of the org because that's the biggest thing in this is it's not just the one person you hire there's the cascading derivatives of who they will hire and then there's the people that look to them and say well if this person is able to get away with this then i'm going to do this as well so there's so many implications of a single bad hire single person so i'm curious on uh on like how you actually you know manage to put that in practice so i think it was two things um in the early days it hasn't really changed it's like me and mitchell were always very accessible even now oh, you know, new folks will Slack me or whatever all the time.

1:38:46So I think we always kept a very open door policy, made it very clear that, hey, Mia Mitchell is super accessible. If people have concerns on anything, like, come talk to us. I think in the earlier days when we were smaller, it was easier and less intimidating to reach out, right? You know, as you get bigger, it's kind of, people are less likely to ping Mia Mitchell directly. So early days, the way it would happen is like, people knew that Mia Mitchell cared deeply about the culture. And so when they would see that, because they're on a team and a new manager came in or whatever, people would slack us.

1:39:14People weren't shy. They'd be like, hey, can we chat? I have some concerns about so-and-so's leadership style or whatever. I would take those meetings and I would take them very seriously. If someone came to me with that, then I would go meet with other members of that team to understand, hey, is this isolated? It's just an interpersonal thing or no. There's fire there. Oftentimes, those would then lead to action. People would talk to me. I'd go in. I'd do the homework. It's like, yeah, this person really isn't a good fit. Okay, let's have a plan and move them out. As we got bigger, that gets harder.

1:39:44Obviously, it's like I can't be everywhere and people get less comfortable reaching out directly. They don't have a relationship. So the way we've done it is actually it's baked into the same performance reviews. So not only do you do your review, you do an upward review of your manager as well as your peers, and then we do heat mapping. So it's very clear usually. It's like when you run this heat map and you're like, hey, what are their scores from their team? When it's orange-red, it's very obvious on the heat maps. And so then we can go say, okay, great. So senior leadership is going to go do a bunch of skip levels and go figure out what's going on here.

1:40:16Is it just, you know, interpersonal thing, a team, whatever? And oftentimes what you find is when the heat map is red, there's something there. Yes. You can manage up and hide a lot of things. It's really hard. Your direct reports are pretty good leading indicators of what's actually going on in the business. Exactly. So it's like when those things go red, you're like, okay, those are serious indicators to us. So we talked about the number of principles and the stuff you guys valued culturally. I enjoy obscure shout outs and references from internet software history. And it sounds like a fairly influential company that is obscure to history at this point, I think was Basho, who I think influenced you all around integrity, maybe one of the principles.

1:41:07Can you maybe talk about, just to give an obscure shout out to people that long since lost to history, I think Basho is at this point, but what they did that you admired and how it became a part of some of the principles of HashiCorp? Yeah, no, that's a, you've done your homework. That's a great reference. So Basho was a company that we had used their products at Keep when me and Mitchell worked there. It was a Washington-based kind of... San Francisco. Oh, San Francisco. San Francisco-based, sort of distributed database company. Yeah, database, yeah. Very cool and influential, albeit not majorly successful, I think.

1:41:42Yeah, I think that's a good way of putting it. There was a hardcore distributed systems group that would nerd out about it, but it was a niche group. And so we became friends with them. We were users of their technology. There's many things we admired, but I think one of the things that we loved was their approach to marketing was very no bullshit right this was an era you know if you go back to 2011 it was very like databases were in there's a million of them and most of these database companies it's like you go to their home page marketing and it was like they're lying through their teeth right it's sort of like infinite scale unlimited transactions blah blah and then you use this thing and you put three nodes and it falls over and dies so you're like okay well you know where basho was always very technically honest very transparent and open about here's our architecture here's exactly the algorithms.

1:42:34Here's how it scales. Here's the limitations of it, right? It wasn't just marketing smoke and mirrors, basically. And we love that because as practitioners, we felt like this is genuine. No software is perfect. We're not asking for perfection. We're asking you to tell us what do you do really well and what are the limitations of it because that's what you need to know as an engineer. Like I can work with your strengths and I can work around your limitations. But what I can't do is, you know, live in la la land of magic and mysteries, right? So we love that about that. And then their focus on the technical operations, making it a really elegant software in terms of how do you run this in a simple way?

1:43:07How do you upgrade it? Because those are often the hard parts of software. It's not just the day one setting it up. It's like I have to operate core infrastructure like a database. If it goes down, it takes my application with it. How do I make this simple for my operators who have to do this stuff? So we loved that side of it, their passion for the operations teams and how you make this stuff easy to run, their honesty, their openness about technical architecture, their approach to community engagement. So all of those things were things we admired and were very much things we tried to incorporate.

1:43:35And for us, for many years, our products, if you would go to our websites, we would say, hey, how does this tool compare to the competition? And they were all very honest. We would put these things in open source. They were not meant to be FUD. And so we would encourage our competitors often if we were wrong, hey, send us a pull request on GitHub. Fix any factual inaccuracies we have. And they often did, and we would accept their changes. And we were trying to say, hey, here's our strengths. Here's why our philosophy is different. Here's how we've benchmarked it. You know, here's how it stack ranks, you know, strengths and weaknesses, right?

1:44:06And we try to be very, very honest about those things. And that very much came from the work we did with Basho. Tao of HashiCorp. Can you explain to people what it is and how it came to be and what it's done in principle? Yeah. So the Tao of HashiCorp, sort of the companion to the principle. So if the principles are sort of how does the company operate and the people operate, the Tao is how do the products operate? Yeah, the external versus the internal. Exactly. And so for us, when we started to build all these different tools in the portfolio, even though they're different tools solving different problems, we had a common worldview is maybe the way to put it.

1:44:38It's like, hey, we think infrastructure should be managed like this. So you could almost think about our Tau as a little bit of like our manifesto of like, how should infrastructure be managed? What's the HashiCorp view of managing infrastructure? And so it identifies a bunch of these sort of, I'll call it design decisions, right, around, hey, we believe in immutability. We believe in a focus on workflows over specific technologies, things like that. And so we sort of codified those as part of the Tao and published those so customers would know, hey, here's the design philosophy that we sort of follow.

1:45:08But they also became our internal design guidelines. As we were building new products, we would look to the Tao and say, okay, well, how are we going to design around workflows over technologies? How are we going to be pragmatic about integrating with whatever technology the customers need us to, etc.? So it became this sort of twofold internal guide as well as an external, how should you think about the HashiCorp ethos, basically. Has it stayed consistent? amazingly we haven't changed a thing on it and i'm not sure i would change a thing wow that's amazing so how did you go about actually coming up with the inputs into it then you know it's uh i think some of it was just a deep-seated set of beliefs from being an operator of like how this stuff should work some of it came from just kind of i'll call it practical business sense maybe of like you know pragmatism is a good example of it we saw a graveyard of these companies that failed because they were dogmatic right and so some of them just come from you know looking at what other companies had done.

1:45:58You know, I interned at Amazon for a little while. So we looked at some of their leadership principles as well and took some of those in. So some of it was just learning from what are the great things you see from other success stories around you? How do you incorporate some of that? And honestly, you learn from the failures too. You say, okay, well, what made them fail? Okay, you know, these were the things that went wrong. How do you sort of avoid those? And then others were just from a practitioner standpoint, like, what do we value as engineers? So a lot of what we focus on is sort of an elegance and simplicity of it, a, you know, a singular focus of these things, a composability of the tools.

1:46:28So it brought a lot of things like the Unix philosophy into how we think about building tools. And that just came from being engineers, working with other tools and saying, we really like that about these tools that we use. And we dislike these things about other tools that we have to use. One of the things I heard you specifically worked on as a leader, manager, operator was communication. And I think it was both written and verbal, but I don't know. I guess one, And why do you think communication is important for leaders in, I guess, I mean, maybe some of the non-obvious things around that? And then how do you actually go about working on being better at it?

1:47:07Yeah, that's a great question. So actually, in many ways, I think about communication as a second order consequence of execution. And we talk about this even in our principles, right? We say execution is one of our principles. But if you think about execution, at the end of the day, it's about how do I make every individual at HashiCorp successful, right? You have thousands of people. So for them, they need to know each and every day, what is the thing that I should be working on that's going to be most impactful to the business? So, okay, there's either two answers. Every single day, I should ask my boss that question, who should ask their boss that question, and so on and so forth.

1:47:39Or you have to have a communication strategy where it's clear to every single person, this is the strategy, this is what's most impactful, this is what I should be working on. And that's a distributed decision that everyone is making to drive the execution in a consistent way, right? And I've seen many cases of this go wrong at a company where you don't have that consistency. And marketing team thinks this is the most important. Engineering team, that's the most important. Sales team thinks the third thing. And so every part of the company is executing a different strategy fundamentally. And you can tell, right?

1:48:09The pieces don't come together. So for us, we said, okay, for it to work, you have to have a tight communication loop that's bidirectional. meaning it's top down in terms of this is vision this is strategy this is what we're going to go execute in and that has to be top down because otherwise it's inconsistent like it can't be a bottom up everyone defines the strategy but you also need it to be bottom up in terms of well what's the feedback loop we might say great we're going to build surf we think it's a great product let's go pitch it to customers we go in product and earn in market and customers like well this thing doesn't make any sense it's too complicated okay well you need that bottom up feedback loop to be able to adjust your strategy and change course, right?

1:48:46So communication to me, I think about it through that lens. Then when you step back and say, okay, well, we're a remote business. What's the best strategy for communication? Synchronous doesn't work, right? We have people in every time zone. So you have to optimize for something where you're like, okay, it has to be asynchronous fundamentally so that people can consume it at their leisure at any time. And then importantly, when you think about a company that's growing rapidly, do you have to assume 50 % of the people at the company a year from now? have no idea what you said today. So how do you keep it so that they can, like, do you want to do the same town hall every week?

1:49:18Right? Or do you write down the strategy? Right? And so we have a very strong written culture. In fact, we even wrote our own internal document management tool that searches and indexes and categorizes all of our internal documents because we have something like 4 ,000 internal memos. Wow. Right? For different product strategy decisions, marketing decisions, this and that. So very, very important for us is that we have this strong written culture. Everything gets written as a set of documents. they're broadly distributed by default they're open to everyone at the company and we've built tooling and process around how you distribute this then for me personally you know and then a lot of people i think struggle coming into that because they're like they're not necessarily comfortable as writers or good writers and so i think what we coach people on is two things one is i'm not asking you to be hemingway right like you know this is utilitarian you're trying to communicate a decision a context a set of ideas like i don't need incredible prose and perfect sentence structure right like it needs to be you know good enough you know for government work right so i think it's taking a little bit of like you know making people comfortable that we're like we're not grading you here on pros and then two is providing a lot of convention and examples so when they come in we point them to here's a bunch of examples of what good documentation good rfcs for us internally look like and then we give them tools like you know templates and things like that so it's like it's not an unstructured thing it's like hey you explain the problem first you explain the context.

1:50:37Then what's your proposal? What are the alternate ideas you explored? What's an adversarial view? You know, there's a template that walks you through the content I expect to be in this document. So it becomes over time, I won't say formulaic, but it's like, you know, you kind of, there's guardrails on what we expect the document to be. Last one from me. One funny observation that I heard from you is around airline loyalty. And that being actually a big unlock for you at a professional level. And I love this observation because it's actually something I've realized as well recently. And so I'd love for you, I can give my own version of events around it, but why being loyal to an airline has been professionally beneficial to you as an executive at a company?

1:51:22Yeah, I mean, it's a really funny one. You know, I used to have none, as you said. I used to just be like, whatever's the cheapest direct flight, whatever. Same way, I wouldn't even think twice about it. If it was Spirit Air, I would try to get the big seat, but I would, you know, that's it. Yeah, it's like whatever the flight is, I'll just take it. I think at some point when you start saying, I'm going to do a quarter million miles a year, you're spending a lot of quality time at airports. And so what I started to realize was like, okay, when you actually have status, it's not like the free peanuts matter, but it's like shit goes wrong when you travel that much.

1:51:55And the airlines have a very different experience for you when things do go wrong, right? And so it starts to be the little things like, hey, this flight got canceled for weather. okay you call united on their premier 1k line great we put you on the next flight out you're standing on their normal line you're on hold for the next four hours right and like by the time they get to the plane's already booked out right so those little things matter because when you do as many flights as we do it's like things go wrong you're like oh this meeting ran long i'm gonna miss that flight can you put me on the next one and they're like yeah no problem we'll just do that they waive the change fee they put you on it whatever so that matters and then it's like you know it becomes the little upgrades of like oh great they managed to get you a business class in this fight that just makes that experience of that much travel slightly less miserable.

1:52:35Yes. It's not like it's not miserable. It's still miserable, but it's less miserable, right? And you're like, okay, when you're doing that much of it, like that little bit of sanity makes a lot of difference. The quality of life improvement of going from, you know, backseat, middle, bathroom to premium economy, you know, window to business upgrade is like, it's some of the little joys of quality of life improvement that I think can keep you like sane in a world of tons of travel. And so I've actually found this to be the case as well. I've moved from the east side of New York to the west side of New York, and now I've had to switch my loyalty from JFK to Newark.

1:53:16And so I've gone Delta to United. But I've learned this exact experience and it took me a while to get there. I haven't done it with hotels yet. I don't know if you've done hotels. I'm only airlines right now but that's the next one it's the same one because the hotels don't have the same problem for me it's like because they're not you don't have the same variability of this flight got missed or whatever it's not as fickle it's like yeah and at the end of the day the the queen beds sleep generally the same uh no matter what if it's a beach view or whatever now beach view or whatever exactly the difference between a random hilton and a random marriott isn't that high it's not that big of a difference yeah yeah well armand thanks for doing this this is a lot of fun yeah Yeah.

1:53:55Thank you so much. This was great. I appreciate it.

1:54:00Thank you for joining this episode of the Logan Bartlett show with Armand Dagger, co-founder of HashiCorp. If you enjoyed this conversation, we'd love for you to share it with anyone else that you think might find it interesting as we're trying to continue to grow the listenership. Also, if you could subscribe on whatever podcast platform you're listening to this on, we'd really appreciate it. We'll see you here next week for another great episode of the Logan Bartlett show. Thanks everyone.