Armon: [00:00:00] I would probably recognize our first thousand users by face. If not many of them by name, people often ask me, what are the tricks to building community? Like what's the shortcut? And I'm like,
Logan: Welcome to Logan Bartlett show on this episode. What you're going to hear is a conversation I had with Armand Dagger, co founder of HashiCorp.
HashiCorp just announced a sale to IBM. Armand and I talk about that acquisition. Armand and I also talk about the journey of HashiCorp and a number of the unconventional things that they did along the way, including launching initially with six separate products. And how that led to HashiCorp's success.
We also talked about him and his co founder, Mishel Hashimoto's desire to not be the CEO, including them swapping back and forth on a monthly basis, before ultimately making the decision to bring in an outside CEO in Dave McJanet.
Armon: It was like you're a CEO. I'm CEO this month, I'm CEO next month. It worked about as well as you thought it would.
Logan: We also talk about their principles for scaling culture. Some of the things related to enterprise selling that were not intuitive.
Armon: I feel like I got multiple MBAs worth on this. So there's maybe two things, which is like, one is I'll share maybe the most surprising thing [00:01:00] and then two is like, how do you actually learn this stuff and sort of make it work?
Logan: And his observation that it is easier to get divorced from a spouse than it is to get separated from a board member. A really fun conversation that you'll hear with Armand now.
Armon: Thanks so much for hosting.
Logan: so maybe just to start, can you give a brief layman's definition to someone that probably isn't familiar with HashiCorp or your product suite, what it is that HashiCorp
Armon: This is the explain to my mom what we actually do.
Logan: right. Yeah. Which is always
Armon: Which is always difficult given how technical the company
Logan: Yeah. Your mom's probably familiar with it.
Maybe my mom. Uh, yeah. Less
Logan: familiar with it at this point. Yeah.
Armon: Yeah, um,
Armon: so the way I like to describe it to people is if you think about, so obviously there's this massive shift happening to public cloud, right? So people are moving out of data centers, they're going to Amazon, Google, Microsoft, etc. Our view is that if you take any large enterprise, right, think [00:02:00] banks, insurance companies, governments, et cetera, they're not going to be in one cloud.
They're too big for that. They do mergers and acquisitions. They have too big of an infrastructure. So fundamentally, they're going to be multi cloud, meaning they're going to have some workload in their own data center, some in Amazon, Google, Microsoft, Oracle, et cetera. So their challenge becomes, okay, how do I do that in a way that's going to be both efficient? And cost effective, right? Because I don't want to have five different ways of managing, one for my data center, one for Amazon, etc. I want one way that can support my whole multi cloud environment. That's effectively the layer we sit at. So we're kind of sitting at that point, enabling enterprises to adopt the cloud and do multi cloud in a consistent way.
Logan: So across all those different clouds, there's a suite of products and considerations, infrastructure, kind of middleware, if you will, that is, uh, repeatable processes that have been codified and turned into software by you all that allows this franca across all [00:03:00] all the different clouds, all the different services, anything you want to spin up, anything you want to do, all that.
Armon: Exactly, yeah. So it turns into a portfolio of about nine or ten products today, depending on how you want to count. So each of those, you know, portfolio products solve sort of a different point problem, but yeah, it's exactly that each of these is sort of a fundamentally a multi cloud problem. So you're going to have multiple tools, but the overall solution is looking at, hey, I'm a customer. I'm going multi cloud. What are all the different problems I have to solve?
Logan: Makes sense. So, uh, you've had a big recent week, I guess, with a notable acquisition. So first, congrats on that. Or an announced acquisition, I guess. It's expected to close end of this year, per
Armon: we're expecting them to close this year,
but, yeah, a bunch of, uh, you know, there's always the kind of classic
regulatory.
Logan: like Armon: in there. Logan: that stuff.
Tends to go longer and longer. I guess maybe take me through, uh, the emotions you feel this week. I assume there's some like validation, [00:04:00] some part of the journey's over in some way or different, it's going to be different than it was before. And so I imagine it's both validating and bittersweet
Logan: at the same time.
Is that fair?
Armon: Yeah, no, I would describe this week as a bit of like a whirlwind of emotions. It's exactly that. Honestly, in some ways it is bittersweet, you know, to your point. It's, you know, you spend 12 years building it. It's your baby. It's sort of the standalone thing that's kind of like, you know, yours in its entirety.
And that chapter comes to an end in some sense, right? You're joining a much bigger organization. But I think then the flip side of it is there's a ton of excitement, right? Obviously we wouldn't have done this if we didn't think it was a good outcome for the people and the products and the company. Uh, and so I think, you know, we feel very aligned with IBM senior leadership in terms of the mission.
And I think, you know, they're very excited about what we bring in the synergies to the portfolio. So to me, it's the, what's exciting is it's almost like, how do I take the HashiCorp mission? But put it on a platform that's a hundred times the size, right. With a hundred times the resourcing [00:05:00] and, you know, kind of get to see real, what was sort of only in my mind's eye, you know, even close, right.
There's still limitations we have in a resourcing and size and scale that, you know, don't apply when you're a hundred
Armon: times the
Logan: Totally. Totally. So,
Logan: so, so now going forward. Uh, so. What happens for the next six months or whatever it's going to be till closed? Business as usual. And you
Logan: just, Armon: yeah.
I mean, I think we're, we remain fully separate independent entities. So, you know, it's kind of business as usual for us, you know, build the same products, same mission, same priorities, focus on the customers. Um, and you know, very much kind of firewalled off. So there's a minimal integration team that can start doing some of the planning and integration sort of thinking. Uh, but effectively it all has to kind of wait until the deal is actually
Armon: closed.
Logan: Uh, Wednesday, did you,
Logan: when IBM announces their earnings, did you and Dave and whoever else get in front of the company and sort of explain everything? Was that
Logan: sort of the way it played out? Armon: Yeah. I mean we couldn't do
Armon: it Wednesday because of just time zones. It's like by [00:06:00] the time markets close and announces and I was already sort of late Eastern seaboard and we know we're pretty geographically distributed.
Logan: But you, do you have an email ready to go out? yeah.
Armon: email and blog posts and a bunch of those things went out right away to the internal audience.
And then it was Thursday morning. Okay. That that's when we can actually do a company all hands and departmental all hands and really like spend time with people to help them sort of digest all the news. But yeah, there was definitely a period and window in there where you're like the news is out and we can't, like we don't, can't get everybody together yet. Um, you know, but I think it's like pretty quickly the company has sort of understood what's the rationale and what are the sort of
Armon: synergies. Logan: on the
Logan: totality of the process and being acquired, is there anything that stands out that you feel like you all did? Uniquely well to set yourself up for a successful, uh, acquisition, anything that maybe you got to down the stretch and you're like, shit, I wish we built corp dev relationships with X, Y, [00:07:00] Z, or, or whatever it was like any, for any founders that might be, Most, I don't know, 99.
999 percent of companies end up being acquired at some point, right? So even if you go public, like the end state is probably being acquired, no matter what scale you get to in the fullness of time, there's a very finite number that stay independent forever, right? And so I'm curious, anything that you, you would reflect on that could be
Logan: helpful for people? Armon: You know, that's an
Armon: interesting one. Um, you know, I think there's an old adage which is the best companies are bought not sold. Yeah. Um, and so I think for us, the way we sort of never geared the company to be bought, right? And I talked to founders who like, they go in with that explicit intent. They're like, I'm not building a standalone business. Here's the three to five year plan and here's the target, you know, acquire. And I think, you know, there's nothing wrong necessarily with that. But I think it's like, it puts you at the disadvantage of like, you're making a bunch of tactical decisions. For a particular outcome that you don't control, right?
And so you're like, well, what happens if that doesn't [00:08:00] come to
pass? Are you, the timing is wrong or you know, whatever is the case, you, you could find yourself in a position that's sort of difficult because you optimize for that outcome
versus
Logan: I just have to think there's the business execution, operational sides of the puts and takes around that. But then just psychologically setting some, uh, uh, time period destination. It, when you miss that, it just has to be totally debilitating, like for
Logan: your ability to keep running the
Armon: Yeah. I would imagine. And I think for us, that's why we always sort of geared it as like we're building this company for the long run. And I think I often got the question of like, well, you know, if you guys, why did you even go public? Right. Right. Right. Because it's like, but that was the company we set out to build.
We set out to build a standalone business that was meant to stand on its own two feet, right? We weren't building a company to sell, right? It happened in the course of time that we found what we think is a great home and there was very logical synergy. So it makes a lot of sense, but it wasn't like we built the company for [00:09:00] that
outcome.
Armon: 7.
Logan: built a company for that outcome, but once upon a time there was a trade off and we'll get into the founding stories, or there was like forks in the road that you were thinking about, about like. Is this a research project, a lifestyle business, a venture backed business?
And so, at what point in the journey did you, uh, did this become within the realm of ambitions or possibility that 6. 2 billion? Was that the price?
Armon: 7 and then net of cash is 6.
Logan: 7. 7 sounds bigger. Yeah, we'll, we'll go with that. Uh, so, so 7. 7 billion, like at what point in the journey did that even enter the realm of possibility that something of that quantum could, could be like
Logan: doable?
Armon: Oh, man, uh, not for many, many years. I mean, so I think the honestly, this rewinds all the way back to the origin. So Mitchell actually started the company six months before I joined. And at that point, it really was a lifestyle business, right? Like Mitchell had started Vagrant and it had [00:10:00]existed prior to HashiCorp. So HashiCorp was really the Vagrant company in some sense, if you all the way back to 2012. And Mitchell had built sort of a consulting lifestyle business around Vagrant. And so the conversation between the two of us was like, well, what's the ambition here? If the ambition is. Vagrant, the lifestyle company.
I'm like, that's cool. That's a great, you know, business. You should have, you know, you Mitchell should have fun with that. But like, it wasn't super interesting to me as like, you know, what's the scale of that as a light, you know,
lifestyle investment. So the conversation really became, Hey, what if the mission became this much bigger thing?
What if we took on venture capital, you know, and shot for the moon? And that's when I was like, okay, that's interesting to me. And that's when I joined as a co founder.
So basically that was a rapid sequence of, I think I joined and we did our, you know, our first round was, you know, weeks after I joined
Logan: Oh, interesting.
Armon: Um, so I think we'd, we'd kind of had that conversation at the
beginning. You say like, what do you want this to be?
If you want it to be lifestyle, that's great. It's just not what I want to do.
Logan: Yeah. Uh, okay. Well, that's super helpful. Uh, I appreciate you going into all that. [00:11:00] Um, so one of the things, I mean, you guys did a bunch of different things that I think go against the grain of conventional wisdom within Silicon Valley, one of which, yeah, yeah, most of, I don't know, venture and outcome maybe, uh, that, that seems within the realm of Silicon Valley, but a lot of the operational stuff are with, uh, outside of it.
Uh, one of the most notable ones, I think, is, uh, I forget it. Maybe it's a YC adage or something about like singular focus and, you know, find product market fit. And, uh, and you guys, um, uh, did not have a singular focus, I think is, uh, is probably the, the, the way that I, I would describe it. And you had a suite of products.
Um, how did that actually come to be? So you referenced vagrant, that was the initial product, but how did you end up with, I don't know how many products by the end you had
Armon: Probably have like
Armon: nine today. Uh, our initial, if we want to call it the initial portfolio
within the first few years was like six products?
So it kind of went from six to eight to, you know, nine
Armon: or ten now.
Logan: And so [00:12:00] by the time you started selling, it was, it was that now, how did you, how did you get there? And maybe what was the process of taking each of those individually from
Logan: zero to one?
Armon: Yeah, so I think it was, you
Armon: know, I think there was a few important decisions along the way, right? The first for us was like, do you take a single product or multi product strategy? And obviously, conventional wisdom would say, you never do a multi
product strategy, especially as a small company. Now, I think for us, the thing that made this all work was that it's not multiple products with multiple buyers. What we had was a single buyer strategy. We said, hey, there's going to be a DevOps persona. That person is going to be responsible for cloud infrastructure, cloud management, doing all these things. So the question for us was like, what are all the problems that person has, right? And so rather than try and build one monolithic tool that solves all of their problems, we said, well, we're going to build individual tools, each one solves one problem that the same person has.
So what we're not doing is building a relationship with 20 different people in an org. We're going to get to the DevOps team, build a [00:13:00] trusted relationship, and say, hey, Vagrant solved your first problem, but Terraform solved your second problem, and Vault solved your third problem. And so it's by having sort of a singular channel, And then building multiple things where you're building trust and then you're layering product after product in that that's what creates some some efficiency to the model versus saying we're going to sell to 20 different people in an
Armon: org, right,
Logan: So the, the
Logan: decision of modularity there versus integration, like what was the thought process on that? Because of other companies have taken the, well, no, we're going to have a bunch of different products, but it's going to be tightly coupled as a suite. And you guys very much. Had, uh, it was more federated, right?
There was some workflow and tooling that tied it together, but you could very much buy or download each of the individual
Logan: products. So how'd you think about that?
Armon: So I think, you know, this goes back to some of the early thinking around a, it wasn't clear to us at the time, which of these products would be successful. And so really, if they're tightly coupled, it makes it hard to ever divest from them, right? So if you build it all in one platform, how do I kill a product if it turns out that thing doesn't have product fit? So it's [00:14:00] You know, it's hard to reflect on it now when these products sort of have fit, when you're sort of in that zero to one, you don't know what's going to stay at zero. So we felt like, hey, if we build this thing separately, we can see what has resonance, what doesn't. And in fact, if we look back, there's multiple products that we ended up killing. Because we built them, we're like, product market fit isn't right, people don't understand it, the workflow's wrong, and we killed those products. Like, Surf and Auto were early products that we built, didn't have fit, we killed them. So by keeping them separate, it allowed us to sort of experiment in a way that was a bit lower cost, right, so we could play with it. The second thing is it gave us multiple insertion points to a company. So we might go to an organization who says, Hey, we've really figured out secret management. We don't care about Vault. But hey, your Terraform thing, that's interesting,
right? Or vice versa. Versus if they were all integrated, it becomes this whole conversation of, Well, we need to bring in the whole platform.
Part of your platform overlaps with investments we already have. And so now it just becomes a much more complicated decision of like, Should we use your stuff at all? Versus if you say, Hey, great. I'm happy you have a Vault solution. Why don't you just use my Terraform solution? And
that worked really well because customers like,
okay, great.
And that thing can play nice with the [00:15:00] tools we already
have. And we're like, yeah, you know, we always took a very open ecosystem approach Our view was that over time, if we land you with Terraform, for example, we win a position of trust where you might say, actually, I don't really love our homegrown vault thing.
Maybe we'll take a look at yours. But that might be a year or two years after they adopted Terraform. But we now have a position of trust in a relationship versus if you had a whole platform. Platforms are notoriously difficult to sell. I mean, if you look at the history of startups, every generation, there's a graveyard of platform companies. Because they bring a ton of complexity, which means their operational burden is high, their adoption curve is very complicated, versus if you say, hey these point solutions solve a very specific pain point. And you don't need to boil the ocean to bring us in. It makes that adoption much,
Armon: much easier.
Logan: And so finding product market fit for each of these things individually, uh, and going from that zero to one. So, so was it you or Mitchell would have an observation? Hey, we had to do this. I assume other people have to do this. Let's, let's build some [00:16:00] commercialized version of this and throw it
Logan: out there and see what happens. Armon: Yeah,
Armon: I mean, I think so. A lot of it was informed by me and Mitchell being former practitioners, right? So we started, you know, it's funny, before I even joined, uh, as co founder, we literally sat down and sketched out the first six products, right? Broadly, what was the use case, the workflow, what problem were they going to solve?
How would they work architecturally? So roadmap on, you know, a few pieces of paper. That would cover the next three or four years of the company. Because we had spent years building these solutions ourselves, and then, it's not just in isolation, we talked to a bunch of our peers that, Hey, what's GitHub doing?
What's Slack doing? What's Stripe doing? You know, and so we had a sense of, we're all solving the same set of infrastructure problems, and we all kind of have converged to a common set of patterns. But we're all homegrowing the tooling. So we kind of had a sense of, okay, we know what the landscape looks like.
We've built these tools before. All of our colleagues in industry have built these tools before. But no one has built it sort of for the masses, if that makes sense. Like in a generic, reusable way,
they built it for their own homegrown need. So we basically sat down and said, let's just build these things in open source, with a very heavy focus on [00:17:00] rel.
So that's really where the product market fit, you know, mattered for us. It was actually not with the commercial products. For the first four years of the company, we actually didn't really have commercial products. We were just focused on open source adoption, open source growth. We obviously had some, you know, customers paying for support and things like that, but there really wasn't an enterprise version. It wasn't until 2016 that we had the first enterprise version of Vault and 2017 that we had the first enterprise version of Terraform that were truly, you know, pure commercial versions, right? Before that, it was just a community
Armon: focus.
Logan: I'd heard you
Logan: say that a number of the competitors in the market, and I realized there probably wasn't any singular competitor, and in some ways you competed with your open source projects as well, is probably your biggest competitor, but that they were maybe more dogmatic in their approach. And you guys.
Uh, prided yourselves on being pragmatic in your approach. Can you, can you contrast like what that actually means in practice and how it manifests itself in [00:18:00] product development?
Armon: I mean, this Is
a great one and honestly, this is one of the biggest pieces of advice that I give founders, which is, you gotta be obsessed about one thing, right? And so you gotta pick, are you obsessed about the problem you're solving, or are you obsessed about your solution? And there's a very important difference between those two things, right? Because what happens with a lot of people is they obsess about their solution. They think, This is the right way to solve the problem. I'm smarter than my customers. They just don't have, they haven't seen the light yet, right? In terms of this is the right way to do it. And the problem with that sort of dogma is, you know, most enterprises aren't starting from a position of blank greenfield, right?
They have existing investments, they have brownfield, they have a mess of existing legacy technology. And so if you come to them with something that's
super opinionated and you're rather inflexible and rigid about that, Then it makes their adoption often impossible because they're like, well, do I really want to change the way the entire enterprise works to bring your tool in? Like, no, right? [00:19:00] I need your tool to sort of fit into what I'm doing. So I think what we tried to be, and you know, we talk about pragmatism as both being one of our principles, but also our TAO, right? So our design philosophy of our products as well. Because our view is we should have an opinion. But it should be loosely held. So all of our tools has an opinion that says, Hey, we think this is the right way infrastructure should be managed. But that's okay if you don't agree or doesn't fit in your environment. We're building flexibility into the design of the product to sort of accommodate other opinions, if you will,
Armon: right? Logan: there
Logan: a way that that manifested itself a tangible example of something that maybe You thought from a principled perspective was the way things could be done. And you just found out in the market, the customers told you like, Hey, not quite, and you had to iterate
Logan: on it. Armon: Yes, I'll
Armon: give a very concrete example of this, right? So if you kind of rewind, you think when we started was like 2013, really. That was sort of the heyday of configuration management, right? So think Chef, Puppet, CFEngine, Ansible, right? They were all sort of reigning supreme. And I think there was this [00:20:00] model in people's minds of the way we should manage infrastructure is a sort of very long running, you know, VMs that you run tools like Chef and Puppet on continuously to patch them, update them, etc. This is sort of a, sort of a classic model of how infrastructure was managed historically. Our view was, You know, this doesn't actually make sense in the cloud world because it's super cheap to, you know, create and destroy VMs all the time. So why bother running things for months or years at a time? Like, use it for a day, a week, a month, and then kill it and create something new, right?
It's costless to do in the cloud. So we have this vision, this philosophy of what we call sort of immutable approaches to management, right? You know, the immutability being, I don't upgrade a server, I just destroy it and I create a new
one, basically, right? This was a pretty radical approach for most IT management, right?
Most IT orgs are used to things running for years at a time. They have patch management practices, et cetera. So when we built Terraform, we held this opinion, and we built Terraform around it. So Terraform's very much modeled around the idea of immutable infrastructure, [00:21:00] right? When you make a change to your server, Terraform's gonna destroy your server and create a new one for you, right?
It's baked into how it works. As we came to our customers, we realized they're like, Yeah, that's a great idea, but we have all of these applications that can't tolerate that. They weren't designed with immutability in mind, that you're gonna cause data loss, you're gonna cause outages for us. So that opinion, while great and while interesting, doesn't work. And so we sort of said, okay, great, well, how do you accommodate that? Well, we're gonna go do tight integrations with Chef and Puppet and Ansible and Salt and bring in those solutions and say, okay, great. Use Terraform in conjunction with those things. So if you have, you know, traditional, more traditional infrastructure, great, Terraform can provision it and then you can do these long running orchestrations for the long running VMs. Using those tools as you modernize and go to immutable practices, great Terraform will meet you right there as well, right? And so we can kind of take customers on this journey from, hey, you have a traditional approach to sort of a more modern approach. And it took many years for some of our customers to sort of see the benefits of that. But now we work with huge banks who are like, yeah, you've actually solved what used to be one of our biggest pain points on [00:22:00] patching where it used to be. thousands of people patching every month to now it's fully automated and we can nuke and pave our whole infrastructure every 30 days. So, but that's the reality.
It took 5 years to take these customers on a journey, Logan: Yes, so, so, so layman's
Logan: version of that is you saw the path of progress and where things were going and your solutions serve that. But instead of being dogmatic about, hey, take it or leave it. We don't want to that. That could be considered a competitor because it's a different way of doing something to a similar outcome.
Let us partner with what ostensibly could be a competitor. Let them do that. And we're going to capture the. The net new way of doing things that we think will be faster growing and future
Logan: proof in the coming years. Armon: yeah, and
Armon: rather than even, we don't even think about it as a competitor, we said it's just a complementary model of infrastructure management. How do we bring these things together and say, okay, even if you're in sort of the old world, it doesn't mean you shouldn't be able to use the new tooling. So let's just integrate these things together and make them play nice so that you can just say, great, both of these [00:23:00] can coexist.
Because the reality of a complex enterprises. It's never one or the other, it's both.
Logan: Yes. So, so, so
Logan: maybe, maybe competitor is the wrong term, but a something that was trying to solve a similar, uh, outcome in a potentially very different way. And so partnering with, uh, with them rather than just being dogmatic about, no, you have to do it our way rather than,
Armon: Exactly.
Armon: Yeah, because the reality of these enterprises, you know, I joke, if you look at an enterprise, I think about them like a tree. And what I mean by that, it's like if you saw down like a big bank, they have every ring of technology still at play.
Nothing has ever gone away. At the very middle, you still have mainframes, you have bare metal.
Logan: Amex credit card still runs the North Carolina mainframes, I think today.
Armon: So it's like, I think people have this view of like new tech comes out, enterprise, Adopts it and transforms their whole business. You're like, it doesn't work like that at all. It's just yet another ring
in
Logan: a layer cake that keeps building
Armon: Yeah. You're going to have your Kubernetes thing, talking to your
VM, talking to a mainframe, right?
Like every layer of it is still at play.
Logan: So, so, so the six products you guys
Logan: initially [00:24:00] launched with, uh, they, in, in hearing you tell the story, it was, uh, not an overnight success for any of them, I guess. Uh, can you talk through, I, I've heard you say that maybe there's three different journeys in like the product evolution that you went through and, and maybe in the first year of all of them, it was like, Hundreds of downloads and most of them might have been, uh, you and Mitchell, but can you talk through like the, the confidence in just, uh, iterating maybe on the product and just staying the course without the data points and then what were
Logan: the next steps in the journey? Armon: So this is the
Armon: hardest thing I think about the whole thing. And founders ask me this all the time, right? Which is if I look at all of our products, except for vault, and we'll talk about vault. They all went through this sort of, I'll call it, period of despair. Which is like, in our mind's eye, we're like, we think it's a great product.
We think they solve, you know, a great, you know, hard workflow problem in an [00:25:00] elegant way. So we build these things in open source, you put them out there, and almost invariably, with all of the products, what you see is almost a flat line of adoption for the first year, or sometimes two years. Where, you know, a tiny bit of download, maybe a tiny bit of GitHub interest. But relatively sparse. Right, you wouldn't look at these things and say runaway freight trains of success, right? And, you know, part of the challenge to us was always like, how do you get conviction that you're right or you're wrong, right? Because they look very similar from the data
Armon: for the first two years.
Logan: And probably wrong, uh, at least based on the numbers initially, right?
Armon: yeah, no, yeah exactly,
Armon: it looks wrong, right? You look and you're like, well nobody cares,
clearly.
No GitHub downloads, no traffic, etc. So, you know, I think it's a few things for us. One of the things that becomes really clear is, It's important to understand like, what's the reaction by, I'll call it, you know, the, you know, for lack of a better term, the smart
kids, right?
And so we had good relationships with a lot of these folks who are on sort of the bleeding edge of defining how [00:26:00] cloud infrastructure should be managed. And 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. 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 it 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 [00:27:00] 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?
Logan: 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 feature gaps. Did you pick some point in the future to like check in and I'm sure incrementally along the way you're like checking the downloads and all that stuff, but just psychologically so that you, you're, you're keeping your own sanity.
How did [00:28:00] you go about picking a point in 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
Logan: time. Armon: Yeah. I mean, I
Armon: honestly wasn't that long. I'd say with both of the products we ended up shuttering, it was about six months. So we give 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, we'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's about six months after we launched it, me and Mitchell sat down and we're like, we think we got the abstractions wrong, right? 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 that the problem is real. Everyone kept articulating, hey, how do we think about network automation? How should we handle? You know, 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're like, okay, what are we [00:29:00] 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's 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, we loved the solution. In fact, Surf is still one of my favorite pieces of technology. Mm hmm. But it was the wrong solution for that problem.
Armon: Yeah.
Logan: 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, dev rel, all of that. Cause I assume you pick, you felt like this was the path of progress one way or the other. And so in, in, in getting there, which one do you attribute more of the success
Logan: [00:30:00] to?
Armon: Oh man,
Armon: um, those are almost intractably linked. Um,
Logan: I assume that the dev rel is feeding into the product development and all that.
Armon: 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. Right? 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, Logan: Yeah. Yeah.
Armon: 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
Armon: years.
Logan: Was the North
Logan: star or the, the ICP, as you were thinking about it, [00:31:00] 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. Or were you also trying to get in front of the, not the disparage JP Morgan and bank of America, and I don't know, LVMH and other big enterprises as well.
And trying to cross
Logan: validate the two. Sure.
Armon: 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 100 people where the bank has 10, 000 developers. So to me, it was super important to get to those people. In fact, some of our most valuable design partners were those, you know, the cool kids inside of these big enterprises, the Ebays, the PayPal, 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 want to [00:32:00] 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 cute.
You know, 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,
Logan: Hmm.
Logan: I, I, I heard you say that you actually knew your first thousand 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 a thousand by name and, uh, how, how did you do that? Staying close to them, I guess. One, is that a factually true statement or sort of a allegory for, for how you went about thinking about staying close to it?
Logan: Sure.
Armon: not many of them by name, because some of them have come to, you know, events [00:33:00] like HashiConf, you know, eight, nine times. Um, so no, it's very much factual. I think people often ask me, what are the, 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, you know, 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, right?
Like, just pounding the pavement, right? Because when you think about, like, getting to those cool kids, building trust and getting them to say, Hey, I'm gonna bet my company's infrastructure on a product you released three months ago that barely works, right? That'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? Like, because this isn't like, oops, it failed. You know, it's like, it's your core infrastructure, right? So it required very high levels of trust and conviction, and I think oftentimes, you know, a deep personal relationship with some of [00:34:00] 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. And 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. Um, and so we worked through all the technical details, et cetera. 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 could give you one piece of [00:35:00] 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. But, 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, uh, 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.
There was really very impactful on how I think about, you know, how you engage with
Armon: customers. Logan: it
Logan: goes back to what, what are customers actually buying? And it's some combination of, of. The, the software, the service, the trust, the [00:36:00] confidence, all that stuff is, is, uh, intertwined in so many different ways.
Armon: exactly.
Armon: Yeah. Enterprise is so much of it is really about trust, right? Uh, 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 since so many, you know, miles, frankly, in a plane is it's like you got to shake their hand, look him in the eye and say, Hey, You know, your success is my success.
Logan: Did you staff against six different products at launch? Like what, 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
Armon: I mean,
Armon: it evolved a lot. I mean, in the early days, it was crazy. I mean, we had 15 people with 6 products. So, you didn't need a GM when you had 3 people on each product.
Logan: Yes. Yeah. Yeah. Hmm.
Armon: know, so I think, you know, from the early days, we were just, we were thin, but we were lean and mean team. And we worked really hard to like, how many libraries can we share, how much code can we reuse across [00:37:00] 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 organized, right? So we had, you know, product engineering, design, 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 the infrastructure line, 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. Then 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, [00:38:00] 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
Armon: that.
Logan: When you move to a GM model, how do you think about, um, the shared commonalities and services, uh, that you want to have across an organization, uh, versus the autonomy that you want to give that group to make decisions? How did you guys
Logan: kind of balance that? Armon: That's a super
Armon: tricky one. So 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. That's 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. And then we had a shared security team who was responsible for things like application security and compliance and all of those kind of things that are sort of shared [00:39:00] concerns.
Logan: How did you
Logan: end up with six, then nine and not three or 16 or 26 on the product set standpoint? What was the landing point there? I realized some were deprecated along the way, but how did
Logan: you sort of land on that
Armon: 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 life cycle of building and managing a cloud application,
Logan: software development
Armon: Cypher 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. Um, actually, ironically, we didn't start with Vault there. I'll come back to that one. We had, uh, we had Auto there and we had Surf. So we had these other pieces and we said, okay, let's go build the initial [00:40:00] portfolio of six. So, 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 division 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. So then they went away. So it really came back down to the six. That was the core portfolio. If I want to call 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, we built vault for secret management. But we have, what about human users? How do they get access to systems that created the opportunity for us to add a new product [00:41:00] 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 way point in 2020 as well to say, okay, this is kind of V two 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? So 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 our environment? And so, you know, some of that became more natural to do through M& A versus build.
Logan: The transition point
Logan: of going from, uh, hunting, if you will, to farming, uh, like the hunting being, uh, building, [00:42:00] shipping all these new different products, farming, being rounding them out, getting them to full feature, figuring out monetization and all that. Why and when did
Logan: you make that transition point? Armon: Yeah.
Armon: I mean, I think really we made the flip in, in sort of late 2015. So I think that was a milestone for us where we said, you know, when we raised money from the, from our investors, what we told them was basically, we're going to spend the first few years of the company fleshing out the portfolio, focusing on community adoption. And kind of getting to the, 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 we said we want to be able to draw the line end to end, and then we're going to focus on fleshing out commercialization, etc. So we basically promised our investors that's what we would do. And so first few years, that's, that's pretty much all we did. It was, you know, every few months we were launching a new product. We got to our first ever HashiConf, which is our big user conference. That's when we launched the last two products in the portfolio. Uh, and so that way we had to sort of completed the arc and I'll never forget literally the week [00:43:00] 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 about how she grew up the businesses now? Cause we know what HashiCorp the like open source projects are, but what's HashiCorp 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 HashiCorp the business look like as opposed to HashiCorp the set of, you know, open source projects that represent
Armon: the vision?
Logan: I heard, uh, that along the way fundraising, uh, maybe got far easier when Docker. Uh, came into existence and people were just like, okay, well, you're a derivative or a competitor of Docker along the way. And, and so I guess I 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, did it give you more time just to [00:44:00] focus on the open source and do this stuff? Or did you need to react to the commercialization because of Docker and what was
Logan: going on.
Armon: Yeah, totally. You know, it's
Armon: funny. It's funny how these things work out. Yeah, when we did our series A, that was probably the most difficult fundraise we ever did. Because
Logan: That was Mayfield.
Armon: that was Mayfield who led it. Yeah, uh, 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.
It was like every
Logan: And you were how old at the time? Armon: 22.
Logan: 22. Yeah. So
Armon: And they're like, and you guys, Yeah. exactly. Graduated three minutes ago. So.
Logan: Yeah.
Armon: think most investors looked at us like, you know, we had a third eye or something. Um, [00:45:00] so I think it was a super difficult fundraise because nobody cared about the 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. You know, we had a great partner, Robin Vasson, who led the deal, who was very connected to the developer community. And 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 his like the portfolio approach will actually be a strength over time because you're gonna build a trust and be able to layer multiple technologies.
So You know, I think he really saw why we were, had conviction about those things. Um, and he was close enough to the developers to sort of help make that bet. Uh, and so I think it was Mayfield and GGV who led the, the A and really sort of, uh, were bought into that vision. Now, I think as you get to the B, it's exactly what you said.
It was like, it became way easier because Docker exploded on the scene. [00:46:00] So all of a sudden, Docker had this organic, explosive vision. 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? Right. And so it's like this boring enterprise infrastructure company that was HashiCorp 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. 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, you know, how much of an impact
Armon: that made.
Logan: Well, and that was when we participated, right? That was in red point. Yeah. I came, came on board. So we're, we're appreciative of that yet. It's every successful company, I think maybe with one or two exceptions [00:47:00] has a very difficult fundraise. And it's, it's, it's a very humbling experience.
I. Think and I think every company, I don't wish it on anyone, but it does, uh, 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 sat 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
Logan: derivative ones.
Armon: Oh, absolutely. I mean, I think there's a bunch of interesting lessons and I, you know, I, with, with a bunch of the founders I work with, I share this, the advice with them, which I'm like, there's a, 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
Logan: Yes, that is very Logan: true.
Armon: [00:48:00] So I'm like,
Logan: legal recourse to get rid of, uh, divorcing and there's not with board
Armon: exactly.
Armon: So I'm like, you know, however much time you spent picking your spouse, think just as hard about picking your investors. So, you know, because I think a lot of founders are going to be like, well, I'm just going to pick whoever
writes the biggest check. And you're like, you don't know if that also means you picked the biggest asshole.
Logan: totally.
Armon: Right?
Logan: Or,
Logan: or what their standing is within their firm or, uh, you know, whatever, what, what their motivations are.
Armon: What expertise do they have? How
Logan: are they underwriting to and what false pressure or things are you going to get put on the business
Logan: because of that? Armon: So I'm like, rule
Armon: number one to me is like, make sure whoever you pick, you're happy working with them for another decade.
You know, because I now have board members like Glenn, who have sat on our board for more than a
decade, 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? So 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 [00:49:00] 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 outsize expectation does that set on our execution,
right? Because yeah, you can go to, you know, and 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?
Like now it's all or nothing. You gotta, you gotta go all in on, Logan: Mm.
Armon: 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 0 revenue company. Like, are you insane? Right. And I've seen that right where we're great companies and great teams. frankly [00:50:00] get stranded because their valuation is so sky high that there's no exit, right? 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. At the same time, I think that, that thing impacts like who you think about as, you know, being the
Armon: folks you want to work Logan: Yeah,
Logan: whenever I say this, it sounds very much self serving and like I'm talking my own book. So it's appreciated when, uh, when founders actually validate these, uh, these things as well. So thank you for that. Um, I guess it's hard to know the counterfactual on the product and the coupling in the, uh, integrating into the suite a little bit more.
Uh, you, you obviously don't know the road, not taken on it. Uh, I'd be curious on the, the very bundled side of the house. And we talked a little bit about this
earlier. Uh, 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 [00:51:00] shared workflows and services between the two. Where were you on that spectrum? And what were the. The, uh, I guess the, we've talked about some of the benefits, but what were the trade-offs or considerations that, uh, might be non-obvious that were negative in some
Logan: way?
Armon: Yeah,
Armon: you know, it's super interesting, you know, and it's like, I look back and I'm like, are the things I would do differently now? Probably, you know, probably, you know, with the hindsight, you always have that luxury. Um, I think some of the biggest tradeoffs is things like what is your development efficiency, right?
Obviously, we had to duplicate some work because, you know, I have more products rather than less, right? Two is you end up with more inconsistencies because you're like, well, this product did it slightly differently the way that product did it. But if they happen to be the same product, they'd be more consistent with each other. And then three becomes complexity on the user and customer side, which is, hey, we love Terraform, now we want to adopt Packer, but it's a different tool. Versus if it was just part of the same logical, you know, platform, right? So I think it creates some of that customer friction. So those are [00:52:00] 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, this, we have a new configuration language, for example. Today we use what we call HCL, it'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, you know, 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 [00:53:00] 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, life cycle management, and security life cycle management. So 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. They're going zero to one. We've gone through that. We did the iteration on product market that we know they have fit.
We know they have logical, you know, synergy with each other's. And we've done a bunch of these experiments. So now it makes sense. Cause you're just in a different place in the market, right? 10 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
Logan: mm.
Armon: So I think that's the other trade off is you kind of have to understand where are you in a market life [00:54:00] cycle, 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 gonna 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 MLOps 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. So you know you need payroll, you need benefits, you need performance reviews, whatever. So you start by building it as an [00:55:00] integrated platform. Because you know up front what all the requirements are. It's not a particularly dynamic market, right? 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, you 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
Logan: Interesting.
Armon: 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. Logan: One of the decisions
Logan: on the product side that you all made was giving independent names that were, uh, disassociated from HashiCorp. I 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
Logan: on that? Armon: So the
Armon: 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 [00:56:00] 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. And then together we can brainstorm what we actually want to name the actual company, right, rather than just my, you know, one man LLC. Uh, 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 want it to feel like mission oriented in a 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, [00:57:00] you know, symmetric, sharp edged, right? It was not a cutesy animal. And what we liked about HashiCorp is it sort of 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.
So it just
Logan: That's
Armon: So it was just one of these like happenstance coincidence Armon: type of things,
Logan: and then on the product side, it's interesting because in some ways, uh, I imagine, I, I've had this experience before where people won't know HashiCorp, but they will know Vault or Terraform or whatever.
Armon: all the
Logan: sure you've, you've lived that way more. And so, uh, I would say. Conventional wisdom to disassociate your company name from your product name.
Uh, it's certainly unusual. That is not what [00:58:00] I would say most Silicon Valley venture investors would recommend. So what, what were the considerations and the puts and takes on, on that?
Armon: Yeah, so
Armon: 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 HashiCorp was like the copyright and the footer in gray text was like copyright HashiCorp. Like it didn't even say HashiCorp 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 HashiCorp. And we're like, well, we make, you know, Vagrant, Packer, Terraform, Cross, 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
Logan: Yeah.[00:59:00]
Armon: And so we're like, okay, this is, we've created a problem for ourselves. So 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 a sort of a single color palette. We changed all the logos to make them much more, not the same, but to follow a 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 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 home page. So 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 still have people who are
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. You know, 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. [01:00:00] 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 1 in 50 that they don't know that it's all linked back to HashiCorp, but, you know, it took years.
Logan: So, so
Logan: maybe not something you would overly recommend. It made sense at the time. Is that a fair, uh, uh, distillation of all that? It's probably caused some more headache than, uh,
Armon: absolutely. 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 HashiCorp brand to begin with,
Logan: Makes sense.
Logan: Your market, uh, had some being open source and being your monetization model and all that. Uh, there's, 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, uh, I don't [01:01:00] know if that's the nomenclature you would use for it, but, uh, the number of people that were using one of the products versus paying for one of the products were wildly different.
And even if you're at an organization or you're an entrepreneur listening and, uh, It could just be your buyer is, uh, 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. Um, 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
Logan: who and Armon: yeah.
Armon: Yeah. I mean, I think this is what makes HashiCorp great. 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, right? Our user is developer downloaded our product on our website or get hub or whatever. They'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 [01:02:00] 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, VP of infrastructure. And then you can position to them the commercial value prop, which is, hey, your developers already love us. What if you standardize our technology and 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 as bottom up, but we have an outside enterprise sales team that drives those conversations at a director, [01:03:00] VP, C suite
Armon: level. Logan: I, I, I
Logan: assume from where the business started, uh, and at one point you were pursuing your PhD, right? Or you were going to go down a path of
Armon: That was the intent. Yeah, I didn't get very far.
Logan: didn't get very far along the way. I assume you didn't, uh, uh, grow up thinking you would have, um, 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
Logan: that. Armon: Oh man,
Armon: uh, I feel like I got multiple MBAs worth on this. Um, You know, I think there's, there's maybe two things, which is like, one is, I'll share maybe the most surprising thing. And then two is like, how do you actually learn this stuff and sort of make it work? Um, probably 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, eighties [01:04:00] power lunch with two martinis, you
know, you know, you're like, that's what I, my, 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. Yeah, exactly. And quadruple bypass, I'm sure. Um, because it's still done over steak 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 gonna 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. 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. [01:05:00] Right? And that's why that won't change. And, you know, I think, uh, 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. Right? 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
Armon: does that anymore.
Logan: Tactically, uh, 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, um, uh, lots of red meat helped along the way. But were there, were there things stylistically that you figured out?
Um, helped in building that trust beyond just FaceTime and being there in person and presumably being honest. Uh, but it sounds like maybe not overly honest, honest with a, with a, a touch of, you know, confidence
Logan: inspiring
Armon: Yeah. And, you know, I
Armon: think the, uh, the other interesting thing is. The, these markets are very predictable in terms [01:06:00] 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, so 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? [01:07:00] And so there is this sequencing of, you know, you have these early adopters, they set 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. They're going to kind of look to their peers. So that was the other interesting lesson is that it can't be pray 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, and sort of the sequence of who are the early
Armon: movers. Logan: The
Logan: 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. Some things are more, you know, software development, lifecycle oriented as well. And so did you [01:08:00] 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
Logan: the sales team?
Armon: So we went through a number
Armon: 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 or technical sales folks. Um, and that was really the early days.
Most of our focus was terraform and vault at that point, right? As 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 more distinct of a sales motion. 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 [01:09:00] core. And now we have a notion of what we call sort of generalist SEs versus specialist solution architects. So we have our solution architects that sort of specialize in different domains, infrastructure, security, et cetera, networking. Uh, and so that's kind of the way we sort of specialize it today.
Logan: We we've,
Logan: uh, shifting gears a little bit. We've, we've, we alluded to different points along the journey, but you and Mitchell were at the university of Washington to gather and best friends over the course of four years, he started working on you guys, right? Keep together. Then he started working on vagrant on the side.
Is that the
Armon: Vagrant actually started at Armon: University of Washington.
Yeah. Yeah. So Mitchell came to me with this idea. He was like, Hey, I wanna build this thing VA to simplify setting up my developer environment. And he was doing all this stuff to try and isolate the app. And I, I, I remember, 'cause it's like this was maybe 2007 or oh eight, um, and he didn't know about virtualization at the time.
And I was like, Hey, have you seen this tool, virtual box, 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, [01:10:00] oh, that's really cool. I'm gonna go like research it the next morning when I saw him, he's like, I rewrote all of Vagrant around virtual box, 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.
Logan: And
Logan: so that started then, and then, did he recruit you to Logan: keep, or?
Armon: 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, uh, at Berkeley. Um, 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. Um, you 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 [01:11:00] 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 it like, you have to make a decision. Are you coming back? And 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
Armon: thereafter to HashiCorp. Logan: So, so,
Logan: uh, you all spent, I mean, friends for, uh, what, now 17 years or something? Dating back 07, 08? Yeah.
Armon: exactly. Back to 07, yeah.
Logan: 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
Logan: working together?
Armon: I mean, it was two years at Keep, and then Mitchell left late last
year, so [01:12:00] 23, so call it 10 years at HashiCorp. Logan: Okay. What, in what
Logan: ways did you all complement each other? Were there clear overlap areas that, that, or was it kind of perfectly
Logan: symbiotic? Armon: you know, I
Armon: think we had both different strengths that we brought to the table, right? Um, you know, Mitchell was always a developer's developer. It still is. Um, 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.
Logan: I've heard he credits like his Apple retail store experience for some of
Armon: Yeah,
Logan: having worked there, I don't know, high school or college
Armon: Yeah, yeah. So he worked there during college. And I [01:13:00] think Apple's very religious about some of this stuff, is that notion of you surprise and delight. Um, 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, so 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 then 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, uh, 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, create a really compelling set of products. Um, and then as we kind of, as the company grew up, our roles sort of very much changed.
Mitchell stayed, I'd 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's like a 100X engineer. [01:14:00] 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. Um, 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.
Logan: Yeah. Uh, well to, to that end, so, so you all, uh, passed the CEO title back and forth. Uh, it seems like playing hot potato for a little bit on who is CEO and then you decided to be co CEOs and then. Uh, at some point along the way, maybe, maybe the totality of the journey, were, 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, uh, CEO or was that an evolution of playing hot potato
Logan: back and
Armon: A, no, it was
Armon: definitely an evolution, right? So for the first, For the first year or two, we were so small that like, CEO was a nominal title. At some point, once the team got to like, 10, 15 people, you need full time management, right? It just can't be [01:15:00] chaos if everyone does whatever they want. So at that point, it was when we were sort of hot potatoing it back and forth.
And then, you know, at some point me and Mitchell had a conversation where we're like, okay, like 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.
Logan: And prior to that, you guys were like switching every quarter or Armon: Every month. It was like, you're CEO this month, I'm CEO next
month. It worked about as well as you thought it
Logan: Yeah, that sounds, uh, sounds like a very, uh, yeah, something that I would not recommend
Logan: to people.
Armon: You know, there's a reason it's
Armon: not a widespread pattern.
Logan: Yeah,
Armon: Um, 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 starting that soul search, right?
The board started to push us and say, [01:16:00] what's how she wrote 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? And 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, you know, 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, you know, we struggled with a bunch of commercialization models, right? Cause open source is not a well understood model.
So we went through a bunch of different things, ultimately land on and sort of an open core model, which has been sort of the predominant way we've monetized up until we introduced cloud services. But then the third question for us was like, well, who leads this company? Cause 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. 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 engaged with the board to say, Hey, we think we need help on a leadership [01:17:00] 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 we brought in an exec search firm, uh, and that's what we told them, 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, what, like, what are you, like,
Armon: these are different
Logan: We need a grownup
Logan: that knows enterprise an
Logan: that's a hard spec to hunt for.
Armon: So, to their credit, you know, they didn't tell us we were total idiots to our face. they thought that. Uh, 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, uh, for a number of reasons it didn't work out, right?
Armon: So we basically said, okay, back to the drawing board. And then having spent a little bit more time, we're like, [01:18:00] okay, we're being a little bit unreasonable. What we really need is actually two very different people. We 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.
Armon: And 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? Uh, and we'd had a chance to meet Dave, you know, previously when he was joining GitHub.
Logan: And that was [01:19:00]
Logan: a part of the marketing search, although he wasn't, he wanted something bigger at that point in
Logan: time. Is that
Armon: Well, Dave was at the time, he
Armon: had gone to be CMO at GitHub. So 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. Um, 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 HashiCorp 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.
Logan: In seeding that
Logan: role, the responsibility, the [01:20:00] 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 going to give it to someone else to come in. Or was that not something you were
Logan: thinking
Armon: So I would say it was a, it was, a struggle, but not for maybe the, not for that ego 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? Like, what's more important to us, right? Like, 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 like, we didn't care about the title. [01:21:00] And it's like, you know, and in fact, the CEO job is a terrible job.
Armon: I don't, I don't wish it on anyone. Um, so, you know, both of us were like, we're more than fine being CTO or, you know, VPN 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 the Dave decision. You know, it was you're giving control away of your baby, 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 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. Getting 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, right? Like, what if Dave's not a good fit? What if there's a cultural clash? What if we don't agree on strategy?
Right. 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 [01:22:00] 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 gonna 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 is like what got us over the hump.
Because we felt great about Dave. We were like, we think he's the right guy, but like, but what if?
Like, What?
if it doesn't work? And what happens? Um, and so it kind of got us over the hump. We ended up making that call and bringing Dave in. Honestly,
Armon: I look back as it was probably one of our best decisions.
Logan: So it was a year long kind of vetting process for someone
Armon: Depends how you, are you measuring from the first time with the exact Armon: search or the
Logan: Yeah, well I guess when you
Logan: were most amenable to a CEO coming in,
Armon: Yeah, that process was [01:23:00] probably Yeah, six, six to eight Armon: months, probably.
Logan: was there anything
Logan: beyond just time? Uh, that Got you comfortable with the person specifically in Dave or like what was the actual vetting
Logan: process? Armon: Yeah,
Armon: I mean, the early dates, I used dates because that's how it felt like you felt like you were 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?
Um, what?
Logan: Drive in movie
Armon: 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.
Right. So, you know, it, it did have that vibe. Um, 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, this is a product strategy question. Or [01:24:00] how should, how should we think about marketing this? Or what's the right positioning for some of these things? And 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 worked together to understand what's our true working style on 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 and those were honestly more valuable frankly than you know, the dinners,
Logan: Interesting. I,
Logan: I, I heard on Dave's side, at least he kept asking you all the same questions over and over again. Uh, and it wasn't because he forgot what you had said previously, actually quite the opposite. He was, he was trying to validate that you all [01:25:00] Actually soft 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 uh, cause it's obviously a mutual sale
Logan: that's going on, but Armon: yeah.
I mean, I think
Armon: so I think Dave was colored by some of his experiences here that other companies and maybe you know Most recently coming off of that 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? 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 going to 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 [01:26:00] conflicts on some of these things, can we resolve them in a reasonable way?
Or are we like, no, every hill is a hill we're going to die on, right? And you know, get a sense for us of like, okay, is it, 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? 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. Um, and so I think that's what he wanted to pressure test was like, Hey, if we bring in salespeople and they start to change the culture, cause 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
Armon: things?
Logan: I, uh, can you maybe take me through your personal journey once Dave came in? Like what, what did, what did he do? You go [01:27:00] do then after that. And what did Mitchell go do then
Logan: after that?
Armon: Yeah, so I think what started to evolve is like, Dave's focus very much became Go build the go to market motion. Because when he came in, it was ground floor, basically. Like, effectively, call it no marketing, no sales. I mean, we had one or two salespeople. We had some marketing that we kind of put together, but it was nothing polished or, you know, 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. You know, build out the marketing function, start to build out the sales function.
You know, we had Rob Abbott at the time who joined the sales. So he was, you know, hiring and building out a sales motion. So they were really focused on that side. And they kind of deferred to me and Mitchell to say, you guys go figure out the product strategy. But we worked very closely with them on thinking about how do you monetize open source?
What's the, you know, enterprisative capabilities we should be thinking about building? But he sort of deferred the roadmap, the execution on the actual product side to us. And then between me and Mitchell, [01:28:00] 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. Great, go put Mitchell on this thing. It's a strategic high priority project for this. He's going to go help build it. Versus 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.
Logan: There there's this adage I hear from experienced CEOs, operators like yourself, that they definitely regretted hiring too late for certain roles. I've heard you, uh, allude to this at different points. Um, 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
Logan: specific seat? Armon: Oh
Armon: man, it's so
Armon: [01:29:00] hard. It's such a hard question. Um, 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. Um, that was my general experience of it. I think the other thing that's really helpful has been finding mentors. seen the movie before. That was, I think, the thing we really didn't have prior to like 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 ahead 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.
They 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. [01:30:00] 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 finance and HR and success and sales, et cetera, 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 Mitchell 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
Armon: obvious. Logan: One astute
Logan: observation that, uh, I guess I, I, I practice it implicitly with companies I'm on the board of, but I'd never heard it articulated as crisply as, as you had, is that the leaders that you found to be most successful in their specific roles were the ones that could also. So. Uh, forward plan or project their org charts and be able to talk about how everything fit together.
Can, can you elaborate on that point and Logan: why that's the case?[01:31:00] Armon: Yeah, I mean, I think what's
Armon: so hard is if you haven't seen the movie, there is these break points in scale, right? The thing that makes sense zero to 50 is different than 50 to 100, different than 100 000, so on and so forth. And 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 a hundred, but I'm designing for 500, right? And 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 timeline.
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 [01:32:00] time. Right, because otherwise everything's constantly in a broken state.
Logan: Did you, did you find people that hadn't been there, done that, that were able to still be cognizant enough about. About that in their scaling journey as well. Or was that a requisite of people
Logan: that had had the experience? Armon: I'd say we had a
Armon: bunch of people that successfully scaled through a lot of the phases. So actually, like a great guy, John Benson, uh, he joined as our first SE. So he was an individual contributor, having never worked in DevOps or infrastructure or cloud. Um, 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 S. E. team. Then he ran sort of the worldwide S. E. team. Eventually, you know, 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, you ran a team of 250 globally, right?
So I think there was individuals like him. We also had another, you know, Kevin Fishner, similar kind of a story, moved through many different roles, became [01:33:00] 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. Um, 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. Um, 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?
People 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 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, uh, and then ultimately helped John scale. And then when John was like, Hey, I've been through this ride for, you know, you know, almost 10 years through IPO, I [01:34:00] want to sort of go take a break. Peter 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.
Logan: In terms of
Logan: hiring people into the organization, I heard you say that you over indexed on culture fit. Uh, what does it actually mean? It's that, that could be a platitude that a lot of companies could say, like we were very proud of our culture, but I get the feeling that. You all, uh, in particular sought out people that fit in with your culture.
And so I'm curious how you go about operationalizing, um, trying to discover if culture fit exists in an interview
Logan: process. Hmm.
Armon: Maybe it was the, it might have been the chief people officer at Netflix once said this, which was, I think, 70 percent of culture is who you hire, 20 [01:35:00] percent of culture is who you promote, 10 percent 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, like 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, you know, 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, as a vendor, they would give us their book of corporate principles and they had like 300 of them or something. And 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. Um, and so we looked at that and we looked at a lot of the sort of culture driven companies that we admired. And we [01:36:00] 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 on the internet. It 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? So 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 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?
Could they talk about it in a product context, right? [01:37:00] 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? You 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
Armon: police, Logan: Yeah.
Logan: Well, and that's one of the things like once. Uh, I wrote culture police here, uh, which I guess maybe I stole from you somewhere, but uh, once you hire someone in, um, it's, they, they pass 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.[01:38:00]
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 bad person. So I'm curious on, uh, on like how you actually, you know, managed to
Logan: put that in practice. Armon: So
I think it was two
Armon: things. Um, in the early days, it hasn't really changed It's like me and Mitchell were always very accessible even now, you know, new new folks will slack me or whatever all the time So I think we always kept a very open door policy, made it very clear that, Hey, me and Mitchell are super accessible.
If people have concerns and 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. Um, you know, as you get bigger, it's kind of, people are less likely to [01:39:00] ping me a Mitchell directly. So early days the way it would happen is like people knew that me and Mitchell cared deeply about the culture.
And so when they would see that cause they're on a team and a new manager came in or whatever, People would slack us. It's like it wasn't people weren't shy. They'd be like, hey, can we chat? Like, you know, I have some concerns about so and so's leadership style or whatever, right? And I would take those meetings and I would take them very seriously.
Like 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 like, you know, there's fire there. Uh, and so
there was, you know, oftentimes those would then lead to action. Like, 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, you know, have a plan and move them out. As it got bigger, that gets harder. Obviously, 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 can, when you run this heat map and you're [01:40:00] like, Hey, what are their scores from their team? When it's like, you know, when it's orange red, you know, 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. Is it just. You know, interpersonal thing, team, whatever. And oftentimes what you find is when the heat map is red, there's something
Logan: Yes, you
Logan: can manage up and hide a lot of things. It's really hard. Your direct
reports are pretty good leading indicators
Logan: of what's actually going on in the business.
Armon: Exactly. So it's like when those things go red, you're like, okay, we, those are serious indicators to us.
Logan: So we talked about the number of principles
Logan: and the stuff you guys valued culturally. I enjoy obscure shoutouts 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[01:41:00]
influenced you all around integrity, maybe one of the principles.
Can you maybe talk about, uh, just to give an obscure shout out to people that, you know, long since lost to history, I think Basho is at this point, but, uh, what they did that you admired and how it became a part of some of the principles of
Logan: HashiCorp. Armon: no,
Armon: that's a, you've done your homework. That's a great reference. Um, so Basho was a company that we had used their products at Keep when me and Mitchell worked there.
Logan: It was a Washington based Logan: kind of
Armon: San Francisco,
Logan: Oh, it was San Francisco. Okay. Armon: based sort of
Armon: distributed database
Logan: Database. Yeah.
Armon: And, uh,
Logan: cool and influential. I'll be at not like majorly successful. Logan: I
Armon: yeah, I think that's a good way of putting
Armon: it. Um, yeah, very, There was a, there was a hardcore, you know,
distributed systems group that would nerd out about it, but it,
was a, it was a niche group. Um, and so we became, you know, friends with them, we were users and, and sort of, uh, of their technology. And one of the things, you know, there's many things we admired, but I think one of the things that [01:42:00] 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 was a million of them. And most of these database companies, it's like you go to their homepage marketing and it was like they're
lying through their teeth, right? It's sort of like infinite scale, unlimited transactions, blah, 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, here'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 loved that about that, and then their focus on [01:43:00] the technical operations making it a really elegant software in terms of how do you run this in a simple way, how 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. You know, how do I make this simple for my operators who have to do this stuff? So we loved that side of it. Their, their passion for the operations teams and how you make this stuff easy to run, their honesty, their openness about, you know, technical architecture, their approach to community sort of engagement. So all of those things were things we admired and were very much things we tried to incorporate. Uh, and you know, for us, for many years, you know, 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. Right? And so we would encourage our contributors, our competitors, often if we were wrong, Hey, send us a pull request on GitHub, fix any factual inaccuracies we have. Right? And they often did, and we would accept their changes, and we were trying to say, Hey, here's our strengths, here's how, why our philosophy is different, here's how we've benchmarked [01:44:00] it, you know, here's how it stack ranks, you know, strengths and weaknesses. Right? And we tried to be very, very honest about those things. And that very much came from, uh, the work we did with
Armon: Basho.
Logan: HashiCorp. Uh, can you explain to people what it is and how it, uh, came to be and
Logan: what it's done in principle? Armon: Yeah,
Armon: so the town of HashiCorp, sort of the companion to the principles. So if the principles are sort of how does the company operate and the people operate, The TAO is how do the products operate?
Logan: The external versus the
Armon: Exactly, and so for us when we started to build all these different tools in the portfolio even though there are different tools solving different Problems we had a common world view is maybe the way to put it It's like hey, we think infrastructure should be managed like this So you could almost think about our TAO 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, uh, 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[01:45:00] the TAO and published those so customers would know, hey, here's the design philosophy that we sort of follow. But 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, You know, integrating with whatever technology the customers need us
to, et cetera. So it became this sort of twofold internal guide as well as an external. How should you think about the HashiCorp ethos? Basically.
Logan: it stayed consistent?
Armon: Amazingly, we haven't changed Armon: a thing on it
and I'm not sure I would change a
Logan: well,
Armon: Right. So,
Logan: How did you go about actually coming up with the inputs into it
then?
Armon: you know, it's a,
Armon: 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 that 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. You know, I interned at Amazon for a little while. So we looked at some of their leadership principles as well and took some of [01:46:00] those. And 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. So 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.
Logan: One of the things
Logan: I heard you, uh, uh, specifically worked on as a leader, manager, operator, uh, was communication. And I think it was both written and verbal, but I, I don't know. I guess one, why do you think communication is important, uh, for leaders in, uh, I guess, I mean, Maybe some of the non obvious things [01:47:00] around that.
And then how do you actually go about working Logan: on being better at it?
Armon: Yeah, that's a
Armon: 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, or 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 [01:48:00] thinks the third thing. And so every part of the company is executing a dance, a different strategy.
Fundamentally, you can tell, right? The 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 bi directional, 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 gonna build Surf, we think it's a great product, let's go pitch it to customers. We go in product, or in market, and customers are 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? So 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 [01:49:00] 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 percent 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? Right? 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.
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.
Microsoft Mechanics 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 [01:50:00] decision, a context, a set of ideas, like, I don't need incredible pros 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 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, then 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, yeah, you know, you kind of, there's guardrails on what we expect the document to be.
Logan: Last one for me. Uh, one funny observation that I heard from you is around airline loyalty and that being actually a big unlock for you at a [01:51:00] professional level. And I love this observation because it's actually something I've realized as well recently. Uh, and so I'd love for you, I can give my own version of events around it, but.
Why, uh, being loyal to an airline has been professionally beneficial to you as a, uh, as an executive, uh,
Logan: at a company?
Armon: Yeah, I mean, it's a, it's a really funny one.
Armon: Um, you know, I used to have none, as you said, I used to just be like, whatever's the cheapest direct flight, whatever. I'm
Logan: Same way.
Logan: I wouldn't even think twice about it. If it was Spirit Air, I would
try to get the big seat, but I would, uh,
Logan: you know, that's
Armon: Yeah. It's like, whatever the flight is, I'll
Armon: 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. And 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 [01:52:00] 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 you, 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 on this flight. That just makes that experience of that much travel slightly less miserable.
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
Armon: lot of difference,
Logan: The quality of life improvement,
Logan: uh, of going from, you know, backseat, middle bathroom, uh, to premium economy, uh, you know, window to business upgrade is like, it's, it's some of the little, uh, joys of quality of life improvement that I think can keep [01:53:00] 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, uh, JFK to Newark. And so I've gone Delta to, to United, uh, but. I, uh, 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 Logan: the next
Armon: 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
Armon: fickle. And yeah. you're like,
Logan: 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, no beach view or whatever, a city view or
Armon: difference between a random Hilton and a random Marriott isn't that
Logan: It's
Logan: not that big of a difference. Yeah. Yeah. Well, Arman, thanks for doing this. This is a lot of
Armon: Yeah. Thank you so much. This was great. Appreciate it.
Logan: Thank you for joining this episode
Logan: of the Logan [01:54:00] 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 Logan: show. Thanks everyone.