Software Misadventures - Stories behind building HashiCorp | Mitchell Hashimoto

Episode Date: January 30, 2024

Mitchell co-founded HashiCorp in 2012 and created many important infrastructure tools, such as Terraform, Vagrant, Packer, and Consul. In addition to being a prolific engineer, Mitchell grew HashiCorp into a multi-billion-dollar public company. We discuss: How to structure large projects to avoid demotivation or burnout The "A.P.P.L.E" framework for diffusing tense situations and handling trolls How to decide what to work on Mitchell's unconventional transitions from CEO to CTO and then back to an individual contributor (IC) The quality that Mitchell values the most in an engineering team.   Segments: [0:14:19] Impactful lessons from working at the Apple Store in college [0:22:26] Origin story of HashiCorp [0:26:08] College side project that turned into Mitchell’s first financial success [0:31:25] Why infrastructure? [0:39:50] How individual products came about [0:44:17] Challenges of fundraising as a company with an umbrella of products [0:48:20] Balancing being the CTO and writing code: “I didn’t want to be that CTO that just produced technical debt” [0:53:09] Transitioning from CEO to co-CTO [0:57:26] From CTO to Individual Contributor [1:06:03] What’s next?   Show Notes: Mitchell’s blog: https://mitchellh.com/writing The “APPLE” principle that has guided Mitchell throughout his career: https://mitchellh.com/writing/apple-the-key-to-my-success Mitchell’s Startup Banking Story 😂: https://mitchellh.com/writing/my-startup-banking-story   Stay in touch: 👋 Make Ronak’s day by leaving us a review and let us know who we should talk to next! [e-mail]

The one I did in college was Vagrant. And Vagrant was local, but the constraint that made Vagrant happen locally was that I was a college student that wanted to be really frugal. So I didn't want to pay an hourly rate to AWS to launch a development environment. So I had to be local.

So I think, I always say more generally that I think the best engineering comes out of constraints. And the question is who defines those constraints? And I think in that scenario, that's a good example of an environmental constraint, which was this has to be free, that caused the design that I think other people weren't thinking about at the time. Welcome to the Software Misadventures podcast. We are your hosts, Ronak and Guan. As engineers, we are interested in not just the technologies, but the people and the stories behind them. So on this show, we try to scratch our own itch by sitting down with engineers,

founders, and investors to chat about their path, lessons they've learned, and of course, the misadventures along the way. Hi everyone, it's Guang here. In this episode, we're chatting with Mitchell Hashimoto. Mitchell co-founded HashiCorp in 2012 and created many important infrastructure tools, such as Terraform, Vagrant, Packer, and Console, which Ronik and I have used as early as when we got into software engineering. This was a big honor for us to speak with Mitchell. And in

addition to being very insightful, we're just really impressed by just how humble and candid he is. Beyond funny stories like when he transitioned from CEO to an engineer and meeting new employees that don't realize he's the founder, I personally learned a lot from the frameworks that Mitchell has developed over the years, like how to structure large projects to avoid burnout and how to diffuse tense situations and handle trolls. Without further ado, let's get into the conversation. Mitchell, super excited to have you with us today. Thank you for joining. Thanks for having me. So we thought we would start with asking you about this one thing that I read on the internet.

And someone quoted you, but you can't believe everything you read. So we're going to ask you this. Why did Neopets send you a seize and desist order? One, is this true? And if so, can you tell us more? Yeah, they sent me a letter. That's true. So how I got into programming pretty much was that i played this game neopets

and you know i didn't have that much time to be on the computer because i was in school and at homework and my parents had restrictions and so like to make the in-game currency and neopets took a lot of time that i didn't have so i looked at bots as a way to make the in-game currency so that when i came home from school i could just like play the games to make the in-game currency so that when I came home from school, I could just like play the games and use the in-game currency, not like grind it out. And that sort of led me, you know, Neopets is constantly patching to make sure the bots didn't work anymore.

And then I'd wait for updates and made me question like, how do these bots work? And can I make the updates myself? Like, how does this work? And so that long story short, led me to learn how to do programming i wrote a lot of cheats for neopets and a lot of other games but i did get a letter from from neopets asking me to stop at some point i think you know it's just a game of cat and mouse

and they realize at some point that we all know apis we all know web stuff like you could keep changing the api you keep changing things and like you could always cheat it pretty much and so they were like let's just send a legal letter and then that stopped everything when your parents saw the letter what was the reaction like honestly it was pretty calm it was sort of just like we don't know what you're doing on the computer but whatever you're doing like stop and don't do anything illegal and that was it like i didn't get grounded or get in trouble or get less computer time honestly they were just like this just stop doing whatever you're doing and i did do they brag to their friends being like oh you know my uh my son is so smart that the fbi is good i don't i don't think they've ever brought this up with anyone. So, no, it's probably more shame.

Oh, no. We'll cut this part out and they can listen to the rest of the episode. So, in terms of learning programming, is this something that you self-taught yourself or was this something you were learning in school? Well, I self-taught, but I did eventually go to college and study computer science. But by the time I went to college, I was already sort of building websites and building desktop apps and all sorts of stuff. And so I did learn a lot in college, but I was self-taught originally. And yeah, I was self-taught, but at the same time, I spent my time, you know, this is the early 2000s, right? Late 90s, early 2000s. So I spent my time living in like online forums and bulletin

boards and things like that. So even though I'm self-taught, a lot of people in those communities helped me out a lot because I would post on their dumb questions and usually they would either have links or answers to things. And so that's sort of how I figured out my way. Like going back to the Neopets thing, I found a community of people that wrote online web game cheats like for Neopets. And so when I was specifically trying to figure out how to work on Neopets stuff, I could ask them questions about that specific domain, and they usually had answers. And that's what really got me going. And there's another component, which I'm sure will lead into other questions. But there's people that release the source code for the cheats they made. And so

it's not open source in any sort of sense there's no license or anything attached to it it's just like a source drop but by reading that source code it taught me a lot a lot like i remember my 12 year old mind being blown by figuring out how to given like html how to get like a substring out of it like it's so basic now but i was trying to figure out how to read out the number of currency you currently have. As a 12-year-old, the idea of finding the character before and then finding the character after and

then doing a subtraction to figure out the length, I still remember that because it was the first time in my life that I felt like math that I was studying in school had a real, real application. I was like, holy cow, even though it's just subtraction, it was really cool. That is pretty cool. i don't think i was doing that when i was 12 so that is pretty cool even for what you were doing as a young as a young kid i i think it's really cool that you

had that realization like before going to study so that when you actually later on and you know studied computer science i feel like there was a lot more motivation. It's like, this is useful. Versus I think for me and both Veronica, it was like after the fact, like we were getting into software like after grad school. And it's like, oh yeah, probably should have taken this other class,

you know, that would have been helpful. That's very relatable though, the story. Cause I think for me also like learning about Kubernetes, like trying to set that up back at work uh he was also was very early so you know like reading through like github issues and then just like getting help from people like getting literally messages from kelsey hightower like telling us like oh yeah you should try this you should do that i'm curious what's your take on learning programming? Because nowadays, right, it's much easier. There's so many resources. I'm trying to learn Flutter and there's tutorials.

But at the same time, I feel like it's harder to get into those more, like, I don't know, grassroots communities where you're really trying to figure out things. How do you see that evolving, I guess? And like for someone that's trying to get into you know software engineering like what would you do if you were back at 12 years old i don't know i mean i think things are totally different now so i think it would be hard for me to give like concrete advice about like any sort of technology or anything i mean i think the the thing i always tell people that are learning is to find something to build for yourself.

I think that's the most motivating way. If you watch, like, now there's so much information that you can watch YouTube videos and read content nonstop. But, like, there's such a big gap between reading something and in your mind understanding it and being able to actually put it into practice. You know, I think we've all experienced that where you read a whole book and you're like, yeah, I got it. And then you go do something and you realize you don't know anything. And so I always tell people like, great, yeah, take a course on whatever, like Python, JavaScript, whatever, and then go build a real application. And I had a friend, I think that's a really good example of this, who had no background at all in computer science, didn't go to college at 19 years old just moved to san francisco and decided he wanted to work in tech not as an engineer he didn't you know he didn't know anything so he didn't just want to work in the tech industry but he taught himself

programming and one of the first things he did was he took an online like python like little video boot camp course which is really cool and then um after he took that boot camp course he wrote a personal website and what he wanted to do i remember him coming to me and telling me he wanted to do this and me thinking there's no way he's going to be able to do this and he ended up pulling it off which was he's like i want a website where people come i'm going to overlay my name and information but on the background i want to render a map and i want the map to be my current location based on my iphone and i was like okay and i i didn't really help him honestly i just pointed him into some libraries that i googled around but two weeks later he came and he's like it works and he found a way to host

like and find my iphone relay on heroku this is like 10 years ago on heroku and so it acted like a phone and it was pinging it and actually like rendered it with like not an exact location he just rendered like the map and the like 20 mile radius of where he was and then someone who had never programmed before and i just thought like he it was hard he didn't do it easily he had a lot of questions but i think after that he was such a better programmer and it happened so quickly versus somebody who would have spent those same two weeks reading or watching a lot more videos i think he learned a lot more by just fumbling through building this project so that's my general advice to people is build things yeah like how did he not give up because one of the of the i think the pros of like the community is like there's so

many people that it's like moral support i think psychologically helped a lot did he tell you how what kind of kept him going um i mean i he didn't tell me um my guess is i agree i think progress is really important to to not give up on something you have to kind of see some sort of progress that you're getting somewhere and so my guess is every day he'd come to work and we worked at the same company and he would we were on the same train back to our apartments and he would take that time to ask me some questions but they were really specific and i have no problem like answering really specific questions so i think he was connecting the dots through those questions you know the thing that i always you could tell the difference between someone who's like learning something

and on the path to learning something versus like trying to find a quick way out because the people finding the quick way out ask you these very vague, large questions. And the people that are actually learning had to ask you more specific, nuanced questions. So I could tell that he was doing something because I didn't understand the big picture.

He would just ask me questions like, oh, you know, like if I use this library, do I have to run it on the server? Or is this like a Java? Should this be in like JavaScript? And I would just give him the answer being like, oh, you probably want to run that on the server. I don't know what you're doing.

But then like the next day, he had a different question. I think he was putting all the pieces together. Nice. That's pretty cool. I think one thing which you mentioned in one of your blog posts around how you work on large technical projects was trying to shoot for something that's demo able and that allows you to one, limit the scope of what you're trying to do, but also make progress

that is visible. Could you talk more about how you think about these things? Yeah, I don't know if this is true about everybody, but I'm one of those people that if I don't see progress on what I'm working on, I get burnt out or burnt out is the worst case, but I get just really demotivated quickly. I learned that at a pretty early age, like before I went to college, because especially as a young programmer, you have all these grand ideas. I'm sure that you experience this too, where you learn programming. It's like, I'm going to make a 3d game, like something huge. And then you realize you're not making progress, you can't figure anything out, and then you throw it away. So I learned really early on that if I make my individual goals smaller to where I could see progress, then I'll be more successful. So when working even on large complex projects,

I try to break it down into pieces that not only can I complete on code quickly, but that I can complete and see an actual running result. So that's one of the methods that I use with my projects when I'm planning them is breaking them down into components that are demoable. And you've had a lot of side projects throughout your career and even before when you went to college when you know programming and many things pique your interest like i could do this or that or maybe this other thing how do you choose what you actually work on so the answer is the same between side projects and my professional work actually i've always been one of those people that i prioritize working on problems that i am having myself there you know There's a lot of problems out there that you can't do that, like software, like nuclear control systems engineering. I doubt that those people have issues with nuclear control systems in their house. But I personally am one of those

people that gets the most motivation by working on problems that I am acutely experiencing. So whether it's a side project or whether it was me earlier looking for what my next job would be, what companies I should apply to, it was always for me had to be things that I would use or need soon. So that's how I do it. So that requires discipline. I find myself starting thinking about that, but then I get distracted very quickly. I think that's true for many people. So what resulted in you having that discipline to say, you know what, don't get distracted, focus on the things that are actually important? Yeah, I don't have a great answer for that one. I mean, I think that for me, I have at this point successfully shipped software before.

And I think once I reached that point where I shipped software, I realized that the joy and excitement that comes from seeing others use your software and solve their problems as well is sort of what pushes me to complete a project towards the end. I wasn't always this way. Definitely, at different times in my life, I just try things for a few weeks, throw it away, and try another thing. I think that's really useful for learning. But at a certain point, you know, most people have to ship whether it's maybe never for a side project. It's not that important. But, you know, for work or something, you have to be able to have some discipline. Otherwise, you'll be bouncing around jobs or teams or something.

For sure. For sure. So you've mentioned on scrolling through your Twitter or X thread, and you'd mentioned the time of working at the Apple retail store. I saw your picture holding the first MacBook Air in Oregon. Yeah, yeah, yeah. One of the first in Washington. Yeah, that's pretty cool. So what was that experience like?

I think it had an influence on how you even think about products. So curious to know what influence it had it had a pretty big influence and i i was always one of those kids that worked a lot of jobs so i had been a math tutor i'd worked at a smoothie place i'd worked at a coffee place i'd worked at a grocery store and so the apple store though i don't think any of those were particularly formative but the apple store i do believe was actually quite formative for my career and it's both in product and in i think equally or more important is like human customer interaction so i'll say on the product side i mean it's less like i was a retail employee so it's like not like i saw how they designed the products but i think for me it was how they cared so much about the

products even from a retail perspective so seeing how the thing that blew my mind i a lot of things but the thing that really i couldn't believe i don't know if they still do this today but back then we had to comp they taught us to constantly shuffle around the store whenever we weren't talking to a customer and robotically do this thing where you line up all the computers again or ipods or iphones or whatever was out and you don't just line them up to like what you think looks good they had a few i think to this day yeah yeah to this day all the apple products are on these wood grain counters or tables and they actually marked out no they didn't mark it you just had to memorize it there was a grain grain of wood that the laptops and well, the different products, there was a grain of wood that the MacBooks lined up to a grain of wood that iMac lined up to. And you just had to learn what that grain was and map

it up perfectly. And it was a really, it was a thing like I remember our managers would walk around and they would be like, yo, this is, you know, it would be like a millimeter off and be like, this isn't the right place where this mouse is supposed to go. And that attention to detail really stuck with me being like, this is such a huge company and they care about stuff like this. So I think that was one thing.

And then I think on the customer side, I actually blogged about this, but their approach to empathy and understanding, like one of the first things they teach you is when someone has an issue with a technology device they're usually super super frustrated like they might have just lost their wedding photos or they might have just lost the ability to contact a loved one or ability to do schoolwork or something so they tend to come in super angry and they're going to be angry at you even though you had nothing to do with this and so they taught you this we spent eight hours in a hotel like little conference room doing

training where they were teaching you how to interact with people who were coming in hot and so that was super useful because i applied that over and over and over to this day i apply that to all like open source twitter whatever interactions um my family likes to say like i have no formal background in this this is just apple store stuff and and then my experience after that in open source but like my wife and my parents always tell me like i'm a professional diffuser because i don't mind at all anyone coming at me super super angry like i like working i don't like it i guess but i'm comfortable working with that person to figure out what the problem is calm them down get to a place in equal

footing and move forward together and i think that was really constantly helpful in open source and my company when i started that wait can we actually talk a little bit? So like give us like the two minute version. So you said four steps over there. So yeah, can you tell us more about the framework? Five, five. Oh, sorry. Yeah, the framework is Apple.

It's an acronym for APLE. So it's approach, probe, present, leave. And I forgot the E is now. So basically approach, right? So you approach one of these people. If they're angry, don't just leave them to be angry. Approach them. Actually take the chance to come to them and try to show that you care by coming to them.

The second step is to probe and sort of figure out what sort of is the problem. What's the actual behind all the anger, behind all the huffing and puffing, what went wrong or what do you need? And this is also throughout this whole thing is remaining calm yourself because one of the core tenets they taught was that it's very hard for an angry person to remain angry with someone who is not angry. Usually like an angry person is trying to get a rise out of you. So if you're able to keep yourself level, keep yourself calm. The person who's angry tends to over time feel more and more like, you know, an a-hole.

You know, over time, if you're just constantly like laying into someone who's trying to be really nice to you, you feel worse and worse about about yourself so just stay calm and that's going to bring them down so approach pro for the problem and then the third one is sort of like present a solution so actually don't just listen and be like thanks listen consider the options present potential solutions to their problem that they could have and then then after that sort of, you know, leave the L is like leave, like leave everyone happy, leave everyone like feeling like they got something out of it. And then I forgot what the E said for it. But I remember it has something to do with like inviting them to come back. So it's sort of like the idea that tell them, you know, if you ever

have a problem, again, just email me directly, just call me directly, we'll figure this out, it's going to be okay. So make sure they have a door to come back and get help. And so, yeah, that's constantly what I've done. I'm sure like there's examples of this over and over that are very public because I did this in open source, Dan. I can imagine working on open source projects and especially if you're active on Twitter,

this being an extremely helpful skill because like this is true, even in open source, people would spend 30 seconds on trying something. And it doesn't work. This this create an issues like this thing is not working, and so on and so forth. So yeah, yeah. And the other thing they taught as part of that was, if you go through these steps, and the person is still being unreasonable, like they're, let's not say unreasonable, they're being angry, then they are unreasonable. And this is also a good way to filter out the

people that are angry, because they actually have a problem that they want unreasonable. And this is also a good way to filter out the people that are angry because they actually have a problem that they want solved and people that are angry because they're just trying to be bad people. They're trying to make your day worse. And so in the context of a retail environment, that's pretty nice because the people that are trying to make your day worse, you could just escalate them to a manager. The manager is probably just like, yo, get out of the store in a nicer way, because you're not doing anything productive. And we've seen these people in tech too, that just like troll, they're just trolls, right? That's what you would call them. And so this is a good way, like if I engage in this process, and I realized that they're just being trolled, but I could just disengage, like there's really no issue, you could disengage, I've had

people where I've disengaged from and they're being trolled. So then they try to make a scene out of it being like, look, Mitchell's not being helpful. He's being a dick, whatever. But then I could show like the evidence is all there being like, I tried to help and you didn't engage. And so, you know, it makes it really clear what's happening here. And so that's sort of also part of the framework. And what time was this? This was before you went to college? It was my freshman year of college. It was my, like, I moved to Washington. I moved out of state. And the first thing I did was look for a job because I've always had a job.

And I had to buy stuff at the Apple store and ask if they were hiring. And yeah, got a job. And I think after graduating, you went to work at this company called Keep. I don't know if that's the right pronunciation. Yeah, it is actually yeah i see and i think at keep at some point you decided that you wanted to start hushy corp can you tell us like going from being a software engineer to deciding to start a company how did that transformation happen yeah so i started like slightly before keep uh while i was a junior in college. That's when I sort of started

both physically the software and thinking about the software that I wanted to write. So Vagrant started in college. I met my co-founder Arman in college and we were talking constantly about ideas. And then I started a notebook where I would actually keep track

of some of these ideas that I had. There's a lot that I never did, but in that notebook, which I still have, and I've sent pictures to HashiCorp and stuff, but I still have the physical notebook. You know, I actually have like a one pager of what became Terraform, a one pager of what sort of became like, console S console turned into something quite a bit different, but that that core networking problem, etc. And so that was before keep and then at Keep, I was in charge of infrastructure. And it was

a startup. So even though I had very little experience like that, I just kind of fell into the role of being in charge of infrastructure. I sort of tested these ideas. So I wrote a lot of Python scripts that I wrote something called we called launchy at the time, but it was what Terraform. It was like Terraform-esque.

Right. And then we wrote something that was a bunch of tools,, it was like Terraform-esque, right? And then I wrote something that was a bunch of tools, but it was a DNS-based service discovery mechanism that would ultimately be console. When I say become, none of this code, like I threw it all away, but the ideas and the learnings behind it are what became. And so that's where I got to do that.

And so the open source is getting pretty popular. I was testing these ideas and there was a certain point while I was there where I realized I was spending eight hours a day at work and then I was going home and then spending eight hours a night on open source and realizing, okay, I'm 21, 22, this is fine, but this is not going to be fine for very long.

And so I decided to just take the leap and start a company. I think that was the only option I saw at the time to do this stuff full time. I think there's actually different options today. But that was all I saw at the time. And that's sort of how that went. But I never expected to start a company like I didn't start any of these projects thinking, I'm going to start a business that was never an intention. Did you like worry about the financials before you quit? Yeah, I'm not dissolutioned at all to state that I was in like a fairly privileged position for a couple reasons. So I didn't have any help from family or anything. But I'd always worked job.

I'd always been pretty good about saving money. I think that as tech people coming out of college around that time, we were being paid way more than the average person coming out of college. So again, I was good at saving money there. So even though I only worked a couple years at Keep, I had put away over, I think it was like 60% of my paycheck and savings. And then in college, I actually had one successful side business that i continued to run while i was at keep and i ended up selling that business and so it's not like when i say sell a business it's not like millions of dollars i i sold the business for 200 ish thousand dollars and so you know a huge amount of money for a 21 year old 22 year old but it's not like i was going

to retire or anything i had to figure something out so you know by the time i quit keep i probably had like three three hundred fifty thousand dollars saved up which again for a 20 something year old 21 22 year old is crazy but i'd always been super frugal and stuff so i was pretty comfortable from a financial standpoint and uh yeah i think that's how I viewed the finance thing is I knew I had a few years to figure this out. And the side business that you mentioned that you had in college, this was, if I remember correctly, about helping people sign up for courses. Is that right?

Yeah. The University of Washington had a terrible system where if a class was full, it rejected your entire schedule, your proposed schedule. So you would submit your desired schedule, your proposed schedule. So you would submit your desired schedule for the entire quarter. And if any single thing in your schedule was full, it rejected the whole thing. So you'd have to resubmit. But by the time you resubmitted, another one of your classes became full. And so you would, the ultimate result, you would get none of them. So I started a service where you'd pay $5 per class and i would just text message you the moment a student dropped so that you could quickly log in and sign up i couldn't do the sign up

because of federal privacy regulations but i could text message you and say this class is now open and you could go get it actually really really funny like weird coincidence so we're recording this now yesterday at lunch i was having lunch with a parent that we met randomly because we have a baby now and you meet parents and i met this parent turned out we went to the same college and he was a customer and this this happens once in a while i really like if someone said if someone says i went to university washington i say what years and if there's like a four-year overlap on either side or on i guess on the graduating side there's like a four-year overlap i always go how did she get into class oh that's funny uh in this case by the way like having a side project that does this thing is a slightly different skill than actually charging people for it.

At the time, how did you spread the word around this and say, hey, you know what? I have this service. You can just pay me five bucks. I never, ever, ever marketed. It was all word of mouth because I was super afraid that what I was doing was not legal. I wasn't sure. I was young and I wasn't sure if the university would be cool with it. So, I mean, now I talk more publicly about it, but for the

longest time, nobody except my college roommates and they didn't tell anybody, nobody knew who was behind this thing. And the funniest stories then, or when I was in like computer science labs or libraries, and I would hear people talking about it and i actually heard a couple people i heard a couple people having a discussion being like who makes this are they a student what are like and i was sitting like a table over and uh but i was just so afraid of anyone finding out um because i was making you know for again for a college student i was making decent money on it it was making, you know, for again, for a college student, I was making decent money on it. It was making about like $40,000 a quarter pre-tax. And so I didn't want to give that up. Right. And so, yeah, I was, I, my plan was to stay quiet until they shut it down or something.

I ended up selling it and then they did shut it down a couple of years later. How would people pay you in this case if they didn't know exactly who was behind it, like PayPal account or something? Yep, PayPal. And then PayPal was just fronted by a business name. Oh, I see. That's interesting.

It's interesting to have here, we will talk about behind you, next to you thing, who is behind this thing. Yeah, I got some really good ideas, actually. There is someone this you know the podcast isn't about this but there i was at a computer lab and i charged five dollars per class okay that's how it worked per class so if you had three classes you didn't get into it for a quarter that's 15 and i had this person behind me at a computer lab and i heard her and she was complaining

how it's five dollars a class she's like i wish i could just pay one time and get as many classes as i want and i thought oh that's an interesting idea i went home that day and this is a bit slimy but you know i think this is good business sense of what i did here i i had been running it for three years at that point when i heard the girl say that in the computer lab i downloaded all my sales data into an excel spreadsheet and what i did was i calculated i have their like student id number which is public information like it's just on the front of their card so i had all that and so i was able to tell by the duration for the what was for each student what was the expected lifetime value of a person and the expected lifetime value was about 2525, $30. Because as a freshman, yeah, you might pay me $15 a quarter. But as you get more senior, there's less people fighting for the same classes.

So you get into the class anyway. But as a freshman, you don't realize that. And you feel like your whole four years is going to be complicated. So I figured out the expected lifetime value is $30. So I decided to charge $50 for a lifetime thing. And it was crazy successful. Like I think that was when I went, I went from like $25,000 a quarter to like 40.

That was like the jump to make all that money. And it never, I was like, okay, I'm going to have one good quarter and then it's all going to come down because everyone in the next quarter is not going to pay me anything. False. Like this stayed up the whole time.

And so that was a really interesting, I didn't come up with that on my own. I had an ex-girlfriend at the time who her dad was like a CFO at a big company. And I asked him what I should do. And he was like, yeah, just figure out, figure out what they would pay and then charge them more and see if they'll pay for it. And I was like, okay. And it worked. That's really cool so you mentioned like working at keep you you became uh in charge of the infrastructure pieces and a lot of ideas that you had been thinking about call it service discovery or deployment automation or provisioning infrastructure a lot of these things i'm going to use a very large bucket. They fall in the traditional category of ops,

to say. And it's not something that I've, at least in my experience, I haven't seen a lot of folks in college think about ops per se. They want to build flashy applications. They want to put up the website that people come to. They want to build a mobile application. The ideas you had been tinkering with, or at least were thinking about, are a lot of these, well, day two problems. Like, okay, once you build something or once you build infrastructure, how do you want services to talk to each other? How do you roll them out? So what kind of resulted in you thinking about these sorts of infrastructure problems? Yeah, I worked for a consultancy that built like a Ruby on Rails consultancy for a couple of years in my junior, senior year in college.

And while I was doing that, there was just ops people at the consultancy. And I thought it was really interesting. I just thought I just gravitated towards a problem and thought it was really interesting. I had fun building apps and I wanted to build these flashy apps, but I also thought it was really interesting

how they got these deployed and working for consultancy, we were able to do more complicated things then, was, you know, like, background queuing and scheduled workers and video encoding and chat systems, all sorts of we got I got to experience all sorts of fun stuff on the dev side. But it was more interesting, like, how do you deploy the system? And so that's sort of how I got into it, just asking questions. And then I think it really piqued my interest because I really think that automating a large amount of servers is such a fun problem, especially as a young engineer. I always joke that it's like building a Lego, but instead of building a Lego, you're building

a room full of synchronized robots, right? And that's the challenge that I loved to have. And so I sort of, yeah, gravitated towards it. Personally, I empathize with that a lot because my job at the bootcamp was pretty much doing this. I didn't build Terraform. I was using Terraform to do that actually. And one of our other friends, Austin,

both of our jobs was to pretty much do this where you would have every quarter, like 30, 40 people who would come into the bootcamp and they wanted to bring up all these servers on AWS. Plus, they didn't want to worry about how do I install Kafka on this machine? So just seeing like, do like Terraform apply and you see the entire infrastructure come up and you do destroy and it just goes away. Yeah.

Kind of magical to look at and even just experience as an engineer. Yeah. Yeah. And that idea of the destroy side of things, because, okay, the one I did in college was Vagrant. And Vagrant was local. But the constraint that made Vagrant happen locally was that I was a college student that wanted to be really frugal. So I didn't want to pay an hourly rate to AWS to launch a development environment. So I had to be local. So I think I always say more generally that I think the best engineering comes out of constraints.

And the question is, who defines those constraints. And I think in that scenario, that's a good example of a concern environmental constraint, which was this has to be free, that caused the design that I think other people weren't thinking about at the time, I think there was work at the time to try to spin up AWS-based dev environments. And now we see that. And I think the technology has just come so much further where that's actually more practical today. But back in 2009, we didn't really have the web technology in general

to put an editor in the browser or anything. So it had to be local. So I think that's also an important point. Yeah, yeah, yeah yeah there's two sort of sides to the coin of being very curious about the tooling right of building something because on one hand you can do a lot of automation you can make things much more efficient but the on the other hand it kind of distracts from because i remember being kind of also very excited about infrastructure and my first startup.

But then it was like life sciences, like tech. And then I was trying to put our Spark clusters on Kubernetes when it was way too early to be doing that. It would have been much better for the business, I think, if I just used Databricks. Now that you've been many years founding HashiCorp, and I'm sure you've come across a lot of engineers who maybe want to go too deep into the engineering part instead of thinking about the bigger picture. What's your take on that? I think that in a work environment alone, I think that professional environments, generally generally they have to be thinking about making money like that's their stated purpose. And so as a result of that, I think that there isn't enough time given to actually be able to reliably change the way things are done. You know, like, for example, running Spark on a Kubernetes cluster, I don't have experience doing this. I don't have experience deploying Spark. So I'm just talking about this metaphorically here. But you know,

if you had spent two months full time doing that, maybe you could have brought it. And but like you, the argument is that two months full time was a waste of time for the company, maybe. But if you spend two months doing that, you get it to happen. And then you show other companies how they can make it happen. And that two months suddenly probably comes worth it but no one's willing to pay for that two months it has to be done like sort of like for the good of the community and so i think that within a business you have to balance that but for me for example like i feel like all the big changes i made that ended up having some sort of impact was because I spent an irrational amount of time trying to get there. And so I don't think there's a way around this other than if you get really lucky at work where they're willing to be wasteful or you've got to find the time, go home, and figure it out yourself. I just don't think our society, economy, whatever, is structured in a way that there's a good platform to be able to make these changes.

So coming back to Weigrant, I think that was at some point Weigrant started making money. And I think you had a partnership with VMware, if I remember correctly? Just a product built on their product no partnership yeah okay so i started making money and i think that was the tipping point that resulted in you starting hushy corp at least this is from the stories i've read could be wrong reverse yeah i started hushy corp and then felt this this pressure to make money as quickly as possible we weren't sure when we started hushy cor, we weren't sure if it would be venture-backed yet. So there was an immediate pressure

to figure out how to make money, to give us more time to figure out what we were doing. So there was a huge demand for a VMware product integration. So I built that integration just on my own and then like on my own as in without a partnership with VMware and started selling it for $80, a licensed perpetual perversion. just on my own and then like on my own as and without a partnership with vmware and uh started selling it for 80 a license perpetual perversion and uh yeah that ended up being even though we ended up raising venture capital the amount we made from that vmware integration i've already

said publicly before has ended up paying like a few salaries for like four or five years honestly yeah it was not bad that's pretty huge uh yeah for a starting product so in this case like when you started hashicorp vagrant was a thing that you had built before and hashicorp built a whole lot of new things after and like you said you didn't know whether you wanted to be venture backed or not but did you have this idea of what kind of products you wanted to build? And not just kind of products, but also domains with an infrastructure that you wanted to touch? Yeah, definitely. We had everything up to Nomad written out before we founded HashiCorp. We had more stuff than that, that we ended up canceling for various reasons. But we had everything up to

Nomad. The only exception, the only weird one that came out, which ended up being really important for the company, was Vault. We knew we wanted to look into the secrets problem. We didn't think that would be... We thought that would be more per product. It would just have a mindset around secret information. We didn't realize secrets would be a full standalone

problem that needed to be solved, but everything else up to that point was pre-planned and when i say planned i mean like the problem the general shape of the solution but the exact technology is exact what came out like obviously that was more in the moment yeah did you how do you go about doing that is it like okay you know i'm trying to do this thing therefore right like for someone bringing up infrastructure like these are the things that i need so really focusing on that sort of profile or is it like hey i'm trying to do this one thing and then that naturally led to okay well i need this other thing in order to do it better and then like how did you approach that

yeah it was it was based on my experience at this previous startup and then another consultancy it was just like, okay. And there was also a research project, an undergraduate research project that I was part of. That's how I met Armand. A lot of it came from there too, just the problems. But it was sort of just all interrelated, which was like, okay,

if we want to live this truly elastic dream that AWS is pitching us, we need the ability to create and destroy servers like fast, automatically. Like it needs to be fluid. So that was sort of like one problem. Another problem was it felt that configuration management was king at the time.

So Chef, Puppet, things like that. And it felt like those technologies didn't, I was struggling to really make them work in this highly elastic dynamic environment so that sort of led to packer i was like i want this vagrant style thing where you just start it and it already has everything on disk ready to go so that led to packer and then we had this issue where you have all these servers that are very ephemeral how do you find them so that led the console and and so on and so forth and so like

that that could just keep going and going and so we were able to sort of i guess paint this large diagram of all the various categories of things that needed to be solved and i think very ambitiously thought we would just try to solve all of them the reality is obviously things take time and as we were building different problems, different things got solved. Like I think a huge, massive one, for example, that we had written down that we ended up canceling was what you would now call a container runtime. At the time, no one used the word container runtime,

but we knew that we wanted, we described it as Packer for application. And so that's what we were thinking about was how to bring image based deployment down to the application level, rather than there was this huge like that. And that was inspired by Heroku, because Heroku was already well established by then. And Heroku had this build step. And for anyone who had used Heroku will understand this, but at the end of the build step, you got a slug. It was called a slug. And the slug was this root FF that just got splatted onto machines.

And so that was what inspired me to think Packer for Applications would be generalizing the build pack and then using containerization though. We were thinking LXC, like using LXC to actually run these slugs in different places beyond Heroku. So that ended up being

canceled for very obvious reasons but stuff like that it was easy it felt easy for us to map it all out given our experience yeah and how did you pick which ones to prioritize and start uh first uh we sort of solved them in the order that we felt they needed like technically made sense. Like, so for example, Terraform is not very useful without the images, in my opinion. So we did Packer first, and then service discovery, you don't need until you have ephemeral machines. So we did Terraform first, and so on and so forth. So yeah. And you had these ideas written down, if you think about a bunch of these systems, they could be, or at least some of them could be a company on their own.

And in a way, HashiCorp has a diverse set of products all within the infrastructure space, but they're solving different problems. So when you went to, like, at some point you decided to raise capital. So when you were pitching this idea to investors, did it make it challenging to talk about all these different ideas you wanted to do under the same company? Yeah. Yeah, definitely. Like, definitely. It was a constant point of discussion amongst new investors and current investors that we had at various points in time. And they constantly asked, like, what are you going to focus on? You got to focus on something. What are you going to focus on? Pick one product, things like that. We were really stubborn about it. I think we compromised by doing less. And I think that was the right move. I think we did spread ourselves

really, really thin. But at the same time, I think selfishly, we wanted to solve these problems. One of my core ideas behind it was that, and I actually still believe this, and I think this is a problem with our industry, with the, I won't say our, but with the infrastructure industry today, is at the time, I felt that if you have a different entity building different products, they don't work together super well. And so I wanted to be, yeah, I wanted to build this big company that built a lot of products that ended up working together well. And I think in some ways we succeeded in other ways we really didn't. But regardless, I think the industry as a whole has turned into this map of dozens, hundreds of products that you're responsible for writing the glue for. And that's what I didn't want to happen. So I would say this

part of my vision didn't play out as how I wanted. But that in my mind, that's what I didn't want to happen. So I would say this part of my vision didn't play out as how I wanted, but that in my mind, that's what I wanted to see was this cohesive set of products. And I think that also came from the Apple experience, right? If you're within the Apple ecosystem,

then it's this beautiful working experience generally versus like you see, like non-Apple people, I would say pick on one product like if you pick on an airpod if you use airpods but you have no other apple products they are pretty annoying to use but as soon as you use like their pairing is weird there's no like good indicators but as soon as you have an iphone pretty cool and then as soon as you have like multiple products and you realize

pairing with one pairs it with all of them automatically for all time, even new ones, it all starts coming together. And so I always had this dream of being able to do that with infrastructure products, and that didn't quite play out to the extent I wanted it to. But that was also one of the core reasons we did multiple products.

One of the main things that is different about Apple and HashiCorp, I would say, is like, if I think about Apple, it's a fairly closed source, meaning you need a special hardware to even open up your, let's say, iPhone or your MacBook. Good point. But HashiCorp, on the other hand, you started with a very different philosophy on the other end of the spectrum, which is you started with open source. What resulted in you starting with open source?

Well, I mean, I think one part of it is just like that's momentum. That's how we had been doing things already. Because I never planned on ever building a business. There was never any reason for me to close source any of this originally. And so I think there was that decision that it's hard to go back on that. But I think another part, which is equally if not more important, is that infrastructure was the type of industry where people were making decisions

based on whether something was open source or not. Of course, there's a ton of infrastructure companies that are fully closed source, infrastructure software that's fully closed source that's very successful.

But the up-and-coming software was, at the time, driven by open source. If like if it wasn't open source it was sort of a non-option for a period of time yeah i think that is changing again right now because of sass mostly uh but that was also an important driver of differentiating uh between people yeah and at hashicorp like you started as a CEO of the company, and at some point, you transitioned to CTO. But before you even talk about the transition, I think you posted your GitHub stats. I was looking at the numbers. Well, one, they're mind-blowing. And I mean, you're a prolific programmer. And if I remember correctly, you were also writing code, engaging in open source community on GitHub issues as the CEO of the company. You had as a CEO of the company, you have a whole lot of other responsibilities too. So how did you manage time to make code like spending time on code a priority?

Well, the code you could see, you could see in those statistics, it's actually very clear. If you know my background, you could see a pretty steep drop off. It is pretty significant. It still seems like a lot. But, you know, if we get down off. It is pretty significant. It still seems like a lot, but you know, if we get down to like the low points and those statistics were down to like a thousand fifteen hundred contributions, GitHub's word contributions per year, but

a contribution as far as I know also includes issue responses, pull request review, etc. So I have a feeling without digging into the data, I have a feeling during those low years, it was primarily that and less me making actual commits. Because there was a period of time where I stopped completely on HashiCorp stuff. I always had side stuff going on. But on HashiCorp stuff, I stopped completely because I didn't want to be that CTO that just produced technical debt, right? That just swooped in in doesn't have any context like and so at a certain point i did that for a period of time i upset some people and so at a certain point i just stepped back completely from the hot shoe cart product besides like really focused ones i was working on so no i

think you can't really do both very well so i didn't and that was part of my transition process and how what was the what was it like the getting the feedback and that must not have felt very nice but then being able to you know take that and then make adjustments uh which feedback the um the part about just uh or creating more tech that as you put it yeah i don't think you know especially at that point i don't think anyone was comfortable enough like just like being mad at me you could you have to have a certain level of like eq right like a certain amount of ability to just like read people and i could just tell that i was producing stuff that people were getting stuck with maintenance of. And I could tell their mood, the way they talked about it. They weren't thrilled by it.

And so I sort of took that signal and adjusted myself accordingly. And it wasn't that I didn't want to do maintenance. Like, I don't have any issues doing maintenance. It was just that I got pulled away into other things. So the maintenance had to happen, but I was busy with other things. So I couldn't do the maintenance. So I decided if I couldn't be around to do the maintenance, then I wouldn't do it unless there was a specific emergency type situation. So there was like a couple instances of like, we're shipping a brand new product, we really need, we really want like a founder's vision or

mindset on this product so knowing that i would be on the product to help them launch it but then i would depart to like do other stuff like if that was well established ahead of time then i would do it but i stopped just like i used to just do some work and then at night i would just pull up like terraform issues and be like oh yeah i'm gonna fix this one i'm gonna fix this one and then i would just like pull request them and i stopped doing that that's very impressive though i know of like founder ctos right who can't do that because they're like this is my baby did you how did you i mean like how did you get that eq but like did you receive like ask for like a coaching or like uh like do you talk to the board or like they give you a heads up?

No, no. I can't recall specific instances but in my mind, it feels like there had to have just been concrete events that didn't feel good that we're learning. I made mistakes and then I learned from them. It wasn't a pre-planned sort of thing. But it definitely didn't feel good. I didn't want to...

My favorite product that we ever made is Terraform and I think I would have been really happy working on Terraform forever, but I had to step away from it. And for me, the only way I could step away from products is sort of really letting go of them and giving it's my wife likes to tell me like, I'm a very much like an all in or all out type of person. I really struggle to be 50 5050. So I think when I was all in, I was very much like a BDFL type character within the community. I made all the final decisions.

I drove the roadmap. I did everything. And then when I step out, I try to be, I try to share my opinion, but I'm very much, it's your product. You make the decision,

but here's my thinking behind it. And I think there's pros and cons to that but for me i have to do that for my own like mental health and going from ceo to cto like that's an interesting transition one i don't know if many people can do that or want to do that but the other part is also like you started the company as a ceo you kind of get to call all the shots yes you have stakeholders to answer to, but still you're deciding roadmap priorities, everything. When you become the CTO, you're letting go of some control of the company you built. And that transition doesn't sound easy. So what

resulted in you deciding that I'm okay with this, let me transition to a CTO role? So I think at a certain stage of a startup company, the CEO job becomes very differentiated from any other job. So at any startup company for the first period of certain period of time, it doesn't really matter what title anyone has, right? Because you kind of have to do everything. And yeah, okay, the founder is involved, the only one probably involved with like fundraising and things like that. But it's not that time consuming. And so you could kind of still do other stuff. At a certain point in a company's life, the CEO job starts becoming a real differentiated job.

And I think when that started happening, I realized that differentiated job was something that I didn't enjoy doing. And not only did I not enjoy doing it, but I thought, I don't know what I'm doing. So I'm going to make a lot of mistakes here. And so as part of that, we were open to bringing in a CEO and then switching to CTO. And I think a big thing is at an early stage company, you could still be really involved. Like there's no rule that says the CEO has to make all the decisions and the CTO has no say, right? So Dave became our CEO. Dave came in, was really respectful of me and Armand. And we as a trio sort of ran the company together, even though Dave took over the CEO responsibilities, investor relations, financial management, sort of some growth planning in terms of headcount, budgeting, things like that. But every major decision, all three of us were involved. So I felt good about that. The thing that made it tricky is that CEO was the first person we ever hired.

Maybe only, I guess, but it's the first person we ever hired where me and Armand alone, they didn't have the ability to fire that person if there was a mistake. That requires board level approval. So that was the first time we had not full control, just us two. And so that was the scariest part, because we were afraid of a scenario where we might bring someone in, they might be doing a good job for the board, but we didn't like what they were doing. But the board wouldn't be on on board, so to speak, with getting changing them or something. So that was what we kept us up at night. But we are really lucky. I mean, we never had that problem at all day was great.

But that I think that's okay. So for a long period of time, there's really no giving up control besides the control of fire. And then at a certain point, yeah, the company becomes much bigger, and the CEO is really doing a different thing. But since we brought Dave in so early, by the time the company reached that point, we were so comfortable with each other that it was all good. And at this point, I think you and Arman were co-CTOs of the company.

Yeah. How do you spread the responsibility at that point? It was pretty simple, actually. Arman more or less, okay, these lines really blur, but while we were co-CTOs, Arman more or less became sort of the public facing or like a customer facing CTO.

And I was more of the community and engineering focused CTO. And by engineering, I mean like product planning, working with VP of engineering, VP of product. Again, lines are really blurry because Armand definitely met with engineering product leaders and I definitely still did customer travel but in terms of like where our hours went he spent more hours doing that I spent more hours doing this and I think that's like that's totally normal like if you look at a company like VMware or something you know any big company they probably have like 10 to 15 CTOs yeah it's you know it's not the S you have a global CTO is basically just the boss of all the other

CTOs. It's pretty normal. So I think like Armand ended up being like, you know, the more field focused CTO and I ended up being the more internal CTO and it worked out great. And I think like if, you know, ultimately I became an ICO, ultimately I left, but I think we could have been co-CTOs

indefinitely. There was enough work to do and that balance worked well enough. You spent about five years as a CTO. And if things were going well, why switch to being an IC? Like that is, by the way, that transition overall from CEO to CTO to IC, I've never seen that.

My data points might be less, but yours was the first one I ever heard about. Yeah, I don't know. I don't know. Maybe. I'm sure someone else has done it. But yeah, so I always tell people that I did enjoy being a CTO and I did enjoy my job responsibilities and I wasn't burnt out and I could have kept doing it forever indefinitely. The issue was that as time went on, it became a life choice of what makes you happiest, so to speak. As I was thinking, looking ahead towards

Hoshikor being 10 years old, doing this for all my 20s and half my 30s, as I started getting that point, it was like, I could keep doing this and i don't dislike it but like what would optimize for me like selfishly what would optimize for my happiness and i always just loved you know coding and just like throwing code around and just being an individual contributor type engineer i loved it and as much as i liked talking to customers and doing the conference things and being part of product planning if that's like let's say if that's like a b plus level enjoyment like coding was always like a plus like always and so they're both good they're both right in there but you know i liked coding more so and it was binary like you kind of couldn't do one with the other, right? It was too time consuming on one side. So I started planning

this sort of more selfish decision at that point. I sort of felt after over 10 years of doing this and the company growing to where it was, you know, I felt like fair, it was fair that I could start thinking about this future for myself. For a long time, I made a lot of my decisions based on balancing what I wanted wanted but also what would make investors happiest and what would be best for the employees because you know employees get a lot of equity and stuff like the company by helping the company to help employees so i balanced all this and i sort of felt like with us approaching an ipo liquidity event for employees with like that i knew that was coming right from the inside with that,

with the growth that we've had or things like that. I just felt like, okay, I think it's fair that I did right by these people and that I could start being a little bit more selfish. First question. So has there been any like new team members who doesn't know the backstory and then joins the team, you know, maybe like two weeks into it was like, oh, you have a funny. Why is your last name in the company?

What's the relationship here? Has that happened? Actually, yeah. Yeah, yeah, yeah. It's not that. I mean, maybe it's really awkward for them. It really doesn't bother me at all but for the for up until pretty much the day i left um we did this thing uh where slack it was a bot in slack and slack would randomly pair two people in the company together and you

would spend 30 minutes and especially once i stepped down from being in leadership and our company was getting thousands of employees almost everyone honestly almost everyone i was getting for months i had no idea that they we would do this one-on-one they would they would literally ask me like what do you do with the company? And I would tell them. That's a legitimate question, even for my role. So I would say, like, oh, I'm an engineer on this

project. They're like, oh, cool. How long have you been here? I'd be like, oh, like, 11 years? And they're like, whoa, that's almost since the beginning. We would, like, go through this this thing and then i think the funniest was when i was leaving you know we gave some warning to various leadership groups that i was leaving even though i wasn't part of them just in case you know there was

some fallout from that and then they were telling more people and there was like i thought you know i never name and shame any of these people because it really doesn't bother me but there is a couple people that they were like oh mitchell mitchell's gonna announce that he's leaving and they're like who's mitchell like who are we talking about because i actually view that as a huge success because it had been long enough that i was unimportant enough that who cares right and that's the best time to leave but But yeah, it's definitely super funny. I think you've reached like the level above sort of like recognition and then, you know, being kind of appreciated by employees to the more like higher level of like self-actualization. I have this question. This may not go anywhere so we can skip it. But one of the things that you said, at some point you started thinking about what actually gives you happiness in the grand scheme of things and yes being the co-founder cto of the company did give you joy

but writing code gave you even more joy all of this when you are smack in the middle of things there are lots of priorities you need to get done with you rarely have the mental bandwidth to get this clarity you're just like execute deliver stuff make progress when progress gets made that's like you get the dopamine hit you do it again yeah was there a specific thing you went through to reflect and realize you know what take a step back and this is not the thing i want to do long term versus this is the other thing i would do instead yeah there there's various moments of reflection, I think, that happen. The way I sort of distill it to people without getting into like specific events, I would say, is I always knew that coding and that sort of thing made me the happiest because it was always the thing I made time for, even when I didn't have time. And so that's when people say like, what is my, I don't, I'm not passionate about anything or something. I always say like, what would, if you were exhausted and you know, you were out of

time at the end of the day and you did a full day of work, what is something you would still make time to do if you could? And so for me, you know, I would travel internationally, fly for 12 hours, come home. It would be like two in the morning, and I would still be like, you know, before I go to bed, I'm going to fix one GitHub issue. And it's like, there was no reason to do that, right? The only reason I was doing that was because I really wanted to do it. And so looking back when I saw stuff like that's what made me realize that's what I'm going to make time. I wasn't going to make time no matter what for a lot of the other stuff I was doing.

I like that advice, but then also, I think I'm too old to be a professional, you know, esports gamer. So I don't quite like that answer also. So you transitioned to being an IC at this point. When you transitioned, did you decide like, how did you decide what projects you would work on or like what did that overall look like yeah i think you know i had the privilege where anyone

was open to me choosing whatever i wanted to work on which i i decided to continue working on the product that i was i was sort of leading anyway so i just moved from a leadership position to i was familiar with the team. Everyone knew me. I moved straight into an IC position. I think that worked pretty well. And then after that, because I was afraid of sort of just jumping

into certain pre-existing teams, I did work more on like special projects after that that would sort of help kickstart other teams. But yeah, that's how I made that initial decision. And in this case, like if you identify as an IC, if people had feedback about you, would they come up to you and say this directly as a peer? Or would they have a channel to go to and say, hey, you know what, this is something we don't like? Or what did that look like? Well, you know, I don't know the things people didn't tell me, right? So I can't know.

But I tried really hard to create an environment where it was really clear that they were welcome to give me feedback that I wouldn't take it poorly. But more importantly, I tried to make it really clear that I would never abuse my founder title to do anything. So, and that happened regularly for not super dramatic things. You know, like people would come to me and say, hey, do you think you could talk to the manager

about making this change on the team? And I would, and it wasn't negative, but I would just say, no, I'm not going to do it. Because, you know, if I say it, then yes, there might be some implicit weight behind it. And I'm not trying to do that. So you should, you should tell them and things like that. So I tried really hard to do that. I participated in the one-on-ones and peer review, just like anyone else. Yeah, it was, I think it was okay. But like I said, you know, I don't know what people were saying behind my back. So I't know and recently i think in december you

announced that you're departing from hashicorp now that was another big step two years after you transitioned to being a seat being an ic tell us more about how you decided to do that yeah the um so you know the blog posts i wrote it and uh it's true you know it wasn't written by pr or anything and what's what i've stayed there is true which is that the big difference between being an ic which i was having a blast doing and leaving the company was that i really wanted to have the bandwidth to play around with stuff that wouldn't necessarily benefit the company in any way. I had spent over 10, I mean, 10 years of the company, but 15 years, not like total thinking about infrastructure, just like every day, just thinking about infrastructure. And I really wanted to now

think about other things. And so I didn't feel comfortable doing that while being paid, while like having these benefits, things like that. It didn't feel fair to me in a, especially like in a tighter economy when there's less jobs, like it just didn't feel good. There's, there's people out there that say it's your company, you know, you have that privilege, whatever, whatever. I think that's fair. But I felt like financially, I was in a place where I didn't need that. If me leaving opened the door for another person to get hired, that's better than me staying there, honestly. So I wanted to do this. And so that was the main motivator to make that final step.

Did you consider this option where you could still tinker around with stuff, but that becomes another product for HashiCorp? So that way you could still stay at the company? Yeah, of course. I think I just wanted, I didn't have any specific product things in mind. I just wanted to do things like learn learn spend more time doing like gpu programming some more time doing like different categories and things and the issue is like there's a good chance none of this is ever relevant like hush group would never want this stock anyway at all so it was sort of a waste

yeah i mean i think bigger big big big companies like google and stuff i think they have specific like categories of people that literally do this you know as long as they get to own the copyright they're happy with you doing completely mindless things but punch corps is not at that stage and uh it just that never felt great to me and so at this point i I know you're building this new terminal emulator. Apart from this, what's next for you? Nothing specifically. So one, I'm taking a break because I have a brand new baby at home. And so I do want to be a good dad and focus on that.

But on the other side, I am really taking this time to just explore and do various things and solve my own problems and if anything comes out of it great but there's no like specific thing that I'm gunning for I think that yeah the terminal emir project is a little more public it's a little more like real than other stuff I've been playing around with and there's actually users and things

like that but it's not necessarily going to be this huge focus of mine. I'm not sure yet. What are the other things that you are playing around with if you don't mind sharing? Nothing that exciting. I think that I've been having fun with, like I said, just systems-level programming,

I've been having fun with trying to figure out what can I use hardware-specific features for like make better software so i always think about this in the context of like if i were writing terraform today if i were writing whatever you know vault console today like if i said that it was super optimized for a specific type of hardware would that change something because one of the things that actually really bothers me that I would want to do differently is I think too much software today

doesn't scale enough on a single machine. Like you need the jump to when you need more machines is too quick. So in my perfect world, I think that software would require two or three machines just for availability, not for compute. And then those two or three machines just for availability not for compute and then

those two or three machines would scale super far like that was always sort of the idea i had so back when we worked at keep armand and i wrote you know keep wasn't super high scale but we wrote a lot of the core software and see the api backends were in Python, but they called out the C stuff for the hot paths. And by writing all the stuff in C, we scaled to like, I don't remember the exact number anymore, but it wasn't huge, but it was something like 500,000 requests per second

or something. It's not tiny, but it's not huge. But 500,000 requests per second and I think we were just on like two machines for availability and it was at like 5% CPU and it was just because we're like well if you write it in a language that you're like you're controlling every single machine

instruction then it and the benefit of the cost like there's a cost benefit but it's also just like mental overhead if you have everything running on one machine and it's like you can look at the process tree and understand everything you don't need to understand network failure scenarios

like you don't get partial memory corruption. Usually there's any memory corruption and the whole thing blows up. So like everything becomes atomic at that point. Yeah, I've been like thinking like could you write, I'm not doing this, I'm not doing this. I didn't sign anything to say this but I don't want to do infrastructure

again right now. But I always thought, could you write a Kubernetes? Could you write a Terraform? Could you write a tool like that today, knowing the problem that you're solving in a systems-level language? You're saying this works exceptionally well specifically on, you know, 2020-plus ARM chips. It's made for these ARM chips. chips like if you write it specific for

certain hardware how fast can you get to the point where the payoff is worth it because you would say oh yeah you only need two machines and that's just because of availability only one is active at any given time and yeah i think that's really interesting to me i think people have i think as engineer people i think engineers we've come so far, we've gone so far up the abstraction and we've gotten so comfortable with how reliable networks seem to be that we're doing these big distributed systems, but I've come all the way around to questioning whether we need them. I like when you say the networks seem to be reliable. When you do your demo on three machines for two days and it doesn't go down, you're like, yeah, this is great.

And then it changes everything. Yeah, what could go wrong? Well, I work at LinkedIn. We still have on-prem machines. I know when people start relying on specific machines, like, I care about this host name. I'm like, no, no, no, you can't do that. Okay, so you shared a lot with us

about what you have spent time on, what's going to come next. We are running close to time, so we have a couple more questions. One thing which I would ask is like, as an engineer, you have strong opinions about how to build software, not just build software,

but also like how you go about PR reviews or chainsets, something that you have a blog post on. So when working with teams, what are the things that you like to see in the engineering team that you're working with? That's a hard question. I think it's funny because in the email you sent me, you mentioned this a lot, but it is an important word for me. I think when I'm working with teams, the most important thing I like to see is pragmatism. You know, I am an engineer that has long opinions. I am an engineer that when I work on my own individual project, I want them to, the code to be beautiful and the distractions to be beautiful and blah, blah, blah, blah.

But when I'm on a team, I'm a different engineer because I have to be pragmatic about what the business is trying to achieve, what my teammates might care about, et cetera. So when I'm on a team, that's what I look for. I really have a bad experience working with people that are hard-line zealots about any specific decision. So, yeah. How do you work with such people on the team?

Because I know all of us have experienced that at some point or the other, where you have some team, it's like sometimes even, well, the customers are asking for the wrong thing. They shouldn't be using this stuff. That's stupid. Like you hear all of these things.

These words are said around very casually. How do you go about working with such engineers to say, you know what? Got something to deliver. I mean, as a founder, you engineers to say, you know what, got something to deliver? I mean, as a founder, you can do that, but any advice for others on how to deal with this? No, I don't think, I don't think, I think, I don't know. I tried my best when I was in a leadership position. I tried my best to explain that to someone that like, I don't disagree with you, but we have deadlines.

We have to balance maintenance, past decisions, et cetera. When I've been a peer on a team, it's much, much harder to do. I mean, I think you have to get leadership involved at some point if they're not willing to yield. And yeah, I don't know. I just generally speaking, I mean, there's a huge generalization. I've just almost never had a good like the those those the people that think in that way are not recoverable like nine out of ten times like they just don't fit the team they have to go somewhere else and that's just unfortunately been the experience i've had i see and before before we let you go do you have any advice for a lot of engineers out there and it was a very

vague open-ended question yes yeah i mean i think just build stuff like i think that's the the most important thing is to to really build stuff and try new things and also like be diverse in the technologies that you use because i see people go really deep and they spend 10 years only writing like javascript or something And that's like fine. But I think a lot of the times that I've become a better programmer in the environments that I work on, like I did basically go only nonstop for about 10 years. But that whole time I was doing Go, I would always spend breaks or free time on my own learning React, whatever the newest thing learning react learning

ocaml learning like systems languages whatever is a new thing like i would spend time learning it and i always felt that that experience came back to improve my core programming language as well because it taught me better maybe how computers work or taught me a better way to think about a certain abstraction so I think the best engineers are those that they're not like, I know there's a lot of like, funny memes and stuff about full stack. I'm not saying you have to be full stack, right? Like, this is not what I'm trying to say. But by being diverse in what you learn, you could be single stack and be way more, I think, effective. No, that's really well said. And thank you so much, Mitchell, for joining us today.

This was an awesome conversation. And we highly encourage people to check out your blog post. You write really well in addition to writing code really well. In fact, there is one story which I want to touch on, but we didn't have time. I think your banking story, that was fun. Oh, yeah. We'll just say this. I think Chase Bank at some point was using HashiCorp as an example to teach employees about startups.

If people want to know why they should read that blog post, we'll link it to the show notes. It's an amazing story. And I hope Alex didn't get fired because of you. I hope so, too. Yeah. Awesome. Thank you so much, Mitchell. This has been amazing. Thank you both. Thanks so much, Mitchell. Hey, thank you so much for listening to the show. You can subscribe wherever you get your podcasts and learn more about us at softwaremisadventures.com you can also write to us

at hello at software misadventures.com we would love to hear from you until next time take care