Good morning, everyone. Welcome to TiEcon, day one. I have the great pleasure of having Armon with me today, Co-founder and CTO of HashiCorp which went public in December of last year with over 15 billion in market cap. Armon, I want to start by thanking you for being here with us today.
Thanks so much for having me in, Navin. It’s a great pleasure to be here, and get to speak at TiEcon, with everyone.
Absolutely. So, let’s start by what HashiCorp does for the audience.
Sure. Yeah. To keep it relatively simple, we started HashiCorp almost 10 years ago with a pretty simple idea, which was how do we make it easy for development teams and application teams to build their next generation set of applications in the cloud? It sounds like a simple problem, but of course there’s a lot of challenges around how you provision and manage the underlying cloud infrastructure. How do you secure all of those assets and secrets and data? How do we tackle the networking challenges across all of those different multi-cloud environments, and how do we manage the application life cycle? So, as a company, we focus on four layers, but it’s a very simple goal, which is enabling application teams to efficiently deliver applications in a cloud environment.
Great. And it’s been a delight working with you throughout this journey. It would be helpful for the audience if you could talk about your background, and how that led to you founding the company. It’s always helpful for TiE entrepreneurs to know what the real story behind an entrepreneur is, and what leads them to starting a company.
Yeah. Happy to share. So, it actually goes back all the way to the time that me and Mitchell Hashimoto, my co-founder, spent at University of Washington together. So, both of us were there studying computer science when we first got a chance to meet each other. And that was actually in the context of an academic research project. So, we met doing research at the University of Washington. And then we started cutting our teeth on some of these problems around how do you build applications in the cloud? How do we manage things at scale? Very much in the academic environment.
But then, as we went on to do internships, and then graduated college, and went to work in industry at small startups in the San Francisco Bay Area, we ended up realizing that all of those problems around cloud infrastructure and application management were unsolved.
And so we kept asking and thinking to ourselves, eventually someone’s going to solve these problems. And at some point it felt like six, seven years into cloud, nobody had really done it. And so, we looked to ourselves and said, you know what, we’re practitioners, we’re the developers ourselves, we’re the engineers using these tools. And so, we’re our own customer. So we said, can we start HashiCorp, and really be our own first customer, and really build the tools, build the products that we would want to use, to solve these problems? Because we know the problems very well. We’re the end user ourselves.
And so, that ended up being the push for us. And it really came from just talking to a bunch of our startup peers, and bigger company peers, and everyone saying, “Hey, there’s not a good answer to this.” You know, and we built the same set of tooling three, four times that we said, you know what, let’s do it once and for all. And that really is what started HashiCorp.
That’s great. So, were you an accidental entrepreneur with your co-founder, Mitch? Or was entrepreneurism always running in your blood, and there was this desire always to start a company, and have impact on the world?
No, I’d say we were both probably more in the accidental camp. I think we were open to it. And in university we ended up starting a little startup group, where we got a team of five people together, and we brainstormed various ideas. I think we really wanted to find ways to innovate, and participate, in the startup ecosystem. But I think we didn’t start a company saying, “Let’s start the company, and then figure out what our idea is.” It wasn’t like we’re starting the company for the sake of having a company, or for the sake of being a founder. We really started with the problem and said, this is a real problem, we see this over and over again, nobody solved it and we’re passionate about it.
And so, in some sense, we felt like the problem came first, and the vehicle for us to solve it was, let’s go form a company around it, but it wasn’t the other way around. We didn’t start with the company, and then go looking for a problem.
I think like I always say, in the end, people build companies. But companies are built by identifying a real pain point, so make sure your product is a pain killer, not a vitamin. So, one thing that first time founders want to learn about is choosing your co-founders. The partnership I have seen between Mitch Hashimoto and you is very unique. You guys can complete each other’s sentences. You guys are always watching out for each other, helping each other grow. So, any advice on how founders should choose their co-founders, and why are they important?
Yeah. It’s a great question. I see some people try and go to founder speed dating events, to try and find a founder. And to me, that seems like such a scary idea, to pick your founder after a 30 minute chat. Because I think for me and Mitchell, it started from a deep friendship first. And we spent many, many years together, in undergrad, and then as colleagues, working side by side, before we ever became co-founders together. I think we have such a deep mutual trust and respect, that anytime we have a disagreement, or anytime we have a challenging discussion, I think what makes it so powerful for us, is our ability to set our ego aside.
Because we know that if I’m saying something, it’s not because I’m attacking Mitchell personally. Or if he’s critiquing my idea, it’s not because he thinks worse of me as a person. It’s that we both have such high trust and respect, that that’s almost not a question. We set that off the table, it’s like, ‘Hey, we know we’re both asking and saying these things, because we’re trying to come up with the best answer for the company, or we want the best idea, or the best product.’ And so, I think that ability for us to move beyond our ego, to really focus on what’s the best thing here for the user, or the company, or the product, is really what makes it such a successful partnership. It’s never about either of our egos, or feeling like there’s a lack of mutual trust or respect.
And I think that’s what makes the partnership so successful, because as a startup, it is a roller coaster. You have your great days, where you’re riding high, and you feel indestructible, and you have your lows. And I think your ability to ride both of those out, really depends on the strength of that relationship with your partner.
I think like I always say, for co-founders, one plus one equals two is not enough. It better be a five or a six, but I’ve seen like 11 – the 10 X factor – with you guys. As you mentioned, company building always comes with a lot of ups and downs. But it’s a marathon, it’s not a sprint. And I believe the founding mission and values of a company are critical. And in your case, you guys came up with the Tao of HashiCorp. Any advice for founders on how important it is to write down the values and the mission of a company, because it’s been a great case study for many of our companies, to learn from you guys.
Yeah. I think it’s a great point, and I think it has become even more important as we’re all moving to a hybrid, remote world. I’ll call it the intentionality of the business. I think we’ve always been hyper intentional about all of the decisions we make, the culture we want to build, the process we want to build, et cetera.
And so, I think for us at the heart of that intentionality is documenting it and being super explicit, and honestly getting comfortable to the point where we are able to put it on the internet. So, when we talk about the Tao of HashiCorp, for example, that’s really our product design ethos. And so, from the very beginning, before we’d even written all of the products, we sat down and said, “You know what? How do we want all the products to look, and feel, and behave? And what’s the, in some sense, the deeper belief we have about how infrastructure software should work to begin with?”
And so, that’s really where the Tao started, saying, “Let’s capture what those beliefs are, document them, and go so far as to publish them.” Because I think that the act of publishing it lets you bring your users, your customers, your community, with you, so they can say, “You know what? That is a set of principles I believe in.” Or it gets them to consider, why don’t I operate my infrastructure that way? Or why do I maybe have a different set of beliefs?
So, I think it allows you to have a different level of conversation, which is less about the features, and more about the philosophy. Now, I think we did the same thing around the culture of the business, and we call that one, the principles of HashiCorp. So, if the Tao for us is around our products, and the design ethos, then the principles are very much about the culture.
And so, oftentimes we hear people throw around the phrase of culture fit. And anytime I talk about it, I put it in quotes, because I think the problem with a phrase like culture fit, is for most organizations, they don’t define it. If you ask an organization to say, “What is culture fit for you?” It becomes one of these, I know it when I see it type of things. And that very quickly, I think, becomes exclusionary. I think it becomes an old boys club, in terms of how it gets defined, because then it becomes the first 10, 20 people at the company, who really get to define what culture fit is. It’s not this fair, equitable thing.
And so, I think for us, we said, we want to be really clear that the principles of HashiCorp, what we capture, what we document, that is culture fit at HashiCorp, they’re one in the same. And in fact we’re going to publish it on our website. And so for us, it makes it this very explicit thing that we put into our review process. So, anytime a candidate interviews, we screen them on the principles, and we have feedback. And when we talk about it’s not like, oh, that person wasn’t a culture fit because that’s not useful feedback. We can say, you know what? That person seemed very dogmatic in their views. They didn’t express a lot of pragmatism in how they make decisions. That’s not a good fit for the HashiCorp environment.
And so, it lets us give much more fair feedback, both internally and to the candidates. But then, it also self-selects. The people who apply to HashiCorp, are the people who read those principles and say, “You know what? That is an environment I want to be in.” So, I think it’s a two way road. It helps us both internally, but it also helps us attract candidates that say, “You know what, that’s the right environment for me.” Or they say, “You know what, that’s the wrong environment. It’s not the kind of culture I want to be a part of.” And that’s great too. We don’t want to talk to someone who thinks it’s the wrong culture.
So, I think that being really intentional always helps you to have a better quality of conversation, both internally, but also helps you start the conversation externally, whether it’s a candidate, or a customer, or a user. And so, I think it’s been super successful for us to really document our practices and values.
I did spend a little while at AWS and Amazon. What I saw there was their notion of their leadership principles. And they have a very document driven culture. The famous Amazon six pager. So, there was a lot of aspects that we actually borrowed from organizations like Amazon, in terms of written culture, or being very explicit, being very intentional.
And then, when we looked at the principles – actually, some of the folks we looked at were Ray Dalio and the Bridgewater Group. So, for folks that haven’t studied Bridgewater, they have a very unique culture. They believe in notions of radical transparency. They have a published book of those corporate principles, that’s now in publication format.
And so, it was early exposure to some of those environments, as well as exposure to some of the smaller, more shoot from the hip, Silicon Valley startups. And we said, “Okay, there’s parts of that we don’t want to replicate.” And we really synthesized it, and said, “Okay, what’s going to be a good blend for us. I think a culture as extreme as Bridgewater is hard to scale.” But then, I think a lot of the aspects of Amazon’s culture made sense, and we brought that in. And then, we looked at, how do you make it a very professional and inclusive work culture as well? Those were all super important. So, we blended a lot of the best of worlds that we saw from other great organizations, and tried to make it uniquely HashiCorp from there.
That’s great. Great learnings for everybody on that front. You brought in David Janet as CEO who has been a great addition. What was the thinking behind it? Because it’s your baby. You guys started the company. Getting in a CEO, what was going through your mind ? I think it would be good to share your thought process with people.
Ultimately, we decided when we grow up, given the space we’re in, focusing on enterprise makes the most sense for us. And so, we made that decision to pivot internally. I think the question then for me and Mitchell became, who’s the right leader for that? And I think, as founders, obviously we had the the moral authority. And I think if we wanted to be CEO, we could have been.
So, the question is, that 1,000 mistakes that you’re going to make, is that going to jeopardize the business? Right. The answer is not, you can only make zero mistakes. But there’s some threshold where you’ve made so many mistakes that they will kill the company. And then, on the other side, it’s like, could we bring someone in, that no one’s going to be perfect. That’s not going to happen. But can you find someone who’s been there, done that, and maybe they’ll make 50 mistakes, as opposed to a 1,000.
And so, the question is, does that 95% reduction in mistakes improve the odds that the company succeeds, and is that more important to us than our title? And I think when we really interrogated it, we said, “Yeah, that’s ultimately more important to us.” If my title has to be chief janitor, then so what, I don’t really care, I’ll happily do that. What matters to me is that, the company’s successful, the products are successful, the vision is brought to market.
And so, I think once we internalized that, then we said, “Yeah, the right thing to do is for us to bring in the right person, whatever their title should be.” Let’s find the right person who will drive the company’s success, and compliment me and Mitchell’s strengths, and then ultimately check our ego and really say, “You know what, the title doesn’t really matter at the end of the day.”
Very unique perspective, and very helpful for everyone. So, switching gears. You guys are a role model also on the front of building community, leveraging open source – any learnings on that front? How should companies think about the importance of community? What do they open source? What do they provide as a SaaS service? What is commercial? So, any key learnings you would bring out for the audience?
I think there are so many. We could do a master class just on open source strategy. I think at the heart of it is, people often think about open source as a thing that you can bolt on to any strategy, as part of a marketing effort. And I think that rarely works. I think you have to decide, and there’s a bit of a binary choice here, which is, do you authentically commit to open source, or do you not? Because I think anything in the middle, the community realizes pretty quickly it’s inauthentic. And I think you get the worst of both worlds, to be honest.
And I think if you authentically commit to open source, then what that really means is, you have to make sure the product isn’t crippleware, in the open source. It has to be that practitioners can use it, download it, extend it, and really see the true value of the tool, in a purely open source motion. I think you have to then commit towards developer education and developer evangelism. So, there’s big investments that go into not just putting the code on GitHub, but building the communities around it. We have our HashiCorp user groups around the world. We have HashiConf, which is our two global conferences.
So, we spend a lot of time, money and energy fostering a community around it. Our engineers interface with the open source community every day. Our product managers interface with the community. So, we’re very authentically committed to it. I think then as you talk about commercializing open source, I think the most important thing is to articulate a clear framework for what’s commercial and what’s open source. Because I think if you do it on an ad hoc or random basis, it becomes very easy to upset your open source community, because they feel like there’s no rhyme or reason to how you’re operating. There’s no framework that they understand.
First, I think we’ve always been really clear that solving the core technical problem is always open source for HashiCorp. Solving the organizational challenge around using that product is our commercial product. And I think that articulation and framing, has always made it really clear for our community, why something goes one way or the other, and they don’t feel like it’s just random.
So, I think having that intentionality and being able to articulate it is really, really important. And I think maybe the most important rule is, what you give to the community, you never take back. Open source communities are very loss adverse. And so, maybe it’s a mistake and you regret it. But I think, you have to learn to live with some of those mistakes, rather than try and take it back because that burns the trust of the community. So, I think some of those become really important.
From a commercialization viewpoint, I think obviously the markets have evolved a lot since HashiCorp started. I think SaaS is probably the most predominant and the right answer for most organizations. Obviously, that’s a large component of our business. That’s self-managed open core. I think that’s driven by the fact that, when we started this in circa 2012, most enterprises were not comfortable with the idea of SaaS managed infrastructure. And in addition, we’re at the core infrastructure layer. We’re not a high level application SaaS. So, core infrastructure people tend to want to self-manage as well.
So, I think the answer depends slightly on what business you’re in, but by and large, I think most enterprises have come around to the idea that SaaS is the future, and consumption billing is the future. And that’s probably the right way to monetize it.
I think that’s been our takeaway, having been involved in so many companies. But I think as I was mentioning, and you just affirmed that, SaaS is the way as companies go cloud native. So switching gears, HashiCorp has had so many opportunities. And in your role, how do you help prioritize which products to build, and how do you find product market fit?
Yeah. I think in some sense, it goes back to our origin. We were the end users of this stuff and so, we understood the problem space intimately, because we were the operators and we were the buyers of these tools, if you will. And so, I think a lot of founders go on problem searches or solution searches. Which is where they might start with an idea, and then look for the problem that it solves. And I think that’s almost the wrong way to do it. I think the right way to do it is, start by identifying a real problem. And then, by definition, if you can solve that problem, you have product market fit. Because if you know an organization has that problem, and it’s a painful problem, the more painful, the better. Then, they’ll be willing to pay to make that problem go away. Versus if you start from a solution, and you look for a problem, there’s no guarantee anybody actually has that problem.
And so, I think this goes to the core ethos of the company. We talk about this in the Tao – we start with the user workflow problem. So, when we’re building any new product, we go into our customers, we go into our users and we say, “Show us a workflow problem you have, that’s really painful. This could be a thing you’re actually doing every day of every week. Show me that thing. And hey, what if I could automate that for you? Or what if I could make that less painful for you?” And then, that’s what we start building the product around. So, when we talk about it with our onboarding of new employees, at the heart of what we do is, identify the workflow problem. Then we build the product around that workflow. It’s around that, then we say, “Okay, let’s go build a community of open source users and an ecosystem.”
And then finally, is the sales piece of it, where we’re monetizing at the highest commercial layers, that community of user base. But at the very heart of that onion, if we think about it in those layers, there’s a user workflow problem that we started with. And I think by virtue of thinking about it in that order, problem first, then product, you’re always very likely to have tight product market fit. Because by definition, a product was built for the specific problem. Not always. You can be off the mark. But I think starting in that order, makes it much more likely.
Got it. We are heading towards the end, so I’ll try to keep it to a few key things So, what’s something you wish you knew when you were founding HashiCorp? One thing that you’d like to tell your younger self?
I would say, know the target customer. I think we got a lot of heartburn by not being able to answer that question, and saying it’s enterprise, until we are four years into the business. We ended up with the wrong products, the wrong marketing strategy, the wrong people, the wrong sales motions. We ended up having to fix all of that. But I wish I had known that four years earlier.
Got it. And then, you’re a big believer in giving back? You think it’s important for every company to have social impact, and help communities. Any key learning there?
Yeah. We started our social impact fund, really early on, to give back to the communities. I think for anyone in this industry, we’re so blessed in many different ways. And I think all of us need to look for ways to give back to our communities. Maybe it’s the communities we came from. Maybe it’s communities that we think are underserved, or underfunded. But I think, it starts with a sense of gratitude for everything we have, and really saying, we have a lot, how do we give back to others who maybe don’t have the same opportunities?
And I would like to end by just asking you again, what’s the biggest advice for people starting companies? Just one thing that comes to mind?
I would say, you just have to get on with it. And what I mean by that is, I see a lot of people obsess over, I’m going to read every book on Zero to One, or Good to Grade. I’m going to go to a thousand seminars, and a million conferences, and I’m going to soak in all of this context, and then I’ll be ready. And the answer is, every company, every situation, every market is unique. There’s no playbook for it. Some of these innovations, you have to just jump into the pool, and then solve the problems as you go. There’s just no way around it. Because from all the webinars, and books, and whatever I’ve been through, none of them would’ve told me what I should do in my role at HashiCorp over the last 10 years. Yeah, they’re all useful and interesting anecdotes. And maybe there’s some frameworks that are helpful. But ultimately, you just have to jump in the pool.
And I think that my ultimate advice is, there’s no right moment. There’s no level of learning that you’re like, now I’m ready. I’ve read the 1,000 books about it. I’m ready now. I think you just got to get into the water. And I think you’re going to have to solve the problems, because they’re going to be unique. They’re going to be situational. And you have to solve them in that context, that only you’re going to have. So I think in some sense, great, you should be prepared. But at the end of the day, you’ve got to start the journey somewhere.
Yeah. Be an entrepreneur, and just jump in. Love it. So, I want to end by thanking you for taking your time. And on behalf of Mayfield and myself, it’s been a pleasure working with you, Mitch, Dave, and the entire team, right from your series A. Thank you again for taking the time. It’s been a real pleasure.
Likewise. Thank you so much for making the time. And it’s been great to be here, and great to work with you.