Stories behind building HashiCorp | Mitchell Hashimoto

The one I did in college was vagrant and vagrant with 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 an 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 the task to be free that caused the design that I think other people were thinking about at the time.

Welcome to the Software Misadventures podcast. We are your hosts, Ronak and Guang. 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 edge by sitting down with engineers, founders and investors to chat about their path, lessons they have 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, the Bigrin, Packer and Console, which Ronak 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 H's whole humble and candid ideas.

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 in handle problems. 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 want to ask you this, why did Neopets sent you a season-desist order? One is this true. So can you tell us more?

Yeah, they sent me a letter. That's true. So I sort of how I got into programming pretty much was that I played this game Neopets and I didn't have 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 and use the in-game currency not like grind it out.

And that sort of led me, you know, Neopets was 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 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 API, we all know web stuff. Like you could keep changing the API, you could keep changing things and like you could always cheat it pretty much. And so they're like let's just send a legal letter and then best off to everything. When you paid in some later, 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. Did they brag to their friends being like, ooh, you know, my son is so smart that the API 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 the learning programming, like is this something that you self-card yourself or was it something you're learning in school?

Well, I self-topped, but I did eventually go to college and study computer science. But I 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 or early 2000s. So I spent my time living in like online forums and bullets and boards and things like that. Even though I'm self-taught, a lot of people in those communities helped me out a lot because I would post on there 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 sheets like for Neopets.

And so when I was specifically trying to figure out a 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 in which I sure will lead into other questions. But there is people that release the source code for the sheets they made.

And so it's not open source and any sort of sensor with the 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 by 12 year old mine being blown by figuring out how to

give in 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 like the number of currency currently have. And like as you know as a 12 year old, like the idea of finding the character before and then finding the character after and then doing a subtraction to figure out the length.

Like I remember I still remember that because it was sort of the first time in my life that I felt like math that I was studying in school had like a real real application. And I was like, holy cow, even though it was just subtraction. Like 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 though you were doing as a young kid.

I think it's really cool that you had that realization like before going to study so that when you actually later on in you know study computer science, I feel like there was a lot more motivation inside this is useful versus I think for me and both Veronica was like after the fact like we were getting into software like after a 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 because I think for me also like learning about Kubernetes like trying to set that up back at work. It 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 from other and there's like 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 self-engineering like what would you do if you were back at 12 years old. 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 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 could 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 work. 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 a little video bootcamp course, which is really cool. And then after he took that bootcamp 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 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. It was like 10 years ago on Heroku. And so it acted like a phone. And it was pinging in and actually rendered it with like not an exact location. He just rendered like the map in the like 20 mile radius where he was. And then someone would never program before. And I just thought like he 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 that people is building.

Like how did he not give up? Because one 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? I mean, he didn't tell me. I'm I guess is I agree I think progress is really important 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. He would we were all 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 question. So I think he was connecting the dots through those questions.

The thing that I always you could tell the difference between someone who's like learning something on the path of learning something versus like trying to find a quick way out because the people finding a quick way out ask you these very big large question.

And the people that are actually learning to ask you more specific nuance 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 another server or is this like a job is to show this being like JavaScript. And I would just tell I would just give 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 have a different question. I think you was putting all the pieces together. That's that's pretty cool. I think one thing which you mentioned on your blog post around how you work on large technical projects was trying to shoot or something that's demoable. 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 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 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 goal 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 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 site projects throughout your career and even before when you went to college, when you know programming and many things, peak your interest.

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 site 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's a lot of problems out there that you can't do that. Like, you know, software, like nuclear control systems engineering, like I doubt that those people have like issues, nuclear control systems in their house.

But, you know, 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 company that 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 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 reach that point where it shipped software, I realize 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 like at different times in my life, I just try things for a few weeks, throw it away and try another thing.

I think it'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 at the first MacBook Air in Oregon. Yeah, yeah, yeah. One of the first to walk through then. Yeah, that's pretty cool. So what was that experience like? I think I think it had an influence on how you even think about products. So cutest two, no one influenced that had. It had a pretty big influence and I was always one of those kids that worked in a lot of jobs.

So I had been a math tutor. I had worked at a smoothie place at work at a coffee place that 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 is 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 a constant 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 without. 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, they didn't market. You just had to memorize it. There was a 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 I'm asked to end 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 managers would walk around and they would be like, yo, this is, you know, it would be like a millimeter off and they like this isn't the right place where this mouse is supposed to go. And that attention, the 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 they're approached to empathy and understanding like one of the first things they teach you is when someone has an issue with a technology device. They 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 school work 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 all like open source, Twitter, whatever interactions.

My family likes to say like I have no formal background on this. This is just Apple store stuff. And then my experience after that in open sort. 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 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 art my company when I started that. Can we actually talk a little bit so like give us like the two minute versions that you said four steps over there. So so yeah, can you tell us more? Five five. It's a start. Yeah, I blog the framework is Apple. It's an acronym for APL so it's approach probe present leave and I forgot the years now. But so basically like approach right so you approach one of these people you if they're angry.

Don't just leave them to be angry approach them actually like take the chance to come to them and try to show that you care right by coming to them. The second step is to probe and so to figure out what sort of is the problem like what's the actual behind all the anger behind all the huffing and puffing while we're wrong or what what do you need.

And 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 whole to you know over time if you're if you're just constantly like laying into someone who's trying to be really nice to you. You feel worse and worse 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 to sort of like present the solution.

Actually don't just listen and be like thanks listen consider the options present potential solutions to their problem that they can have and 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 east tips were but I remember 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 will figure this out it's going to be okay to 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 a example of this over and over that are very public because I did this in open source that I can I've been working on open source projects and especially if you're active on

this being an extremely helpful skill because like this is true even an 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 yeah yeah and the other thing they taught us part of that was if you go through these steps and the person is still being unreasonable like there are also say and reasonable they're being angry and 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 solved and people that are angry because they're just trying to do it.

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 you day worse you can just escalate them to a manager the manager is probably just like you get out of the store in a nicer way because you're not doing anything productive and we've seen these people in tech to 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 realize that they're just being trolled but I can 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.

What time was this was before you went to college is my freshman year college is 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 up and I think I think I'm for graduating you 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 car 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 slightly before keep I was a junior in college that's when I sort of started both physically the software thinking about the software that I wanted to write so they

started in college I met my co founder armon 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 sent pictures the hushy group and stuff I but I still have the physical notebook you know I actually have like a one

page or what became terraform a one page or what sort of became like console s console turned into something quite a bit different but 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 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 it was what terraform it was like terraform ask right and then we wrote 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 or what became and so

that's where I got to do that and so that 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 spending eight hours a night on open source and realizing okay I'm 20 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 the time and that 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 dissolutions at all to state that I wasn't like a fairly privileged position for a couple of reasons so I didn't have any help with the family or anything but I'd always work job I'd always been pretty good about saving money I think that is 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 saving and so and then in college I actually had one successful side business that I continue to run while I was at keep and I end up selling that business and so it's not like when I say sell business it's not like millions of dollars I sold the business for 200 is $1,000 and so you know I 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 had always been super frugal stuff so I was pretty comfortable from a financial standpoint and yeah I think that's how I viewed the finance thing is I knew I had a few years to figure this out

side was a thing you mentioned that you had in college this was if I remember correctly about helping people sign up for courses is that right yeah 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 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 resubmit it another one of your classes became full and so you would the ultimate result you 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 or he was a customer

and this happens once in a while they really like if someone said if someone says I went to University of Washington I say what years and if there's like a four year overlap on either side or I guess on the graduating side there's like a four year overlap I always go how did you get in the class this

well that's funny in this case by the way like having a site project that does this thing is a slightly different skills are then actually charging people for it at the time how did you spread the word around this and say hey you know what I have the service you can just pay me five bucks

I never ever ever marketed it was all word amount because I was 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 is behind this thing the funniest stories that then or when I was in like computer science labs 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 but I was just so afraid of anyone finding out because I was making you know for again for college students making decent money on it was it was making about like forty thousand dollars

a quarter pre-tax and so I didn't want to give that up right and so yeah I was I was 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 years later how would people pay when this case if they didn't know exactly who was behind it like PayPal account or something yeah PayPal and then PayPal was just fronted by a business name

oh I see that's interesting it's interesting to have here we would talk about behind next to you think who is behind this thing yeah I got some really good ideas actually there is someone this you know the slot Gausses 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 a quarter that's 15 dollars

and I had this person behind me to computer lab and I heard her and she was complaining how 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

of a big deal but I think this is a good business sense of what I did here I had been running it for three years at that point when I heard the girls say that in the computer lab I downloaded all my sales data into an Excel spreadsheet and what I did was I I have there like student ID number which is public information like it's just on the front of their cards I had all that and so I was able to tell by the

derailleur for the what was for each student what was the expected lifetime value of a person and the expected lifetime value with about twenty five thirty dollars because as a freshman now 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

that expected lifetime values thirty dollars so I decided to charge fifty dollars for a lifetime thing and it was crazy successful like I think that was when I went I went from like 25,000 dollars 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 the next quarter is not going to

be like 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 a ex girlfriend at the time who her dad was like a CFO and 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 they were really cool.

So you mentioned like working at Keef you became in charge of the infrastructure pieces and a lot of ideas that you had been thinking about college services covering 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

services 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 office person they want to build flashy applications they want to put up the website that people come to they want to build a mobile applications the idea as you had been tinkering with her at least we're thinking about a lot of these well day two problems like once you build something or once you build

a system that you want services to talk to each other how do you roll them out so what kind of result in you thinking about these types of infrastructure problems yeah I worked for a consultancy that build like a Ruby on rails consultancy for a couple years and my junior senior 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

interesting I had fun building apps that I wanted to build these flashy apps but I also thought it was really interesting how they got these deployed and working for consultancy were able to do more complicated things then which was you know like background queuing and scheduled workers and video encoding and chance systems all sort we did we got I got to experience all sorts of fun stuff on the

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 peaked my interest because I really think that like automating large amount of servers is a is such a fun problem especially the young engineer like I always joke that you know it's like building a Lego but instead of building a

Lego you're building like a room full of like synchronized robots right and that's like the challenge that I loved to happen so I sort of yeah gravitated towards it personally I empathize with that a lot because my job at the boot camp was pretty much doing this I didn't build a platform 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

have every quarter like 30 40 people who would come into the boot camp 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 like do like terraform apply and you see the entire intersected come up and you do this try and it just goes away yeah kind of magical to look at anyone just experience as an engineer yeah yeah and that idea of the destroy side of things

together one I didn't college is vagrant and vagrant with 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 an development environment so I had to be local so I think I always say more generally that I think the best way to come is that it constraints and the question is who defines those constraints and I think in that scenario that's a good example of a

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 do that and now we see that and I think that the technology has just come so much further where that's actually more practical today but back in 2009 we didn't really have like the web technology in general to

like put an editor in the browser or anything so I had to be local so I think that's also an important point yeah yeah there's two sort of size 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 can make things much more efficient but the only other hand you kind of distracts from because I remember being kind of also very excited about

infrastructure and my first like start up but then it was like life sciences like tech and then I was like trying to put our like spark spark clusters on Kubernetes when it was like way to like early to be doing that it would have been much better for the business I think if I just use data breaks now that right like you've been doing that for many years of founding has you work and I'm sure you come across a lot of engineers who maybe want to go to like too deep into the engineering part

instead of thinking about like the bigger picture like what's your take on that I think that in a work environment alone I think that work is a lot of work and I think that in a lot of other environments they have to be they have to 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

for example running spark on a Kubernetes cluster I don't have experience doing this I don't have experience to playing 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 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 a rational 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 got you got to like find the time go home and figure it out yourself I just don't think like 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 Wigren I think that was at some point Wigren started making money and I think you had a I think partnership with VMware if I had a member correctly and just a product built on there product a partnership yeah okay so it started making money and I think that was the tipping point that resulted in you starting HushyCorp at least this is from the store he's average could be on reverse yeah I started HushyCorp and then felt this this pressure to make money as quickly as possible

we weren't sure when we started HushyCorp we weren't sure if it would be venture back 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's a huge demand for VMware product integration so I built that integration just on my own and then like all my own isn't without a partnership with VMware and started selling it for $80 a license perpetual perversion

and yeah that ended up being even the wins of raising venture capital the amount we made from that VMware integration I've already said publicly before and ended up paying like a few salaries for like four or five years honestly yeah it was not bad that's pretty huge yeah for a starting product saying this is like when you started HushyCorp Wiggin was a thing that you had built before and HushyCorp built a whole lot of few things after

and like you said you didn't know way that you wanted to venture back 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 HushyCorp 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 bald we knew we wanted to like look into the Seek its problem we didn't think that would be we thought that would be more like per product like it would just have a mindset around secret information we didn't realize like secrets would be a full stand alone 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 how do you go about doing that is it like okay you know I am 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 profile or is it like hey I'm trying to do this one thing

and then that naturally let 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 the consultancy it was just like okay and there was some there was also a research project and undergraduate research project that I was part of that's how I met our mom a lot of it came from there to just the the problems but it was sort of just all interrelated

which was like okay if we want to live this truly a leftic dream that AWS is pitching up we need the ability to create and destroy servers like fast automatically like it needs to be fluid so that would 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 the packer I was like I want this vagrant style thing where you just started 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 to console and so on and so forth and so like that that you 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 he did 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 that solved like I think 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 we didn't no one used the word container runtime but we knew that we wanted we described it as 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 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 set you got a

slug it was called a slug and the slug was this root ff that just got splatted onto the machine and so that was what inspired me to think packer for applications would be generalizing the build back and then using containerization though we are we're thinking galaxy like using LXD to actually run these slugs in different places beyond Heroku so that ended up been 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.

How did you pick which was to prioritize and start first? 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 packer first and then service discovery you don't need until you have a federal machine so we did terraform first and so on and so forth so yeah.

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 hashi corp 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 they'd make it challenging to talk about all these different ideas you wanted to do under the same company 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 something what are you going to focus on pick one product things like that we were really stubborn about it like we 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 like I 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 will say are 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 end 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 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 air pod if you use air pods but you have no other Apple products they are pretty annoying to

use but as soon as you you like the 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 like it all starts coming together and so I always have 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 Hashikarp I would say is like if I think about Apple it's fairly close source meaning you like you need a special hardware to even open up your like say iPhone or Mac

but Hashikarp on the other hand you started with a very different philosophy on the other than the spectrum which is you started with open source what resulted in you starting with open source well 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 a ton of infrastructure companies that are totally close

source infrastructure software that's fully close source that's very successful but the up and coming software was at the time driven by open source the open like if it was an 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

south mostly but that was also an important driver of differentiating between people yeah and at Hashikarp 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 get-up stats and 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 like you were also writing code engaging in like open source community on GitHub issues as the CEO of the company

yeah you had as a CEO of the company you have a whole lot of other response of release too so how did you manage time to make core like spending time on quota priority well the code you could see you could see the 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 to like the low points in 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 poor request review etc so I have a feeling without digging into the data I'm a feeling during those low years it was primarily that and less be making actual commit because there was a period of time where I stopped completely on Hosh group stuff I always had

side stuff going on but on Hosh group stuff I oh I stopped completely because I didn't want to be that CTO that just produced technical debt right that just swooped 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 Hosh group 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 that was part of my transition profit and how 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 which be back the part about just 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 like got pulled away into other things so the maintenance had to happen but I was busy with other things 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 they

were the 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 founders 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 like do talk to the board or like they talked to you can be like a heads

up or like no I can't recall specific instances but I in my mind it feels like they're had to have just been like concrete events that didn't feel good that were learning like I made mistakes and then I learned from them it wasn't like a preplanned sort of thing but it definitely didn't feel good like I didn't want to you know 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 get step away from products is sort of really letting go of them and giving it it's my wife likes to tell me like I'm very much like an all in or all out type of person I really struggled to be 50-50 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 they've pros and cons for that but for me I have to do that for my own like mental health and going from CEO to CEO 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 charts 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 yeah 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 founders involved the only one probably involved 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 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 CTO 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 CTO has to make all the decisions and the CTO has no say right so I

Dave became our CEO Dave came in was really respectful of men our mom and and we as a trio sort of ran the company together even though Dave took over the CEO responsibilities invests 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 and maybe only I

guess but it's the first person we ever hired where me and our mom alone they didn't have the ability to fire that person if there was a mistake you know that requires board level approval so that was the first time we had not full control just us to and so that was the scariest part because we were afraid of the scenario we 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 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 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 the size of control the 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 and 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 our mom were cool CTOs of the company yeah how do you set up responsibility at that point it was pretty simple actually our mom more or less okay these lines

really blur but while we were co-CTOs our mom 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 product again lines are really

blurry because our mom 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 said where I was doing this and I think that's like that's totally normal like if you look at a company like the M.W. or something you know any big company they probably have like 10 to 15 CTOs it's you know it's not it's the as you have a global CTO it's basically

the possible the other CTOs it's pretty normal so I think like our mom ended up being like you know the more field focused CTO and I ended up being the more eternal CTO and it worked out great and I think like if you know ultimately I became a little I feel 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 a way by the way that transition you know at all from CTO to CTO to IC I've never seen that my

data points might be less but that's the yours was the first one I would heard about yeah I don't know I don't know maybe I'm sure someone else has done it but yeah I 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 and I could

have kept doing it forever pro indefinitely the issue was that as time went on it became a life choice of what makes you happiest so to speak you know as I was thinking looking ahead towards Hoshkorn being 10 years old doing this for all my 20s and half my 30s like you know 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 pocketed 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 two time consuming on one side so I started planning this sort of more self 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 I for a long time I made a lot of my decisions based on balancing what I wanted but also what would make investors

happy 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 everything like that I 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 choice 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 then what's the relationship has that happened actually 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 up until pretty much the day I left we did this thing where slack we was a bot and 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 I almost everyone I was getting for months 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 that's it that that's a that's a legitimate question even for my role so I would say like oh I'm an engineer on this this project they're like oh cool like how long have you been here I'm like oh like eleven years and they're like whoa it's almost as the beginning you know like we would like go through this this thing and then I think the

first thing I 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'm not gonna ever name and shame any of these people because they really doesn't bother me but there is a couple people that they were like Mitchell Mitchell's gonna know that he's leaving and they're like who's

Mitchell could we talk like we would I because I actually knew that was 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 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 city of the company did give you joy but writing code gave you even more joy all of this when you're 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 delivered stuff made 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 realized 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 happened 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 gonna fix one good have 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 gonna make time I wasn't gonna make time no matter what for a long the other stuff I was doing and like that a vice but then also I think I'm too old to be a professional you know

I'm just a gamer so I don't quite like that is so so you you transition to being an IC at this point yeah when you transition did you decide like how to decide what projects you would work on or like what did that hold all look like yeah I think you know I had the privilege where anyone

was open to make choosing whatever I wanted to work on which 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 I 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 have feedback about you would they come up to you and say the Zidic he has a peer or would they have a channel to go and say hey you know what this is something we don't like or yeah 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 don't know and

recently I think in December you announced that you're departing from Hushed Carp now that was yeah another Bix tip two years after it 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 post I wrote it and 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 didn't feel fair to me in it 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 open the door for another person to get hired that's better than me staying there honestly um so I

wanted to do this and so that that was the main motivator to make that final step did you consider this option where you could still think 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 like you know the things like learn spend more time doing like GPU programming some more time doing

like different category things and the issue is like there is a good chance none of this is ever relevant like HashiCorp would never want this stock anyway at all so it was sort of a waste yeah I mean I think bigger big 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 HashiCorp's not at that stage and it just that never felt great to me and so at this point I know you're you're building this new terminal

emulator apart from this what's next for you nothing specifically so I am I am one I'm taking a break because I have a brand new baby at home and so I am I do want to be a good dad and focus on that and but on the other side I am really taking this time to just explore and do various things

and this all my own problems and if anything comes out of it great but there's no like specific thing that I'm going for I think that yeah the terminal emulator 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 there's actually users and things like that but it's not necessarily going to be you know like this huge focus of mine I'm not sure yet what are the other things that you are

playing it on with if you don't mind sharing yeah I mean nothing that exciting I mean I think that I've been having fun with like I said just like systems little programming to people are I mean like I've been having fun with trying to

figure out like what can I use hardware specific features for to 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 confl 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 want to do different 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 would scale super

high scale but I think that's what I think that's what I think that's what I think is really important for like that was always sort of the idea I had so back when we worked to keep our mononite wrote you know keep wasn't super high scale but we wrote a lot of the core software and see the API back ends were in Python but they called out to see stuff for the hot paths and by writing all the stuff and see we scaled to like I don't remember the exact number anymore but

it's not huge and 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 cut from the whole thing blows up so like everything becomes a atomic at that point yeah I've been like thinking like could you write I'm not doing this I'm not doing so I didn't sign anything to save this but I don't want to do infrastructure for 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 armchips it's made for these armchips 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 all they want is active at any given time and yeah I think that's really interesting to me I think people have I think of the engineer people I think engineers we've come so far we've gone so far up the attraction it's we're got 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 a questioning whether we need them I like when you say the network seemed to be reliable yeah yeah when you do your demo on three machines for two days and it doesn't go down you're like yeah this is a great change everything yeah we could go well I work at LinkedIn we still have on from machines I know when people start relying on specific machines like I

care about this host now like no you can't do it okay so you shared a lot with us about what you've spent time on what's going to come next we are running close to times 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 chain sets is 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 I like I think I I it's funny because in the email you sent me you mentioned this a lot but it is 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 a lot of 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 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 etc 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 mine zealots about any specific decision yeah how do you work with

saschival on the team because I know all of us have experience that at some point or the other where you have some core team is like sometimes even well the customers are asking for the wrong thing they shouldn't be using the stuff that's stupid like you hear all of these things these words are

very casually how do you go about working with such engineers you 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 I try 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 the balance maintenance past decisions etc 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 experience like the those those the people that think in that way are not recoverable like nine out of ten time 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 and before before let you go do you have any advice for a lot of engineers out there I know the way to open a new question yes yeah I mean I think just build stuff like I think that's the most important thing is 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 ten years only writing like JavaScript or something and that's like fine but I think you 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 non-stop for about ten years but that whole time I was doing go I would always spend breaks or free time of my own learning react whatever the newest thing learning react learning okam old learning like systems languages whatever is a new thing like I do sometimes 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 and 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 Michelle for joining us today this was an awesome conversation and we highly

encourage people to check out your block post we have you you write really well in addition to writing core 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 funny we'll just say this I think chase bank at some point was using

hashi corp as an example to tell a teach employees about startups if people want to know why they should read that block post will link it to the show and 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 Michelle this has been amazing thank you so much Michelle I thank you so much for listening to the show you can subscribe wherever you get your podcasts and learn more about us at softwaremissadventures.com

you can also write to us at hello at softwaremissadventures.com we would love to hear from you until next time take care