Inspired Execution

[00:00:00] Chet Kapoor: Armon, welcome to Inspired Execution. Thank you so much. I'm excited to be here. So you co-founded HashiCorp 10 plus years ago, right? 12, I think, now? Yeah, back in 2013, yeah, 11, 12, 2012, I guess, yeah. Yeah, so two questions. Let's start with the first one. Why did you start the company?

[00:00:28] Armon Dadgar: So, you know, it's actually, it's deeply ironic because it's like, you'd think as someone who spent 12 years doing infrastructure, that I'm an infrastructure guy. I'm not, I'm an app dev guy. And so this actually goes back to me and Mitchell at our previous company. We worked together at a mobile ad company and I was on the app dev side of the house. Mitchell was on sort of platform operation side. And the tension was always between our two teams, which was my team was like, hey, I want to push a new version. I want to redeploy, let's go up and down. And his team was always like, great, file a ticket against us and we need to like, we'll manually go do it. And I was always frustrated. And I'm like, Mitchell, why do I have to file a ticket? Why can't you just give me self-service tooling to do this stuff? You know, and just get out of my way, basically. And he's like, well, the tools don't exist. We're building all of these tools. I'm like, what do you mean the tools don't exist? People have been deploying infrastructure forever. And so as I started digging in, I'm like, no, the tools really don't exist.

And so in some sense, it was almost out of frustration that me and Mitchell were like, you know, a bunch of startup ideas we had, a lot of them were more like mobile payment space and other things, but we're like, but the infrastructure is this annoying block. No one has an answer to it. So Armon was like, well, why don't we spend two, three years we'll fix the infrastructure problem and then we'll move on and go back to the app side. 12 years later, we're still working on the infrastructure problems. 

[00:01:47] Chet Kapoor: You know, that is a phenomenal story. And the best part, Armon, is at least my perspective is, I say this story a lot, which is the best chair is the one that Carpenter builds for themselves, right? And nobody in between, no product managers or anything like that, the Carpenter building a chair for themselves, right? And so the fact that you've taken that and said, it sucked, we didn't have a tool, and we went off and actually built one for ourselves. Yep. Right, so that is awesome. The best ones, all right? I mean, this was built for people who wanted to do it for themselves because they were frustrated with everything else out there. 

[00:02:28] Armon Dadgar: Exactly. Well, I think what it gives you too, and I think this is important, is it gives you a super deep appreciation of the end user because it's you.

Chet Kapoor: No, no, no, for sure.

Armon Dadgar: Versus if you're building a product and you don't really understand the end user, it's like, you know, there's always a bit of a mismatch.

[00:02:42] Chet Kapoor: No, for sure, for sure. So what is, now you've done it for 12 years, right? So what has been the rose and the thorn along the journey?

[00:02:53] Armon Dadgar: Oh, wow. Man, that's a hard one. I think the rose has been, honestly, it's from the people I've gotten to meet and build relationships with. I think what's fun for me now is I have customers where I meet with them regularly and they've been customers since 2015. And it's like, wow, it's crazy to have a nine, 10 year relationship with some of these customers. And you get to see how they've gone on a journey. I have employees that have worked with us now for a decade. So it's almost, you get to know their kids and you get to know their spouses and you get to know their personal lives and you build these deeper relationships. And now some of them have moved between different companies but they're still customers of ours. So I think for me, that's exciting because the problems and the technology evolve all the time, but some of those people relationships don't. So that part's fun.

I think the thorn is, and I don't know if there's a way around this, is like, there's just a life on the road that is a part of being an enterprise, you know, technology company, right? You spend 50, 75% of your time traveling. And so I think that part of it's tricky. I'm about to leave for three weeks straight because of our HashiConf event in London and Munich and Sydney, Australia and Singapore. So you're like, you're gonna be in 12 time zones over the next three weeks. So I think that part of it is a, there's no escaping it, but it is a bit of a thorn.

[00:04:06] Chet Kapoor: That's not that bad. You know, as long as you feel like you're on a mission, those things become less and less thorny is probably the best way to put it, right? Because you're like jet lag, but you're meeting people. It's energizing you. They're using your product. They're giving you feedback. All that kind of stuff just works itself off. But there's no doubt. There is a little bit of a grind on the travel for sure.

[00:04:31] Armon Dadgar: Yeah. I think the hard part, it was honestly easier when I was single, and once you have sort of a family and a partner, that's where it gets harder where you're like, okay, I'll see you in a month. You know, that's the harder part.

[00:04:41] Chet Kapoor: No, for sure. For sure. So as a founder, you've talked about challenging the conventional Silicon Valley startup approach, right? Can you share one way that Hashi went against the norm and what was the outcome?

[00:04:55] Armon Dadgar: You know, the funny thing about Hashi is we sort of violated every rule of the Silicon Valley. [00:05:00] Maybe you can say three. Yeah, it's like, you know, I think, so when I look back and you have to put this in context of 2012, 2013, we were a remote first company.

[00:05:09] Chet Kapoor: Yeah.

[00:05:09] Armon Dadgar: That was already, people were like, what do you mean?

[00:05:13] Chet Kapoor: Yeah, there were two companies and a dog who were doing that,
right?

[00:05:15] Armon Dadgar: Exactly, yeah. And so they were like, investors were like, what do you mean you're remote? And people are all over the place. Two is we're open source, we're gonna give everything away for free. Yeah. Investors were like, what do you mean? How does that work

[00:05:27] Chet Kapoor: Yeah, for sure.

[00:05:27] Armon Dadgar: And three, we were fundamentally multi-product. Most people are like, do one thing, do it really well. We had nine products, 10 products, depending on how you want to count. And even from a very early age, we had more products than we had engineers. So we outnumbered our engineers and products. Wow. And so all of those, I think, ran against conventional wisdom, you know, from a Silicon Valley perspective. I think what's been interesting is now, obviously remote work is normalized thanks to COVID. So that feels normal. I think open source as a business model has become much better understood over certainly the last five, six, seven years.

[00:06:00] Chet Kapoor: Yeah.

[00:06:00] Armon Dadgar: And then I think on the third one, multi-product, I think the key insight we had there was, it was about a single logical buyer. It's the DevOps persona or the platform team persona. And we built a suite of products. I almost described it as like, it's Microsoft Office, but for DevOps.

[00:06:16] Chet Kapoor: Yeah, yeah.

[00:06:16] Armon Dadgar: That's kind of how I think about HashiCorp versus we built five products for five different buyers. That wouldn't work.

[00:06:21] Chet Kapoor: Correct.

[00:06:22] Armon Dadgar: I think that was the key insight. It was one user, one buyer who had a set of problems. And we took sort of a Unix philosophy approach to building the portfolio.

[00:06:29] Chet Kapoor: Instead of putting it all in one big fat product, you said, even though these look like fat features, let's make them apps. Exactly. More than anything else, because it's purpose built for specific things, right? Much like Word and Microsoft, but with Word and PowerPoint. Can I go back to, and DataStax has been my first distributed first company, right? It started out as a Cassandra project. It has always been distributed all the way through. I've been here four and a half years. It [00:07:00] was different for me, right? Is probably the best way to put it, because one of the things I continue to miss is I don't have engineers that sit right next, like 15 yards away from me or like 15 feet away from me. That's the one, me going and saying, I have an idea and let's talk about it. That's the part I miss quite a bit. And you cannot replace that, right? No matter what you do and stuff like that. There are a lot of people that are new at it. There are a lot of people like Google and AWS who are, I personally do not believe that this three days a week thing is going to work. You either do it, you either are distributed or you're not. I just think this is a temporary, you know, get people to kind of come back to work kind of thing. What would be your two insights, right? If I started a distributed company right now or remote first company, whatever phrase you want to use, what would be the two things you say that would just nail those? You know, other than use Zoom and use chat and this and that, right? What are the two most important things?

[00:08:05] Armon Dadgar: So one of the things that we've done that's been super, I'd say profoundly impactful is how the company operates from the very beginning is we have a very document oriented culture. Yes. This is something I borrowed from my time at Amazon. And so, you know, today we actually, we've taken it to such an extreme. We've homegrown our own document management system. We call it Hermes. We've open sourced it. Because we have something like 5,000 internal memos that span everything from product design requirements to RFCs on engineering design, to architectural decisions, to, customer feedback memos, et cetera. And so we've designed it in such a way that we categorize all those things by the types of documents. We've built a life cycle around how they get managed. And then we tag all these things by product area and domain so that they're discoverable. And the reason this is so important is you hire a new person into a company. Traditionally you say, hey, here's your mentor. They sit right next to you. You have a question, swivel your chair and ask them. But in a remote world, you don't have that luxury. You don't want to be slacking someone every 30 seconds, interrupting their work constantly. So instead we point them to our internal document management system and say, hey, just go ask this thing.

[00:09:10] Chet Kapoor: Yeah.

[00:09:11] Armon Dadgar: And I guarantee you, there's probably a document that answers your question.

[00:09:14] Chet Kapoor: Correct.

[00:09:14] Armon Dadgar: And so we dump all these documents into Algolia search and we have a unified search index over all of it. So you can go to that thing and say, hey, I have a question about this console feature and how it works. You put that thing in and it will show you, here's the design document. Here's the customer feedback on it. Here's the engineering design on it. And you can see that whole history. And that contact is just super invaluable as a remote company. And I think this is the biggest shift for when I see remote, companies versus the ones that were truly like in person, but are sort of hybrid now, is they have a synchronous meeting culture.

[00:09:45] Chet Kapoor: Yes. 

[00:09:46] Armon Dadgar: The problem is the moment that meeting ends, you've lost that context. 

[00:09:49] Chet Kapoor: Correct.

[00:09:49] Armon Dadgar: Right? And so it just doesn't fit in a distributed remote world where you have time zones, people are offline, right? Like you need the async nature of a document.

[00:09:58] Chet Kapoor: Correct. No, I agree. I agree. It's funny, you know, if you're AWS, I've studied, I've never worked at Amazon, but having spent a bunch of time with some folks there, the document culture from Amazon didn't start out as a remote only culture. Problem. It started out as, we're just going to document and this is how we're going to work. Google has always had that as well, but not as extreme. Right? And that's probably true for everything that Amazon does. That just, it's a little bit more extreme, right? It's the personalities of the founders, right? That shows up in every which way. I would agree, async work. And you have to, I don't, I think a lot of people don't realize that you cannot overdo it. Right? A lot of people think like you can just, no matter what you do, you can still do more. . And so we know, my take is whether you win a deal or close it, we've actually now shown it, the document culture for data stacks actually shows up in the sales organization as well. Exactly. It has to show up everywhere. Right? Yeah. Everybody can read and get smart on it. Totally. Exactly. That's awesome. What would be the piece of advice that you would give, you know, beyond remote, right? What's the wisdom that you would share? If somebody was sitting here, like I'm starting a company, please tell me the one thing I should keep in mind throughout my journey.

[00:11:22] Armon Dadgar: So it's funny. I was just at a dinner last night with some founders and, kind of came up organically in the conversation, similar type of a question. And it's, this is going to sound so basic. It's going to sound so trite, but it's know your customer. And it sounds
so dumb, but what I mean by that is I look back on the biggest mistakes we made as HashiCorp. And the first big one for us was we didn't know if when we grow up, do we sell to enterprise customers or do we sell to SMB, for example. And that's a very important distinction because it changes your
whole go-to-market, changes your pricing and packaging, changes the products you're going to build. And by virtue of us having not answered that for years, for many years at the beginning, we built entire products that we ended up killing because they were misaligned when eventually we said, we're going to sell to enterprise companies. We built the wrong products. We built the wrong go-to-market. We built the wrong pricing and packaging. We had to throw it all away and rebuild. So that notion of being able to say, hey, do I sell to SMB? Do I sell to enterprise is super important. And then one level deeper is within that enterprise, what's the name? What's the title of your buyer?

[00:12:25] Chet Kapoor: Yeah.

[00:12:26] Armon Dadgar: Because I think you see, oftentimes people will build a great technology, but if you're like, hey, this could be sold to everyone from the CISO to the CIO to the head of HR to the CFO, you have no buyer.

[00:12:35] Chet Kapoor: Yeah. And knowing the title, I think is a good example. The one clarification I want is when you say know the customer, do you mean the buyer or the user? Because in the enterprise world, right? They are two separate people. If the user and the buyer are the same, it's like it's a thousand dollar product. Right. And so in your learnings are where should they fall? Obviously you need to know the user because you need to build a product for them like you did for yourself. Right. But I think your comment just to be clear was about the buyer, right?

[00:13:10] Armon Dadgar: Correct. It's about, yeah, exactly. Yeah, you have to know your buyer, right? That's what I mean when I say customer. It's like, who's the buyer? So specifically, it's know your segment. Are you SMB or enterprise? And then within an enterprise, understanding, okay, is it the CIO who's gonna sign my check? Is it the CISO? Is it a VP of infrastructure? Is it a VP of, IM and security, right? And then understanding and building a go-to-market model, how do you get to that person? Right. And, is it top down? Is it bottom-up through a champion who's your user? And I think that user versus buyer divide is super important for us. But I think for years, we wouldn't be able to answer that question. And I think that we wasted a lot of time as a result. And I see a lot of startups where their mistake is they build a great technology, but they have too many possible buyers, which means it's hard to build a repeatable go-to-market motion.

[00:13:57] Chet Kapoor: You know, it's funny, Arman, you would agree with both these comments. One is, when I get a chance to talk to a bunch of folks who build companies or people who are building them, it's never the technology. It is all the mistakes made, are all made on the go-to-market side with the picking the right customer, picking the right, how did you sell it? And how do you do this? And all that stuff. Because not to say that, building products is easy, it is hard, but it's a well-defined problem, right? You have the right people use it, they think about it outside in, they, you know, you have a process, you modify the process that works for you and you go from there, right? But almost always the answer is, I should have changed that on the go-to-market side, right?

[00:14:44] Armon Dadgar: You must be better at this than I am, because I have a long list of regrets on both sides of the house.

[00:14:49] Chet Kapoor: Yeah, but generally we always go to the go-to market side, right? Because we've, on the product stuff, it's also the feedback loop is much shorter, right? Especially if you have a product for developers, right? You get-

[00:15:00] Armon Dadgar: I think the other side of this is, for a lot of founders, they tend to be engineers.

[00:15:04] Chet Kapoor: Yes.

[00:15:04] Armon Dadgar: And so they have a more natural intuition of what needs to be done on the product side, where I think the go-to-market side, a lot of it can be less intuitive.

[00:15:11] Chet Kapoor: Yeah, I agree.

[00:15:12] Armon Dadgar: But I think what's like, part of it just has to do with that personality and background of founders bringing an engineering mindset and maybe not having some of the right intuition on the go-to market side. Certainly that was the case for me. It was like I brought an engineer mindset to the product. I was the buyer, I was the user, so I understood that side of it pretty well. But the go-to-market side was very new to me, and so that's where probably most of the mistakes were made.

[00:15:30] Chet Kapoor: Yeah, no, for sure. And what's interesting is the second comment I'll make is, I tell this to founders, you are gonna make the same number of mistakes I made, I just hope they're different. Yeah. Right, because hopefully you're learning from mine, right? And so, don't be confused. You're not gonna make less mistakes. The number of mistakes you make will be absolutely the same number. It's just, they'll be different. That's the goal here, right? So I think you would agree with both those comments. Totally. Cloud and AI. HashiCorp is now focused on cloud and infrastructure service for many years. We're a big customer, thank you very much. I've been a customer for a long time. Where are most companies in their cloud journey? And let me be a little bit more specific. It seems like people were going pretty hard on the cloud journey. And over the last 12, 18 months, they kind of slowed down, right? Just because the economic conditions and uncertainty and inflation. And now they seem like back on. But do you have a sense of where they are? Because you're like a leading indicator of where people's cloud journeys are.

[00:16:42] Armon Dadgar: You know, it's interesting. And the way I'd put it is, it's a tale of two cities is how I think about it. On one hand, you have the people who I'll say kind of did cloud right from the beginning, right? There's a lot of them were the cloud native companies because they grew up in cloud. They were built in cloud. And then some of the more progressive enterprise customers, I think they brought in the right architects. They designed around practices like infrastructure as code and elasticity and modern containers, et cetera. So they did cloud correctly. Then I think there's a huge tranche of customers who were, I think frankly, cloud was the mantra for years, where they did a lift and shift. And they just took the mess they had in data center. They hired an SI to come and point and click all day and, you know, the Amazon, Azure, Google console, and they just lift and shifted their mess into cloud. And basically what they ended up doing is recreating a data center, but even more expensive. It just happens to be in the cloud. And so now I think what you're seeing is this sort of divide in behavior, which is sort of the cloud native folks. Yeah, everyone, we went through an OPEX optimization cycle with sort of the downturn and interest rates and whatever. The cloud native people got through that faster and then they went back to business as usual, right? They're like, okay, new applications, now AI based stuff, et cetera. Versus the people who did these big lift and shifts are a little bit stuck because they went through these [00:18:00] huge cloud programs to get to cloud, massive costs, bring all these SIs, et cetera. And then they got there and they realized, actually, I'm getting no real business benefit. And all I did was uplift my OPEX 20%.

[00:18:10] Chet Kapoor: Yeah.

[00:18:11] Armon Dadgar: And now they have to go through a second refactoring of their cloud estate to do it correctly. And I think you see a lot of cost constraints, skill constraints and their ability to do that.

[00:18:22] Chet Kapoor: And we obviously have biased points of views because of the data we see, right? Based on our customer base, but would you see what's the split between the two cities?

[00:18:31] Armon Dadgar: Well, part of it is I think, yeah, if you're within 30 miles of the Bay Area, you're probably cloud native looking. Yeah. I think some of the FSI retail, some of them tend to be better off. I think they're a little bit more cloud native as you get into maybe some more traditional industries, manufacturing, public sector, energy, things like that. I think a lot of lift and shift took place. So I think you can almost look at our own verticals. I wouldn't [00:19:00] say that's perfect. There's some really good examples that are exceptions to that, but broadly, I think that's almost how I'd look at it.

[00:19:07] Chet Kapoor: So let's talk a little bit about AI, right? AI is unique. It's building, like I talk about, this is my fifth wave, client server, web, mobile, cloud, and now Gen AI. And the reason I say Gen AI is gonna move very quickly, and I'm obviously concerned about governance. I wanna make sure that we have some light governance sooner than any other wave, just because it is so human-like, right? But not at the cost of innovation. And the reason Gen AI will move so fast is because it builds on everything that was done before. Right? And so how do you think about Gen AI and what it does for app development? But beyond the here's a co-pilot and gives you 30%  productivity, right? Do you have a sense on what does it do to the DevOps world that you're in? There's a lot of automation. Like yours, your co founder and you, if you started the company now. [00:20:00] Yeah. You would build a very different product. Right. Because you would assume so many different things. You would probably use models, small models internally, LLMs externally, right? You would just, you would have a different architecture. Just giving you a perspective on Gen AI in general and Gen AI in the DevOps world.

[00:20:19] Armon Dadgar: Yeah. So the way I think about this, it's interesting because I think we've gone through this, if we think about the software development landscape in various ways. To me, if I strip the AI magic and think about it as it's an abstraction layer of a sort, then to me, is it any different in some sense than with the kind of history that we've gone through? And what I mean by that is, years ago you'd write actual assembly code. Yes. We said that's inefficient. We're going to move to a higher level language like Java. It's going to, it's an abstraction fundamentally over assembly code, but assembly code never went away.

[00:20:49] Chet Kapoor: Great.

[00:20:50] Armon Dadgar: Then at some point you said, okay, does it make sense for me to have to build all of my business logic into these monolithic apps, or do applications really become an API composition of services? And I think [00:21:00] that's really what cloud accelerated.

[00:21:01] Chet Kapoor: Yeah.

[00:21:01] Armon Dadgar: It can say, okay, I'm going to use the Twilio service and the DynamoDB service and Redis and whatever. And really developers start to move to a model where you're composing a bunch of logic, a little bit of business logic, but really it's a composition of a bunch of services. So then if you think about taking that one level higher, the composition of those services is coming from probably some sort of a problem requirement, which is like, hey, user wants to click this button and generate an expense report and blah, blah, blah. So we're from a product manager perspective, we're describing a set of enterprise requirements, handing it to a development team and saying, translate that into a set of Java code that's gluing APIs together.

[00:21:38] Chet Kapoor: Right.

[00:21:38] Armon Dadgar: If you up-level that, then it's like, well, over time, don't you expect that I could provide some notion of almost a formal specification to an LLM?

[00:21:46] Chet Kapoor: Yeah.

[00:21:46] Armon Dadgar: Then the LLM's job is to figure out, okay, the way you compose this is actually I need a database, I need a cache, I need

[00:21:53] Chet Kapoor: a payment

[00:21:53] Armon Dadgar: processing API, whatever. But I don't write the Java code in the same way I don't write the assembly code anymore. I write Java, it turns into assembly. Now I write a formal spec that turns into an executable. The LLM becomes that translation layer between a spec that's in natural language versus an executable code that's in, maybe it's Java, maybe it's whatever. So to me, I think that becomes the future of it. Today, yeah, you're just going to use it as co-pilot or whatever, but I think over time, it's really my formal abstraction becomes sort of a specification rather than a literally executable code.

[00:22:30] Chet Kapoor: I think the interesting thing about this is also, I think the kinds of applications that people will land up building, you've talked about the development process, right? And that was my question, but I don't think people have figured out yet what is the art of the possible with Gen AI apps. I keep saying that we're in the Angry Bird era of Gen AI where everybody's really happy that we have something that we can play on on the device and we can do a little bit of maps and things like that, right? There's so much more that we've not imagined yet, right? And I feel like we should spend a lot more of our time thinking, we should obviously do the chatbots and the co-pilots, do all of those, right? Just like we did Angry Birds and a bunch of others. But I think a bunch of us need to start thinking about the art of the possible and crashing and burning, but doing the art of the possible. Totally.

[00:23:31] Armon Dadgar: Yeah, and I think what will be interesting is our imagination is sometimes constrained by the limitations of the system today, where we sort of play with a GPT-4. So your imagination is like, okay what can GPT-4 do versus, well, but what can GPT-6 do? Correct. Right? You're like, that's not that far away, and it's going to have a totally different set of capabilities.

[00:23:52] Chet Kapoor: Yeah.

[00:23:52] Armon Dadgar: So I think that's also some of the challenges today. We're limited by the technology, but it's moving so quickly that it's just going to look different 12 months, 24 months from now. 

[00:24:02] Chet Kapoor: So what is the one bold prediction you would make for the next year for Gen AI?

[00:24:08] Armon Dadgar: Oh, I think the big one that I think you can kind of see looming on the horizon here is I think we're going to have a dip before we come back. I think the biggest thing we're going to have to figure out is supply chain integrity. And I think where you're seeing that already show up is in things like Gemini telling you to eat a rock or mix glue into your cheese, right? Or there was a recent study that showed GitHub Copilot, they did an interesting attack analysis where they're like, we're going to purposely poison it with training data that has insecure code. And what you saw was developers accepted the insecure code and the secure code at the same rate. Their acceptance rate was the same. Yeah. So what it points to is that the humans are going to get complacent in accepting whatever this thing generates, which means if you're an attacker, you're going to go upstream and say, hey, if I can put the vulnerabilities upstream, I know they're going to get embedded downstream with minimal review. So once that starts happening at scale, you're going to start to look at it and say, okay, let's hit pause. How do we get to a point where I can actually trust that this thing is generating things that aren't fundamentally creating vulnerabilities for me? And I think that's going to put a lot of scrutiny on how do you think about provenance and trusted supply chain. So there's a whole set of interesting challenges I think we've needed to solve, because you have the same problem when you saw the recent example of the SSH backdoor. It's the same problem.

[00:25:28] Chet Kapoor: Yeah, it is.

[00:25:29] Armon Dadgar: But we're not incentivizing the industry to really go solve it. Gen AI forces you to solve it.

[00:25:33] Chet Kapoor: Correct.

[00:25:34] Armon Dadgar: So I think to me, that's going to be interesting. We'll have to take a little bit of a detour to really go figure out some of these supply chain pieces. So you'll almost see a little bit of a pause, I think, while we figure that out. And then it sort of comes back to say, okay, trusted input is required to get the trusted output.

[00:25:47] Chet Kapoor: Do you think that pause has already started, or you think it's coming?

[00:25:53] Armon Dadgar: Both. And what I mean by that is, you're starting to see the pause on the enterprise side. Yes. Because enterprise companies are like, wait a minute. How do I have that assurance? But at the same time, I think the vendors building these models, building the systems are sort of full throttle, full speed ahead. I agree. So I think that's where you're going to see a little bit of a pause. The enterprises are going to be like, wait a minute. I need assurances on these things, versus I think the vendors are going to go figure it out.

Chet Kapoor: Yeah, no, this is great. This is great. So we're now in the rapid fire section of the podcast. So I'm going to ask you a bunch of questions and just give me pure responses. It doesn't have to be one word, but keep it as short as you possibly can.

Armon Dadgar: Sure.

Chet Kapoor: What's an app that you cannot live without?

Armon Dadgar: Concepts on the iPad.

Chet Kapoor: What's your favorite way to unwind at the end of the day?

[00:26:44] Armon Dadgar: Cup of tea and my Kindle.

[00:26:47] Chet Kapoor: What's one book every listener should read?

[00:26:50] Armon Dadgar: Oh my God. That's impossible. Okay. My favorite book is Virginia Woolf's To the Lighthouse.

[00:26:57] Chet Kapoor: Wow. That's great. Biggest myth [00:27:00] about the tech industry?

[00:27:04] Armon Dadgar: Where does one begin? There's a lot more FOMO driven development than you would believe.

[00:27:11] Chet Kapoor: Yeah. Yeah. I would agree. One word or phrase to best describe great leaders?

Armon Dadgar: High conviction.

Chet Kapoor: One word you would use to describe yourself?

[00:27:28] Armon Dadgar: Intellectually curious.

[00:27:30] Chet Kapoor: That's great. That's awesome. Armon, this has been awesome. Thank you very much. It is. I feel like I need to have you back and we should, you know, we've done the general high level stuff and now we should go deeper on things like, how to build developer communities and things like that.

Armon Dadgar: I'd love to.

Chet Kapoor: And talk a little bit about, like from two people who have built one and have actually screwed it up a few times and then built it again, right? And so I would love to have that conversation. This has been awesome. Thank you very much for joining us. I'm sure our listeners will have a great time listening to this.

[00:28:07] Armon Dadgar: Awesome. Really appreciate it. Sure, we could go on and on and open source and community building and business building and cloud, all day.

[00:28:14] Chet Kapoor: Yeah. Like, you know, OSS based business models, right? I mean, how do you give this stuff away and still build a business and continue to build it? There's so much. We'll make sure we do it again. And this time we'll send a note to Dave and tell him he's not invited. Thank you very much again. Appreciate it.

Armon Dadgar: My pleasure.