
Ep. #12, Earn Respect, Not Headlines with Mike Boufford
In episode 12 of Platform Builders, Christine and Isaac chat with Mike Boufford, CEO of Otti and former CTO of Greenhouse. Mike unpacks hard-earned insights on topics like leadership philosophies, management best practices, and the unexpected moments that shape company culture. This conversation blends candid war stories with practical takeaways for anyone leading technical teams.
Mike Boufford is the co-founder and CEO of Otti, a startup helping managers clarify and maintain expectations with their teams. Previously, he spent 11 years at Greenhouse as founding engineer and CTO, scaling the company from two developers to hundreds of employees and over $20M ARR. He’s known for his practical, people-first approach to technical leadership.
transcript
Isaac Nassimi: So Mike, we've got this segment we call Picks and Spang and I are going to go first, so if you don't have one ready, it's totally fine, you've got a few moments.
We just bring something that we're excited about that we've got obsessed about this week.
I think there's something about being in tech and like the personality that it attracts, that you just get really into things really quickly, very often.
For me, I've been getting into the world of micro brand watches.
I dumped the Apple Watch recently and these micro brand watches are so fun 'cause you get some pretty high quality stuff for like a few hundred bucks and there's thousands of these companies doing this, right?
You know, some of them are just little one man shops, and it really scratches that shopping itch, that hunting itch, all that kind of stuff.
And then also like bucketing things, which you know, as someone who has programming DNA in them, God, that feels good to say okay, well, this category of watches is now cleanly filled and again, you're doing it for a few hundred bucks.
Total obsession and I don't know when it's going to stop.
Christine Spang: Well, so are you sacrificing the smart features of the watch and going back to just like a clock face?
Isaac: Yeah, and the Oura Ring that I got really like, let me take off the Apple Watch and feel comfortable.
I still use like the heart rate monitor strapped for tracking the workouts, but man, it feels so good to be able to actually step away from your phone, 'cause when you have the smartwatch on, you can't actually step away from your phone.
Like, even if it's in the other room, it's still with you buzzing on your wrist and pattern interrupting your rest.
Mike Boufford: I'll say texting is not great on the Oura.
Issac: Yeah, yeah, you got to do morse code, right? That's their next feature.
Christine: It sounds like that's a lifestyle choice. I guess Isaac has decided not to text from his watch.
Isaac: Yeah, exactly, I didn't know so many people did that.
Christine: Isaac is big on focus time, you know. You got to have time to think.
Mike: I'm actually no watch 'cause there's just pervasive clocks everywhere, you know, on every device.
So, but I guess you go analog. I did explore like random Timex watches from like 25 years ago on Amazon, thinking maybe I'll get one of those like gold Timexs from like 1990.
But I didn't pull the trigger, you know, 39 bucks.
Isaac: Don't do it because it's your gateway drug.
Christine: I think I have one of those in a box in my closet also from childhood.
Isaac: I'll buy it off you.
Christine: It's probably worth more now than it was back then.
Isaac: Oh yeah. Spang, do you have a pick?
Christine: So my pick for this week is old books, but not in the way that you think. So I have an example here.
It's a book that I got at this bookstore called Dog Eared Books in San Francisco.
And you can tell it's old because you know, the pages are all red on the outside. Nobody does that anymore.
And yeah, I walked into this bookstore, not intending to buy any books, which of course, is a terrible idea.
And I somehow ended up taking this book because when I picked it up, just like the smell of the pages, you know, it's like 50 plus years, they like start, I don't know, like decomposing in some way or something, but it really has this like distinct scent.
And it reminded me of hanging out at my grandma's house when I was a kid.
She had like all these like old like magazines and like weird old books from the '70s.
You know, it's like a random sci-fi book that like, honestly, I read the first story and I thought it was a little sexist, but just having the experience of engaging with an object that's like 50 plus years old and just getting into that experience at a visceral level, I've been really enjoying as like a wind down.
Isaac: Oh God, that's so awesome. And that smell of old books is so unique.
You could identify with your eyes closed, no problem.It's actually got a name, it's called Vellichor.
Mike: Whoa. I was not expecting to learn a new word.
Christine: Just learned something new.
Isaac: Boom. Mike, do you have a pick?
Mike: For me, I think it might be like binaural beats.
You know, I don't know if you've looked at the binaural beats stuff where it kind of like kicks your brain into some sort of like focus state.
And so, for someone who is actually like, interested in a million different things and constantly context switching, it's kind of nice to have something that like triggers focus.
The rabbit hole I went down was, I was actually in Tahoe at the end of last week, you know, I'm on the East Coast is actually my first time in Tahoe.
So it was really nice, but I was having trouble falling asleep because the time shift is like three hours later.
So I found like a binaural beats thing for sleep and I'm like, "Oh, I'm going to sleep so deeply."
But instead it didn't work at all and I was just like up for the next hour listening to this weird, like vibrating sound.
So I both got into it and realized like, probably better for a daytime focus than trying to get into a trance-like zone for sleep.
Christine: Are there different kinds though?
Mike: They're at like different frequencies and supposedly, like, the wavelength of the frequency then sort of triggers different responses in your brain.
And that's as far as I could possibly go in saying that I know anything about it.
So you know, my actual like understanding of the connection between tracks on Spotify and what my brain does in response is pretty limited, but they always have like some Hertz range.
So it'll be like, you know, 68 to 79 hertz, as if I'm supposed to understand exactly what that is.
And I think there are probably connoisseurs of binaural beats who are like, I'm kind of in like 120 hertz mood, but I haven't become that level yet.
Isaac: I'm curious because this is the ultimate endorsement, how much are you pushing them on, you know, your teams and people, you know, who you work with?
Mike: I've barely advertised it just because it almost feels like taking a supplement or something where you know, you know it's probably not actually doing anything but you kind of have the placebo effect and it's working.
So it's not like I want to advertise my superstition. It may actually have some effect.
It feels like it has an effect, but at the same time like, the sort of, you know, skeptic in me is in disbelief that it actually works and I should, therefore, tell other people about it.
Isaac: Well, I mean, you are like the expert on like scaling and building engineering teams, right?
So is this one of your endorsed ways to do so or are there other methods?
Mike: This is relatively new.
I think this is more like alternative to your 400th cup of coffee during the day, you know, and trying to get into a quick focus state.
I think it's almost like a Pavlovian response where there's like, it could be literally somebody ringing a bell next to me and it's like, time to focus, ding, ding, ding.
It's just a trigger. So I don't know that that's actually going to do it.
Scaling engineering teams I think is mostly like a human exercise. So I'm not sure that, you know, specific frequencies with sound are as important as what you say, how you say it and how you make people feel in the process.
Isaac: Okay, well, tell us a little bit more about these scaling engineering teams.
You've given a number of talks and kind of became like a community icon for that act of scaling engineering teams, which I would argue is still kind of an unsolved arc in the world.
There has been no one size fits all, and I'm just wondering like, what are your key core principles for doing so.
How do you approach this kind of stuff? Like, give me the high level rundown of your mindset on scaling engineering teams.
Mike: Yeah, well, I mean, first of all I'll just say that you know, Greenhouse, I feel like I was an amateur fumbling through with intuition a little bit at first.
So, you know, I studied computer science, had been a programmer for a long time so I kind of had like a baseline technical skills to be able to do that stuff and I'd always been, I think, you know, I was like a theater kid so I was much more willing to get up in front of people and go talk about stuff than a lot of engineers.
So I had a couple of those things going for me initially.
And then at the beginning of Greenhouse, you know, it was one of those stories where you spend like, you know, 10 or 12 hours every single day programming all day, barely talking to each other for 18 months straight before you really like start getting significant traction.
So we got our very first customers who were like friends you know, at about 10 months, which was pretty early with you know, sort of working product, but then it really started taking off after 18 months.
And so, at that time I was really more like a developer, and I remember having the mindset of, you know, I want to operate in the way that I wished my peers operated when I was acting as a developer.
And so some of that was like, take the worst stuff off everyone's plate.
So like, there were the thankless tasks like dealing with data migrations, carrying around the laptop on your back when you know, just in case the site goes down even though there's maybe, like, three people using it at the time, you know, early on.
Like, doing patches and upgrades, a bunch of that sort of thankless work was the stuff that I found I need to do. I think a lot of that mindset actually came from the first startup I joined when I moved to New York in 2009, I started working for a company called Thrive.
There are like four million companies called Thrive, so it's definitely not one of the ones you're thinking of, but there is a Mint competitor, mint.com competitor called Thrive that was probably like number three in personal financial management at the time.
It got acquired by LendingTree like a week after I joined or something.
So I thought I was joining one company, and I was actually joining like a recently acquired company, and I had been consulting mostly before that.
And so when I came in, you know, I kind of got into the mode of like I want to prove myself, I want to get as much done as possible and you know, show that I'm like a valuable person as part of the team.
So I would take whatever the work was and I would try to get it done in like two or three days for the week, and then I would try to add value by picking a bunch of other things that I thought were really important to go do.
And I loved the idea of having like, a certain map discretion over what was most important to do because I wasn't just taking the cards and moving them from the left to the right.
Instead, I was also figuring out how should we actually like tackle the problems before us? What are the problems that are worth solving?
And I really liked that. The problem was I then got, you know, months and months into the role and I had succeeded in doing a bunch of those things, and I went out to coffee with this guy Ori Schnaps, who's now VP of engineering at Reddit, and he was CTO of this you know, five person engineering team at the time at Thrive.
And he took me out and I thought he was going to be like, "Dude, you're such a good developer, you are so good at writing lots of good code."
And I was going to be like, "I know, thank you."
But that was absolutely not what happened.
Instead he sat me down and he was like, "You're messing up."
And I was like, "What do you mean I'm messing up?"
And of course, like, I have like the defensive pangs.
And he was like, "You know, when you get your work done, instead of helping everyone else out on the team with all of the other work that we've all decided collectively is most important to do, you kind of go off and do what you want to do, and the team resents you for it."
And that kind of like hit me really hard because at first, I was mostly feeling like that can't possibly be true, I am contributing a ton, I should have discretion over it, but as I processed it over the course of you know, both that conversation and like the coming days, I started realizing like, I was acting kind of like a consultant even though I was part of a team and that that was kind of like a destructive tendency.
And then I needed to like have that, you know, reexamine like what role should I play in the team?
So it turned out, you know, LendingTree shut down the New York office, everyone was laid off a few weeks later.
And so, I got to kind of take this with me along with a fresh start and I went to like a big company, Thomson Reuters, and I was working as a developer, I was trying to change some of the mindset, and when I became a manager for the first time there, I kind of thought, how do I figure out how to like take the worst chair, take the worst work, like help clear the path for everyone else?
And so I got to put that into action, and then if I had some overflow beyond doing those things, I could still be creative, come up with ideas, help set the trajectory for the team.
But I think that mindset changed the relationship I had with everyone on the team.
So when I started Greenhouse, I then had not only, like, the revelation, two companies ago at that point, but then the ability to practice it a bit.
And so when I got there, you know, I was not only, you know, getting some street cred from like being the early person who got to go build that along with, you know, this other amazing developer, Mike O'Neil, we worked together at the time.
I think it was like 60% of the company was named Mike, which is, you know, classically bad startup, you know, diversity hiring in the early days.
But you know, we wound up building this thing, and because I took on a lot of the dirty work, it was really easy when other people joined just to respect me.
And so I didn't realize that it was easier to respect someone who was leading from the front and taking the dirty work than it was the person who did the most amazing thing.
And that informed a huge amount of, you know, how I approached leadership. So that just gets us to like that first moment.
Isaac: I think that makes a lot of sense to me. Here at Nylas, we've been kind of pioneering this principle of embrace the boring.
Because like the flashy, fun features as a developer are really fun to work on, but the stuff that creates the most value, helps the team the most, helps the company the most, it's always the stuff that like, nobody wants to do.
And it's funny, what you were kind of describing is I think what a lot of good developers run into, 'cause they feel very powerful is like, this pseudo like main character syndrome, right?
Where they're like, I'm going to save the company by like coming up with these like ideas and just going off and doing them and nobody, you're right, nobody agreed on these things.
I'm kind of wondering how long did it take you to actually start like implementing that feedback?
Because I got that kind of feedback when I was a young engineer and man, I was super defensive about it, I didn't take it well, and then it just kind of dug its way into my brain like this earworm over the following year, I remember.
Mike: Yeah, I mean, I think the timing where like everyone got laid off shortly thereafter was actually probably good in a way because I got a fresh start.
You know, it probably would've been harder to have a team that already did feel resentful of me and say, "You know what? I'm going to start changing my behavior, just watch. That's going to result in me being a great team player."
In some ways, like, the bandaid just got ripped off automatically and I was in a new environment.
So I think it was actually internalized really over, like, a long period of time because at first, anytime you get feedback like that, you take it about yourself.
And so, it's sort of like how do I fit in? And in some ways, like when you accept a bit of negative feedback, you almost accept that like, this is an abnormally bad thing about me that I need to change.
And so in building a team though, you start seeing like the shadow of all of those behaviors that you changed in yourself and they're really noticeable when you see them in others.
And so, I got to reuse that advice a number of different times throughout my career. And not everybody always has the revelation.
Sometimes they hear it and they're just like, "My boss doesn't appreciate the cool stuff I do," you know?
But other times, you know, it's kind of like life changing because you know, whatever you can do, you know, on your own, you can probably do a lot more with a team, and if you want the team to be with you without having to drag them along or force them along, you kind of have to earn their respect.
And so if you think instead, not what's going to get me the most notoriety, not what's going to be the most fun, but what's going to earn the respect of the team, and that's where the ultimate leadership mandate comes from.
It's like, they are supportive of you, then that probably gives you like, the right list of stuff to do internally.
And then you have like this sort of dual role of, well, I also have external stakeholders like the company or you know, customers or whoever they are, and they have needs too.
So like, one maybe general insight is like you gain respect from people internally when you figure out how do I meet their needs and make the focus about how to meet their needs.
And similarly, when you're trying to sort of like survive the startup gauntlet, right?
Somehow, by miracle, I like lasted like 11 years and then you know, decided to go off to do my own, you know, sort of new thing after Greenhouse, like, I think one of the reasons that I was able to stick it out was because I was trying to think, like, what are the customer needs?
Well, the customers, you know, need the site to stay up so they need to feel validated when we make a mistake.
They need to believe that this is actually the best product, and so what does it take to do those things? So I think starting from a place of analyzing the needs of the people around you ends up giving you the right list of things overall.
Isaac: Well, I mean, I'm biased here, but it almost sounds like you're saying to adopt a product mindset, right? Like, what are the acceptance criteria?
What's going to drive the most value and operate in that way? Rather than, I think a lot of engineers fall into like, how can I do the best engineering, and that's it.
You've kind of described the individual like, hey, here's how you should think about this stuff.
But I got to say, I mean, and you've run this track, one of the two hardest things of becoming a manager is learning how to have these hard conversations of, "hey, you're not doing well."
And when you're a new manager, you screw those conversations up so much and you don't end up getting the results that you want out of your people and they suffer and you suffer.
How do you recommend approaching those kinds of conversations?
Mike: Yeah, I mean, I think it's complex. So like as a manager, it's hard to realize that you have like a dual agency problem.
You know, you are both supposed to represent the interests of all the people on your team, treat them well, treat them with respect, make sure that you're looking out for them.
At the same time, you can't just do that, you know, to the detriment of the company or you're not doing your job.
And you can't just do what the company's asking you to do and treat all of the people on your team like cogs or you're not doing your job and you're probably, you know, not going to end up making it.
So I think one of the most important things is like figuring out how do I balance those two things and like reconcile within myself what I think the job description is.
And so ultimately, like you're getting paid by the company and the best, most effective way for you to do your job is to provide support to everybody on your team to help them be at their best.
And then if it's not possible to get them over the next threshold, then to make sure that, you know, you take appropriate action to balance the energy of the team.
Because it's almost always the case, as anyone who's ever had to let someone go has experienced, sometimes you make the wrong decision, but usually it's like a really labored hard decision to make and you've probably tried a bunch of stuff first, unless you're like a sociopath, to try to make it work.
And at that point when you have to let someone go, it does feel a little bit like I have to, like, this is going to, you know, if I don't do this, this is going to result in more misery.
There's almost like that philosophical idea of like, how much utility is there in one decision or another, like how much goodness is on the other side?
Well, if you have like five people who are all miserable because you know person X is on the team and they're making everything difficult for them and they're like 40% less happy than they would be at work, well, some of those things together and they're sort of like, you know, let's say 200 points of value to get back in letting the person go, but you're maybe sacrificing 100 points of value for them because they're getting the self-esteem hit, they're feeling bad, you're going to have to maybe hire a new person and backfill, you know, there's going to be a disruptive moment for the team, where even those who don't get in trouble or let go as a result feel nervous about their own jobs.
So that's the dual agency problem.
In terms of actually approaching it, like the first thing that people don't do is say what's expected.
And I think that like a lot of times if you ask HR about expectations, they might point you to writing down stuff in a career ladder or taking a look at a job description and using those as an anchor point for conversations.
And I think that works for part of the job, right? Like, we expect you to release great code.
Okay, so now I've defined something that's incredibly fuzzy, let's say, or like, you know, startup mindset or whatever it is, right?
And I've been someone who's authored those things as well, but then there's like, how do I interpret that thing and not just how do I interpret it globally, but situationally?
So, you know, there's an example I often end up giving when talking about our new product, you know, Otti, which is, you know, supposed to help managers do the right stuff throughout the year.
So like, you know, that definition can be a little bit different, but part of it is like, you know, how do you let people know the sort of hidden expectations that might exist in a manager's head.
So let's say that you have a person who is working really hard on getting a feature done, and they realize there's a critical bug, and the manager has gone around all week long and said, "Hey, we are, you know, going to hit the deadline. This thing's going to be done on Friday."
They've informed marketing and you know, their boss that, you know, the project is on track and then the developer delivers it at daily.
They deliver it a day, late working nights every single night for the entire week to make sure that the critical bug is fixed at the end.
So in that developer's mind, they're probably thinking like, I focused on quality and that was the most important thing, and if I released this thing that was not going to work, it wouldn't matter if it was released on time.
And the manager might be thinking the exact opposite.
They're like, why are you putting, you know, sort of polish on a pedestal when what really mattered was us being able to honor our commitments and get it done on time?
Now, that's like an individual value judgment and a situational value judgment. That is never going to be in the job description.
And so one of the big failure modes I think managers run into is they think that the high level definition is enough of what's expected of them in their role, and they don't end up having those little conversations where they both show understanding for the other person's perspective, 'cause they often have like a legitimate subjective argument for why they did what they did, and making clear why they thought what they thought so that they can come together.
So if you think about like a boat, you know, the sort of boat analogy of like, you're three degrees off course and you know you don't correct your course for, you know, three days, all of a sudden you're like on a different continent.
But if instead you're making a bunch of little micro adjustments over the course of the year, then you end up being able to get to your destination, you know, sort of reliably.
And so that's kind of how I think about it is like try to make sure that you're clear on what the overall expectations are but also all the little micro expectations as they go.
And that also like decreases the weight of each conversation, 'cause they're all small.
Isaac: Yeah, I think it makes a lot of sense to me, and you know, in areas where things are like clearly defined for giving feedback, like, everyone knows this, like, I have a very bad cat, and if you discipline the cat 20 seconds after they do the thing, they've already forgotten about it.
I'm not comparing employees to cats or anything like that, but I think this is like a universal constant amongst like all beings that have consciousness where if you don't give some immediate level of feedback, then you're going to have to do a huge like intervention that's real uncomfortable for all parties down the road and oftentimes it's just too late.
So I really liked the little things, and then something that also really popped out to me there was you have to set expectations.
I think my last CEO said this to me, which is you can't hold someone accountable to an expectation you didn't tell them.
And so often, we just assume we're like, yeah, like they're an engineer, they know what to do.
No, it's so hard to figure out that alignment between like what's going to help the company the most, what does success look like?
There's a reason you have to say it, I think it's fantastic.
Mike: Yeah, let me actually show you something. This was not planned by the way.
There's a sticker over here from someone who's doing some product prioritization stuff and by the way, I'm like an epic strange drawings person, and so I had been frustrated that something I wanted prioritized.
So I put this on the task, and for anyone who's only listening to audio, it says, "Manage the backlog according to my hidden expectations," because that's kind of what you actually want everyone to do.
It's like I just want you to do the right stuff and the right stuff is whatever I think is the right stuff as a manager or like that's your sort of like, you know, I am the center of the universe, you know, mindset that we all end up having day-to-day but if they don't actually know what you want, like there's no way for them to actually use that information and do something about it.
The other thing that you said that kind of like, you know, rang a bell for me and like maybe you do have a bad cat but like that's not a very growth mindset thing to say, like, you know, maybe the cat's not bad.
The bad thing is like the behavior. The cat like rips up your couch or like, you know, interrupts your Zoom calls with like a tail to the chin or something or whatever, you know, whatever the issues are.
And so, that's actually I think another fairly common failure mode is that whether it's expressed externally or that's just a thought that you end up having, you get really frustrated with a person and you start like categorizing them in a certain way and then that lens gets put onto everything, right?
It's like, so let's say that manager who is frustrated that that one project didn't get delivered on time, what if they now think, you know, this person's unreliable, and like that's now a lens?
So it's like, oh, you know what? They said that they were going to get this done by 2:00 but it was 3:00, that's because they're unreliable.
Whereas somebody else, they might have been like, who cares, right?
And so they start confirming whatever belief they have about the person because the label itself makes it not behavioral, not an instance, but instead a sort of intrinsic property.
And I think that's often where like employees and managers get stuck in their relationship is that they're in a world that feels unchangeable because they're thinking of each other in terms of like intrinsic traits. They're not able to evolve going forward anymore.
It's like you don't care about quality and you don't care about, you know, getting things done on time.
Isaac: I think that's so true. I think there are very few static traits in people, even like being intelligent.
Like, there's smart people that go through a streak of time where they do some really dumb stuff.
Just 'cause someone's smart doesn't mean they're smart forever, just 'cause someone is bad or checked out or good or whatever, I really agree with like not putting these permanent labels on them because they tend to be self-fulfilling prophecies, right?
Because you've kind of given up on them, like I've given up on my cat, that's why I call her bad cat.
And it's just going to put that person in a box and not give them the opportunity to climb out of it, essentially.
Mike: Yeah, and then, you know, I guess maybe back on the topic of like scaling teams, I do think, you know, to whatever degree that you all, you know, sort of want to explore--
I think there are really different chapters that every engineering leader in particular has to move through over time, and probably the fundamental thread throughout it is that you have to stay in a sort of adaptive or malleable state for a really extended period of time.
I think the people who end up succeeding in management are not just good at how do I deal with people and process, but how do I actually stay adaptive in an environment that's changing around me all the time?
Like the shape of the puzzle to go solve is evolving 'cause the shape of the puzzle pieces is changing too.
And so I'm curious like, you know, with building Nylas as well, just to dive in, like, what were the most sort of interesting or challenging scaling moments you all ran into where you were like, oh, actually, we have to do stuff differently now?
Christine: Mm-hmm, yeah, it's interesting, Mike, 'cause I kind of feel like you have, like a similar path to me at Greenhouse where like, you joined really as like the first engineer.
You were like hands on keyboard, writing code for 12 hours a day, and you know, I was kind of in the same boat at Nylas.
You know, I was a founder but you know, I really like built a lot of the initial version of the product, and then like at a certain point, it was like, okay, we need some more engineers here so we got to go out and recruit.
And like you know, the first awkward thing is like, oh, I got to do essentially sales for like people, you know, convince them to join my company that nobody has ever heard of and really like tapping connections, because you know, how else are people going to get trust with like, essentially like a brand that is completely unknown and benefits that are completely uncompetitive?
So you know, I think there's like, a few phases that I can think of.
You know, one is the kind of first phase where you're just like able to make assumptions because you have enough similarities between you and like all the other people that are working on something.
So like, you know at Nylas, basically I went out, recruited a bunch of other people who were like MIT nerds, and we had like a shared kind of like, cultural alignment there, and that allowed us to get just like get away with not having as much like explicit conversations about like expectations and things like that, and just like have really high bandwidth interactions without like a structure.
And then, you know, eventually we didn't all fit in the same room anymore.
And I personally went through this transition of like, okay, I'm not a engineer anymore, I need to figure out how to run a team.
And I had like a total crisis and went out and tried to talk to every single person I knew, you know, I was like 25, and I didn't really know many people in these like management leadership positions.
I had like three people and I went out called all of them up and I was like, "How do I run a team?"
Because you start to have to have some sort of structure, otherwise like nothing gets done anymore.
The other phases I could think of is like, when we got to be more than like 30 people, because you not only have to have like, a structure for the work but you also have to like have, like, multiple teams and ways of like splitting up that work in more sophisticated fashions, and the people stuff gets more complicated.
And then you know, I think we also went distributed at some point and that changed everything.
And I know that you went through the same thing at Greenhouse. And also like how fast the change happens really impacts like what the result is.
And I know that at Greenhouse, you had a couple years where like things were growing super fast, and that really changes how you have to think one step ahead because if everything's going to be different in six months, that's different than if everything's going to be different in two years.
I'm curious what similar experiences or different ones did you have at Greenhouse?
Mike: Yeah, I think there definitely were parallel universes.
Like yeah, learning how to sell people on coming and it's like your own excitement and like yeah it's going to be different in a bunch of ways to being at a startup.
You'll be like more empowered, you'll be able to do this and that.
So there's kind of like a, you know, for the right type of person, they're going to select into the additional pressure, the additional freedom, like the additional responsibility.
But I think that phase you were talking about where you know you have more or less time when you're going through one of the change cycles I think is super relevant.
So if I think about between 2013 and 2015, we wound up going from a couple of developers to about 40, I think I had like 40 developers, no, maybe the company was 42 people, and I had like half the company.
I think that might have been the case in like early 2015.
And then by the end of 2015, we had 200 people in the company, and I had like 40 people on my team.
So we went from like two to 40. And so you're right, there's like all of this structural stuff and you're dealing with what's probably an immature product.
So like at Greenhouse, it was like, okay, well, now we need better search so we're going to set up search instances, and then we have to realize, oh, how do we make it like HA, how do we make everything HA, you know?
How do we like decrease the blast radius of change? How do we make sure people can still be productive?
The code base starts sprawling, it's harder to understand, how do you onboard new people, how do you carve up teams in the work?
So like, all of those things were really tough and I actually think that one of the blessings in disguise for me personally was that we missed our sales target by like a tiny bit, and that all of a sudden meant that we were going to sort of slow down a little.
So you know, Greenhouse was able to get to I think by the end of 2015, so in less than I guess really, only two and a half years or so in market, we'd gotten like $22.6 million of ARR, which was like, you know, tremendous growth.
So we went from like zero to three and a half, three and a half to 12.6, 12.6 to 22 point, you know, four, 22.6 or whatever it was.
But because it wasn't 100% year over year growth and we had been doing this sort of like triple, triple, double, all of a sudden, we then said, "You know what? This affects like our access to capital."
We'd raised a series A, series B and series C in 18 months, or it might have been shorter, I think it might have been like a 14 month period or something 'cause we were growing so quickly, and so we knew we needed to, you know, conduct a small rift.
So we like, you know, reduced, you know, staff by about 10% at the time, which was really painful, we had, you know, more emphasis on getting efficient, we had, you know, still really fast growth sustained, but it kind of felt like I had the pace slowed down enough that I could grow into my new job.
So it wasn't just absolutely pedal to the metal for the entire time. That was a little bit of a slower period for a couple of years.
It allowed the platform to get stable, it allowed for us to make like architectural changes that would end up, you know, really working long term, it allowed us to pay down a bunch of debt and deal with bugs and expand the surface area of the product.
I got better at managing because, you know, I went through more stuff over time so I had more time to like bake those experiences in.
So then we went through another pretty fast period of change and scaling and I think like 2017 or 2018, so like a couple of years later, things really started humming again.
We started growing, you know, a lot faster, we'd like solved a bunch of the puzzles that allow you to start growing faster again.
And I was kind of ready for that next phase and had matured a bunch, and if I didn't have that, I think that there's a pretty good chance that I would've, you know, been, it would've been like, you know what?
Thank you for your service. We have to hire somebody who actually knows what they're doing for the next phase.
So those pauses are potentially really valuable.
I don't know if your experience is similar, but like you know, when you hit a slower patch, it does give you like a chance to learn.
Christine: Yeah, I'm really curious about these growth spurts.
Like, what do you think just like came together in order to like, allow that really rapid growth in a short period of time?
Mike: I think it's different at different times.
So like at the very beginning, you know, the founders of Greenhouse first came up with a really well-informed idea about how to go solve the recruiting problem.
We got lucky with a couple of different things. So just to dive into some of those for a minute at the beginning.
So there had been studies for years and years and this is all kind of taken for granted and is a norm now that structured interviewing, like figuring out what it is that you need somebody to do in a job and then how do you figure out what questions would help you understand whether they could do it well, and then ask specifically those questions in the same form over and over again for the candidate pool actually result in better hires.
So this was like known in academia, and people were doing it in spreadsheets and docs at the most sophisticated companies, but they were not doing it with their applicant tracking system because it didn't support that.
And so, that was probably like, the most important innovation number one.
And so during the period where you have a lot of Silicon Valley startups, you know, this is post Great Recession, ZERP starting to really scale up quickly, they had this problem of repeatability, I have to hire like 100 or 500 software engineers so it's worth investing upfront effort and making sure like the template for how we do that well is, you know, sort of rock solid, we can iterate on it over time.
So Greenhouse went out with that value proposition.
We also had some like lucky little product breaks, where like I remember we were having a conversation in the early days where it was like me and one other engineer and the two founders where it was like, okay, I guess it's time for us to go build like, the job board portal where you have to like log in and then you apply for jobs through it.
I don't know if you remember prior to 2012, that was 100% of the way you applied to jobs online.
Like, you always had to go create an account.
And I remember just being like, "Do you have to create an account? Like, couldn't we just use their email address to communicate with them? Like, do they have to go through that extra step?"
And it was like, huh, maybe we don't.
And so then we also had the first job application form that didn't require you to sign up in order to apply for a job and people saw like a 30 or 50% lift in application rates because it was less hard, and there was like a real demand for candidates at the time.
It was not like AI spam.
And so I think those things, plus the economic moment we were in, allowed us to go out to the talent partners at a bunch of VC funds and say, "Hey, we think we have a solution to scaling up, you know, at a higher quality level in a better way."
They shared it with their portfolio companies, and within our first 20 customers we had Airbnb, Pinterest, Uber, Snapchat, and WeWork and I think some other, you know, unicorns on top of that.
And so that was pretty wild. So it was like, you know, the best of the best started using the product right away, and they scaled from, I think Snapchat might have been 12 people, I think they negotiated a $6,000 contract, three years later they were going public, and we hadn't figured out how to charge them any more despite now being like 3,000 people or something.
Airbnb went from 250 to like many thousands. Uber, similar. Pinterest, I think it was like 80 people at the time.
So that all went well and then I think there was the social conversation of like here's a better way and you know, all of Silicon Valley kind of hopped on board.
The later phases of fast growth were like totally different and a lot of them were how do we figure out how to position ourselves well in the market?
How do we create a good repeatability? How do we create a more elevated brand so we can go after larger accounts?
You know, how do we knock down the enterprise features required in order to be able to successfully service a, you know, four or five, 10,000 person company?
And so a bunch of those puzzles needed to be worked on simultaneously, and I think that was, you know, that plus like the right leaders at the right time in certain roles, you know, around sales and marketing in particular I think really helped.
And that's what, you know, sort of let the next wave really, really work.
So it's always probably like a little bit of a different formula depending on the phase.
How about you? I mean, what, were there like sort of moments that were similar for you?
Christine: Yeah, hearing about how the digital insight was like, structured interviewing and essentially like scaling that and making repeatable just really drives home to me how much has changed over the last 10 years.
Like, that's almost like the water, like, in hiring at this point.
It's like of course you have to do that, that's like a no-brainer.
I mean, it's pretty sweet to feel like you guys kind of made that happen at Greenhouse.
Mike: Yeah, no it is really cool.
Definitely not my insight and even the founders, I think they like went and discovered you know, what the best practices were and devised a way to make it happen inside in the products.
But I do think that there's like an interesting insight maybe that's transferrable to other people as well where if there's already a bunch of research in your discipline, what were the best ideas that people believe in that have not yet been implemented in the software everyone uses?
That that might be like a good way of discovering something that sort of like pre-built to resonate and has pre-built evidence to support the approach.
Christine: Yeah, it also really just drives home how like SaaS and the tools drive culture and best practices and it's kind of this like virtuous circle where you know, you're not just shipping like a technology that makes you more efficient, it's also like encoding workflows that produce better results.
And that's a lot of what people are buying as well, not just a tool to help them get something done.
Like they actually don't know like, what is the best practice in order to achieve the best results here.
And you know, a business with a focus on recruiting, you know, your job is to help people also discover like what is the right way to do this.
Mike: Yeah, totally, and so, one of the interesting insights actually with the current business that I'm working on, Otti, was that like, you know, you go through the recruiting process, there's clear stuff you're looking for as part of the job, then you get hired and it all disappears.
Like it's almost never that you're then having clear conversations about what those expectations were, how things are going, how they relate to the work that you're doing once you actually enter the company.
And so, you know, how do we help solve for making sure that people do actually understand, like, what it looks like to succeed in their job and that managers are playing an active role in helping them succeed in their job.
So I think that same insight interestingly, could still be pulled forward, 'cause while it is the water down recruiting, it's not yet the water actually management even though it's sort of obviously a better way.
Christine: That's super cool.
You know, I'm really curious about, you know, throughout these scaling periods, like it must've been really key, you know, your relationships with like the other key stakeholders and functions between like sales and marketing and like your CEO.
Were there any things that, like you did to make sure that you guys were super well aligned and like what did that back and forth look like?
As a CTO, you're balancing all sorts of things, like, you know, well, we can't ship X feature because we have to like, you know, migrate the database because you know, it's falling over because of, you know, we added 10X the scale in the last six months, we need some slack time to take care of this stuff, and then we can do this thing, et cetera, et cetera?
Mike: Yeah, I mean, I think cross-functional work was probably my greatest learning curve actually at Greenhouse.
Just figuring out how do I work with people in different functions and you know, both from a relationship and priority perspective.
So the first thing that I did, and this is more about like my own imposter syndrome, you know, as a CTO, was like I want to understand what everyone else's job is, 'cause like I don't know what a marketer does, I don't know what a salesperson does day to day, you know, I don't know how finance thinks about things.
So I did have like a little trick that I still recommend to people. It's time consuming, but most definitely worth it. Read a couple of books that are the famous books that everyone's read on all of those other functions, like every other function of the business.
So, you know, if you want to learn about sales, read like "The Challenger Sale," "Spin Selling," stuff like that, if you, you know, I wound up doing an online certificate in financial management so I could talk to the finance people and the board better.
I wound up reading a bunch of marketing books, I read books on customer support, on customer success, on, you know, product management, on design.
Like, and I think that gave me not only like, some common language, but like a bit of an understanding of what mental framework they had for how they thought about the world.
It didn't make me an expert but it allowed me to sort of like speak enough that we could hold a conversation on the topic and I could understand more of what they were talking about.
You know, it's like if you go to a foreign country, I don't know if you'd speak any other languages, but if you like speak like this much, they immediately, like if they know English, they're going to like switch to English and like you're not actually going to get to practice.
If you speak like this much, then they'll probably like talk to you for a little bit, even if they are better at English because like there's a sort of window of tolerance and your effort has been like demonstrated.
And so, they want to like engage with that. And I think that's true with cross-functional collaboration as well.
The other thing I learned that I think is hard for CTOs is like the way of thinking and collaborating with others or taking feedback can be really different in other teams.
You know, engineers I think are taught to think how do I get to the best solution no matter what?
And we beat up each other's ideas and we examine approaches as if they're not personal 'cause they're not.
And like you kind of get that real feeling of like, you know, whether we choose to go, you know, down path A or path B in terms of architectural decision making, it's not because like I am good or bad, we should get to like whatever the best algorithm is and we can almost like mathematically, or we could mathematically prove this was the best choice.
And so like, you know, let's not debate it on, you know, subjective merits, let's debate it on, it's like, you know, objective merits.
That's definitely not true with how work feels in most other functions of the business, that for most people, they are investing a lot of energy personally in whatever it is that they're building and they're not practiced in the same way.
And I'm not saying that from a sort of, you know, superiority complex sense of like, engineers know how to do this better, it's just a different culture, that like, you know, they're not practiced in thinking about their ideas as being totally separate from themselves.
And so exploring like, well, what about all of these other things could feel antagonizing or like condescending of like, have you not thought through this thing thoroughly?
Because you know, we're professionals at thinking through things. Maybe you need an engineer to help you in sales or something.
So I think that was like a little bit of a thing, that I had to learn some communication style tweaks to demonstrate clearly that like, yes, I do understand that you're as smart as me, yes, I understand that you actually know way more about your discipline than I do, and like how do I have like good exploratory conversations so that we can like collaborate together on getting to whatever the best outcome is?
And so, that's kind of nuanced.
I definitely don't have like an automatic tip or trick, but literally just being aware of the fact that people are going to process feedback or even analysis of their work in a really different way outside of engineering than inside of engineering.
I can feel it now by the way. Like, now I'm sort of doing like, the early founder led sales stuff, and like my mood is dictated in some ways by like, oh, that was great meeting, I'm feeling awesome.
Like, everything is great. And then the opposite thing happens and like I had a bad meeting like, you know, and you kind of like get your emotions entangled with your work.
I didn't feel that way as an engineer and I definitely felt that way more doing so sort of sales type work.
And so building empathy for like the different experiences people are having when they're doing their job and modulating communication a bit.
Christine: That reminds me about how kind of, at early Nylas, we had an office that was just like one big room, and you know, we had engineering on one side, we had sales and marketing on the other side.
And sales wanted to play music all the time in the office, 'cause they're like, "We got to get hyped for our calls."
And the engineers were like, "We need to concentrate. You know, we want quiet, like, no, like low key vibes."
And I don't think we ever figured out a solution for that.
I just came away with it of like, you know, different people have different needs and like, you know, the way sales needs to show up at work is very different from the way the engineering needs to show up at work.
Mike: Yeah, totally, and so I think Greenhouse eventually wound up with just like different floors.
Christine: Yeah, just got to give people their own space.
Mike: Yeah, but actually I had a little thing that I did almost just purely out of excitement that I think did a huge amount to build empathy functionally.
I wound up doing this thing with the very first AEs at Greenhouse and kept doing it all the way through when I left called Coffee is for Closers.
And so anybody who hit their quota, I would buy a coffee every single month and I would make sure they all knew like, you know, I want to run up this bill as high as possible, and I would pay for it out of my own personal bank account too.
It was like, not like a company expense, it was like, you know, I'm happy to buy $80 worth of coffee.
That just meant like 20 AEs, like, hit their quota or whatever it is.
And so when I bought them coffee, it wasn't just about like giving them a thing, it was spending time with them.
And then I got to understand like from the, you know, there's some SMB AE who started six months ago, like, what's been easy, what's been hard?
You know, what are you running into?
What are the biggest like issues that are happening day to day?
Like, what's painful about onboarding?
You know, then I wound up building these really close relationships where individual contributors and other departments wound up trusting me as, you know, part of their world and they saw that I took an interest in it.
So I think taking an interest in like not just the other execs, especially if you're in exec role, but like getting to know the people who are actually doing the work across the company isn't just like instructive.
It's like, you know, it actually like, I think shapes that empathy and understanding for what's happening.
Like SDR, it's like, yeah, it's a hard job. It's hard to do that all day every day.
We should like respect the difficulty of it.
Christine: Mm-hmm, that's a really cool way of just kind of breaking down the silos that happen between different functions.
Was there like a key moment or like a friction point or story around like what caused you to decide, I need to understand better, like, what it's like to be in sales or what it's like to be in marketing?
Mike: I think it was the off by one on being a founder thing actually was probably it.
So it was like, yeah, both of the founders of Greenhouse and you know, they were about 10 years older than me.
They'd already been successful in their careers. And I was sort of younger at the time when I first started, and I was there to learn.
And so, you know, as the company progressed, I could see that, okay, I'm like leading engineering and that part's going well, but I really kind of wanted to make sure that I could be part of any conversation.
And I did know that they understood how the whole business worked together.
That like, you know, and they're smart, good mechanical thinkers.
And so they understood how, you know, the funnel went from people getting awareness, you know, that the brand exists and social validation from others.
And you know, then they see a white paper and they continue moving down the funnel all the way to becoming a sale.
And once they're, you know, a sale, then they get onboarded. If you do fail to onboard them successfully, then there's a failure point there.
If you onboard them successfully, then they stick around.
Now how do you prove value as they, you know, stay with you?
How do you figure out how to expand the account?
How do you figure out to sell them, you know, how to sell them more products and how do you balance all those things with the finances and you know, people problems that are happening around?
So there was this complex understanding of the physics of a company that they had. And I could see that I understood bits and pieces of it. And when I didn't understand one of the pieces, it was almost like now I can't speak the same language anymore.
Like, you just switch into a language I don't understand.
And, you know, I had a personal feeling of frustration, not at the other person, but like with myself anytime I, you know, hadn't learned the vocabulary to be able to participate in the conversation.
And I realized the more I understood, not just like the vocabulary and the ideas that they, you know, had going through their head about how to run a business, the better I actually could leverage my own intuitions in making decisions within engineering.
So I'll give you an example of one of the moments.
So Thoughtworks I think had a Beijing office and Thoughtworks has been a Greenhouse customer for a really long time, still a Greenhouse customer, you know, and a great partner over the years. So lots of respect.
They had a Beijing office. And so all of a sudden they were like, you know, "We're having all these like great firewall issues," this is like 2016, the, you know, things are getting blocked, connections are getting dropped, like assets aren't loading.
And so as an engineer I'm kind of like, well, we have to fix that problem for them.
Like, we can't just like let them have a bad experience in China.
Like, this is one of our big customers. Like, we have to make sure it works.
And so, I had added to my roadmap for like engineering projects for the quarter, like, fix the great firewall problems and started spending time talking to a bunch of people about like different things that you could do for that.
And I remember, you know, there was actually a workaround, like you could get people to get on a VPN and when they were on the VPN, it might be a little bit slower, but it did work.
Now what I didn't understand was like, they were kind of like the only company having that problem and there was a workaround.
The business decision I was about to make was to spend let's say hundreds of thousands of dollars plus some opportunity cost on solving this problem for this one customer.
And it was not actually like, the right value judgment for that moment.
We actually wound up maybe two years later investing a bunch and fixing more of those things so that it would work, you know, for people who are in a similar situation.
And it did make sense at the time to do it. We had a broader customer base, there wasn't a workaround for all of those issues.
And so, understanding like how to make good reasoned business decisions, not just based on whatever it seems like the biggest fire this second requires a little bit of like, you know, I guess sophistication, understanding what the trade offs are and you know, why A is more important than B.
I'm sure you've run into similar classes of issues, but that was one with China that I remember.
Isaac: I have a question.
I love asking this to people because they're always fun stories and usually it's far enough in the past that you can laugh at it, but like, you know, you've been in all parts of these businesses that have had these massive, massive scaling issues that you've run into that you've managed to overcome and all that.
I'm curious, do you have any fun stories of like big mistakes you made, either on the engineering side, the personnel side and you know, that kind of stuff?
Mike: Yeah, so you remember the Tres Comas scene from Silicon Valley?
Isaac: Yeah, yeah, from like, the wine he had, right?
Mike: So he had like made his, you know, billionaire tequila and then someone had left the tequila bottle, like, on the keyboard and that wound up, you know, causing the site to go down like over and over again.
One week later, it's Friday night, you know, everyone's hanging out in the office after a good long work week, you know, I have a whiskey at hand, it's like maybe 8:00 PM, and there's probably still like, you know, a couple dozen people there or something like that.
And then all of a sudden one of the engineers comes up and like very calmly was just like, "Site's down."
I'm like, "Ah shit."
You know, it's like, you know, relatively early, happens sometimes.
So, but you know, you got to go deal with it right that second.
And so, I go over to my keyboard and I like, you know, open up a terminal and start trying to figure out what's going on, and you know, I'm like, you know, found the logs of what's happening and we're getting like absolutely slammed.
So I'm like, "Oh my God, it's like, there's like a denial of service attack happening right now."
And then I start, you know, looking and figuring out where the IP address is and I'm like, "It's coming from inside the office."
I'm like, "Oh my God, we're being like attacked. Someone's like, you know, everybody checked the closets, like, see who's like hiding in our office, like, doing an in-office denial of service attack,"
And someone goes, "Maybe it's like that Silicon Valley scene."
And I am like, "Shit." So one of the product managers, this guy Murph, I was like, "Can you just like go run around and see like, on the off chance that is true that that might be happening."
Turned out our head of customer success, which is perfect because she was the one that had to deal with the problem later, had put her headphones down on the space key while inside of a backend search bar that had no rate limiting.
So it was like only in a system that we would use anyway, but we hadn't rate limited it.
And so, she was like DDoSing our website by like having, you know, millions of requests go through on like Turbo Mode from her keyboard on this un-rate-limited search box.
So that actually happened in real life at Greenhouse, and we took down the site for like, you know, 10 minutes or something with headphones on a keyboard.
Isaac: Those search queries are always, like, the most intense on the database as well, of course.
Mike: Yeah, well, actually, yeah, it was like an open search query too.
So it was like, you know, select star from, you know, the table and there was like, you know, where it was an empty value, like on an unindexed.
Christine: Like a "like query?"
Mike: Yeah, yeah, exactly.
Christine: Oh God.
Isaac: On that front, I don't think I've ever had a moment where I'm like, oh, I want to hold this key down on the keyboard and have it fire over and over again.
I don't know who asked for that feature.
Mike: Yeah. I remember Turbo Mode used to be a thing, you know, back in like the late '80s, early '90s, and it was for gaming, it was so I, you know, could just hold down Space Bar and continue shooting monsters in "Dim."
So that's at 43. I know the origin story.
Isaac: That's awesome.
Christine: So we're getting to be almost out of time here, but before we wrap, you in the last couple years, left Greenhouse and are working on a new thing.
What's it like to start fresh again? And you're the CEO now, you're the boss.
Mike: I am. Well I'm now, I guess the boss of like nine people, whereas I had hundred right now, so.
Christine: Is it an upgrade or a downgrade?
Mike: Well, totally different in every way. I mean, it's been like exactly what I expected in some ways.
So, you know, upsides are, I'm in the game that I want to play, right? Like, I chose like what to go do.
And I get to realize a lot of, you know, the vision in my head of like how things should be and get to, you know, sort of like quantum leap style, like, right the wrongs of the past.
Like, what can I do differently this time, you know, from the mistakes I made, you know, my previous go around?
And at the same time like, you know, any person who's ever actually gone through this having journey, like it's hard.
The first couple years are hard. They were hard, you know, at Greenhouse when I wasn't a founder and I was the founding engineer, and you know, there's just a million puzzles to solve.
I think that's like the best way to describe it. It's like you start with literally nothing.
You don't have a name, you don't have a logo, you don't know what you're going after, you don't have a validated idea about how to solve a problem, you have no product, you have no customers, you have nothing, right?
And so starting from nothing is intimidating, but there's like an infinitely open world, and then you have to start making a bunch of decisions, and each of those decisions both make the thing more real and constrain other options.
Like, now that you're doing this, you can't do that. So like, now that we're making, you know, software in management, we're definitely not going to make like a video game, you know, that's like a "Pokemon" spinoff or whatever, right?
Like, you're not going to do certain things once you've made decisions and it's kind of like a, you know, it's Markov chain, just to be like a total nerd. It's like, you know, and so, I think that that's, you know, all been super interesting and I think we've mostly made good decisions, but then you also make lots and lots of bad decisions along the way and you're like, you know, how do I remedy those or which ones do I accept as I go?
So I think it's been exactly as I would've expected, high amplitude feelings of, Oh my God, we got it, and you know, the inevitable lows where you're like, you know, there's 85 more puzzles that I have to solve in the next year, right?
And if I don't solve, you know, 82 of them, like, you know, then, you know, there's that feeling of like, the company will fail or something.
You know, I just came back from a founder retreat I'd mentioned, I, you know, went to to Tahoe, and I was like a founder retreat with 50 other founders of a bunch of different companies doing all manner of things.
And they all kind of have the same feeling, which is like, you know--
The success of the company is really closely linked to how you feel about yourself in a way that isn't necessarily the most healthy, but it is a pervasive experience, that when you get to be the CEO and founder, you get to build your own vision. It does feel very personal.
And so, I think that's maybe a struggle, but I think one that is, I think 100% of people end up feeling, as the person who's on stage talking about this mentioned, unless you're a sociopath.
Christine: Yeah, I think, you know, there's kind of like, twin devils here that map to the rollercoaster.
There's the feeling of agency, you know, you could change anything, you can make anything, the rules, you can do whatever you want because you know, you're the one who's driving this new thing.
And at the same time, like, if it doesn't work out and if it fails, you have nobody else to blame but yourself.
Mike: That's right.
Christine: And yeah, there's times when you feel like you're on top of the world and then there's times when you feel like you're depressed and it's never going to work.
And I think one of the keys is to like, be able to separate out like, what are things that are fixable and like what is kind of just your own psyche, like stuck in a pattern of like, go to bed and think about this tomorrow because you know, there's a path through this, you're just not seeing it now.
Mike: Yeah, totally, and managing yourself is as much work as like figuring out the company through the process.
So it's like, intense growth and only people who like want an intense life choose to become founders in the first place. so I definitely wanted that and chose it, as I'm sure you did.
Christine: Yeah, and then you get addicted and you just get bored if you're not in that space.
Mike: Totally, it's like, why am I not under constant pressure anymore?
Christine: Mm-hmm, mm-hmm, it's a pathology.
Mike: Totally.
Isaac: All right.
Christine: Cool, well, this has been a fascinating and insightful conversation and I really appreciate you taking the time to join us here today, Mike.
It's been super fun.
Mike: Yeah, totally, really great hanging with you both and it seems like we have lots of shared experiences through the whole thing.
Christine: Yeah, I loved getting the chance to connect.
Content from the Library
Open Source Ready Ep. #19, Kubernetes at Scale with Josh Rosso of Reddit
In episode 19 of Open Source Ready, Brian and John speak with Josh Rosso, Principal Engineer at Reddit and author of Production...
Generationship Ep. #29, Game Theory with Leslie Fine
In episode 29 of Generationship, Rachel chats with Leslie Fine, managing partner at Enjoy The Work. With a background in game...
Open Source Ready Ep. #1, Introducing Open Source Ready
In this inaugural episode of Open Source Ready, Brian Douglas and John McBride embark on a technical and philosophical...