Tim Veil 0:00
Welcome to the Big Ideas in App Architecture podcast. I’m your host, Tim Valle. And today I have the pleasure of speaking with Mike Boufford, CTO of Greenhouse Software. Welcome, Mike. I’m very excited today to have Mike Boufford on the Big Ideas in App Architecture podcast, really, actually been looking forward to this for a couple of weeks. I know you and I met. I don’t know it was it a week and a half, two weeks ago and kind of did a prep call. And I thought that thought that conversation was super exciting. You’ve obviously got a really exciting background, done some amazing things. So I’m excited to kind of talk to you today. Instead of trying to read your background to you just tell us a little bit of how we got to this point who you are, you know, obviously, we don’t spend the whole podcast there. But tell us a little bit about your journey, you know, where you started, and how you got to be where you are today, which we want to spend a lot of time talking about.

Mike Boufford 0:50
I was born in New York City, I grew up around the Boston area. And you know, I had really sort of lucky timing, I think in my life, I turned 13. In 1995, which was really like the dawn of the web, I eventually linked up towards the end of high school with some other programmers when we started making things and dreaming of making different types of companies. And so right after high school, I actually went and started a couple of businesses, both of which businesses might be an exaggeration, but a couple of companies that were technically incorporated and all of that, that were trying to solve different problems around the year 2000. Wow, okay. Yeah. And, you know, maybe just noting, I guess, one was trying to integrate bike maps with regular map. So you remember, like back then in 2000, you had Mapquest. Yeah. Print out the map question. Yeah, paper and bring it with you. To do

Tim Veil 1:42
that. That’s right. You have to like print it all out. And like staring at this sheet? Is your drive. Remember that? Yes, yeah, you

Mike Boufford 1:48
might bring some like scotch tape. So you understand exactly where you need to go. So I was trying to integrate bike maps. And so Google, of course, did this in like 2010. And it was a feature of Google Maps, but I was trying to make that accompany my business model did not exist, I just thought that would be cool. Turns out it would require a lot of money to make and would probably make no money. So ended up failing. And that one, did my first stint at a big company first and only stints at a big company, Thomson Reuters 55,000 person global mega Corp. worked there for a while I learned a ton about scaled up problems of different sports, and realize you don’t I’m still starting today, I’m gonna go and join a smaller startup. So I met the co founders of greenhouse and spent a little bit of time with them and took the dive and became their first engineer a little over 10 years ago,

Tim Veil 2:39
you were their first engineer.

Mike Boufford 2:41
Yeah, I read the first lines of code that wow, the company didn’t officially have a name yet. They hadn’t closed their funding round. I remember when I was about to quit my job. I’m like, so it’s never closed around yet. I’ll be your first employee, like, what happens if you don’t, in terms of me being paid if I quit my job? And they’re like, well, we’ll figure it out. Okay, well, this is just like, okay, so I quit my job and went and started a greenhouse.

Tim Veil 3:06
That’s awesome. Well, that I mean, that’s the fun part about it. Right is starting, you know, when, when it’s so small, you know, like, the whole world is your oyster. I think it’s so exciting. So, so tell, what is your role today? And then do tell us? I mean, obviously, I know greenhouse very well, which we’re going to talk a little bit about, I’m gonna ask for a favor. But tell, you know, kind of tell the listeners what, you know, what your role is, and what greenhouses today, because I think it’s a really neat thing. We’re huge users of it, obviously, a cockroach.

Mike Boufford 3:33
Sure. So I’m the CTO, I’ve kind of been head of engineering with with a few different titles over time, but I’ve been CTO of the company steering the technical ship. I’ve also worn a few other hats since I’ve been there forever. So I ran customer support for a while and professional services and product and design. And you know, you just kind of have to do whatever you got to do. You know, when when you’re at various stages of your startup lifecycle. What greenhouse is where think about, like, 900 people now? We are, I think we’re well past it now. But we had a press release, which I know I can reference that a year and a half ago, where we crossed the 100 billion dollars of ARR. Mark. So it’s kind of an ad scheduling startup, which is really great. We were ranked number one best place to work, I think, by Fortune magazine, you know, just this year and have had the number one best place to work from Glassdoor and a bunch of other things. So it’s a really sort of like positive work environment generally. That’s a, that’s really great. And then in terms of what we do, you make hiring software. And so that covers everything from going to find candidates and bring them into your pipeline, running a thoughtful, structured interview process, ensuring that the things that you Institute are sort of operationally effective and scalable that they, you know, we take DNI into account in terms of how we build our products, all the way through employee onboarding. And so getting somebody ramped up so we cover a ton have different problems across that spectrum.

Tim Veil 5:02
Yeah, so we, you know, a cockroach labs, obviously growing startup, and not not quite as far along are. Although yesterday, ironically enough, we did celebrate our eighth anniversary, a cockroach, and I’ve been there for years. So it’s been kind of an interesting journey to see it grow. But, but we’ve been big Greenhouse years and obviously is a growing company we’ve been, we’ve been hiring a lot. And so we use it, I think, to kind of do all of our I mean, we may use it more, but the way I interact with it is certainly for the hiring process, the review of candidates, et cetera, et cetera. And the favor I’m going to ask of you is, you know, our Chief People Officer runs a very tight ship in terms of, you know, interview candidate, you gotta get your feedback in under a certain SLA. And I think I think I may be the worst in the company at this. You know, we have to, we’re encouraged to write kind of very, very lengthy notes, which is appropriate and get them in in a certain amount of time. I am absolutely horrible about it. So I was hoping maybe now that I have like this inside track it technical leadership greenhouse, you can like alter the code somehow. So the like, if, if Tim Vail submits his feedback, it doesn’t register, or notify our chief people officer that he’s way past the SLA. Because I spent, I spent a lot of time in there writing feedback, but I almost never get it in on time. So I will,

Mike Boufford 6:19
I will certainly spend a bunch of time talking to the product team about that. I think, fantastic. Right? Yeah. Featured, but I came on the podcast and heard that might might change the course of this for the better. But yeah, we I mean, there’s like accountability stuff in there. Right? Like, there were certain things and various, that’s a good example of it. But do you feel guilty? Because you know, that’s, that’s probably part of it? If you don’t do it, you know, you said you were gonna do it?

Tim Veil 6:46
I do. There’s a lot of guilt associated with it, which I don’t need more guilt. So you know, I just somehow if I could, at some point, I’ll get to the point where I do these things on time, of course, but but let’s so we’re in the big ideas and app architecture podcast, which I guess means we should we should attempt at least to talk about not only big ideas, but architecture as well. Maybe let’s let’s let’s talk a little bit about kind of how you build me, but you were the first engineer, I mean, how have you built a green house? You know, how is the you know, what does it look like today? And maybe maybe be interesting? I mean, given the length of time you’ve been there? You know, how is it? How does the architecture evolves? Because you guys are doing a ton of stuff. I mean, I you, you’ve shared with me previously, some pretty interesting facts and figures about you know, how much uses there is just, I’d love to hear just kind of how the, the tech stack the architecture, if you will, is kind of evolved over time, I’d imagine you’ve seen lots of changes, lots of changes.

Mike Boufford 7:45
Yeah, we definitely have. I think, you know, there are probably specific things that we need to figure out that will inform the architecture, more than anything else. So one of them was, you know, how do you add customers indefinitely to a SaaS application, because, you know, that’s, that’s a business critical problem. If you hit some vertical scaling limits, and you no longer feel like you can add more customers, the business basically grinds to a halt, and it stops. And so this was like, one of my great fears as greenhouse was coming up that we wouldn’t quite figure that out. And the types of solutions you often have to implement to be able to add more customers kind of indefinitely, often do take a while, like they’re architectural. They’re they’re like fundamental changes to how you organize and run your systems. And so I wound up going on a little bit of a SAS CTO tour, I chatted with a bunch of the venture capitalists who invested at different points, and they made some intros to other people who are further along. And I asked them, like, how did you scale? How did you architect stuff, so sort of like, you know, my own personal podcast with with all of these luminaries who kind of knew what they were doing. And what I realized was, you know, there is no one size fits all problem fit fits all solution for, for scaling up. But SAS businesses tend to have a really good sort of shard key baked in, which is that you can separate organizations from each other organizations generally don’t need to or want to know any of the information about another organization when they’re using the applications, just them. So that meant that we could separate people out into separate databases. And that created, you know, the path forward. So we took a really sort of blunt approach and said, you know, what, let’s make a greenhouse. So greenhouse having, you know, search capabilities and caching and queues and web servers and database and all those things. And let’s print sort of copies of them and make sure that we have you know, services or other sort of data exchange protocols in place where we do actually need to share data, but most of the time, we know we won’t need to and so if you look at today, we have eight different silos, which is what we call them, that contains separate sets of customers. And and that allows us to keep adding customers indefinitely um, which is, which is good, we figured out that we could use, this is actually kind of an interesting goal setting insight, we could use the amount of revenue we were generating as a good sort of trigger. So it was like, you know, after X number of dollars, you know, you kind of need another silo. And so you need to spin that up. And that allows you to also manage Causton in a relatively consistent way as you continue scaling. Other nice things about that style of architecture is that when there’s a failure, most of the time the failure is isolated. And so you know, even with Ha, you know, everything, you still end up introducing issues. And so that architecture allows you to, let’s say, deploy to one silo, see, if things are going well, you know, sort of blue green style and then rollout to everyone else, when something happens, a cube gets backed up, it gets backed up in one place. And so there’s almost never anything that grinds the whole system to a halt would have to be like DNS level or, you know, something even more catastrophic. You know, the,

Tim Veil 11:03
you know, and I wonder if you get this sometimes when talking about architecture certainly been, you know, involved in plenty of conversations where it maybe it’s not architectural, necessarily, but kind of the word silo, you know, people I will use IQ siloing, you know, it, you know, I think in some levels that almost has kind of a negative connotation. I mean, the way you explained it obviously, makes total sense, right? Forget green. Yeah. But you get that at all. I mean, it’s like, Hey, wait, wait, wait, Mike, you mean, your architecture silo? Do you know, what is that mean? Yeah, I mean, does that mean, you know, it’s, I think,

Mike Boufford 11:33
I think it’s sort of like a bleed over in terms of new people here. Oh, I think the engineers feel siloed or excluded from product, but, you know, I think it’s, I think it’s just sort of a different use of the language and, and, you know, in our world, it does mean separateness, but separateness is good in certain ways, for this type of architecture, and I agree that it’s often bad when you have certain roles that are are siloed, from others, and they’re not collaborating effectively. So, you know, it could mean both.

Tim Veil 12:03
Now, obviously, you know, a cockroach, you know, part of our big story is, you know, resilience, and, you know, we, you know, one of the things that we have is how to survive anything. So, you know, that that whole kind of theme is important to us. I actually really liked this idea that, like, you know, kind of a small blast radius, right, should something happen? So, if, you know, if one silo goes down, it doesn’t, it doesn’t impact the rest of business. I’m curious. You know, and obviously, no need to give specifics. But what does it mean? I mean, you know, if, if a customer’s silo, if you will, is offline, I mean, what’s the what’s the impact to the business, you know, is this, you know, fire alarms ringing everywhere, you know, walk walk us through, if you can, like, what happens if things were to go down? Maybe, maybe you’re fortunate, and they haven’t. But But what does happen if things go down?

Mike Boufford 12:51
Yeah, I think things don’t really, you know, sort of fail all at once so much anymore. You know, I think we’re, you know, we’re, yeah, at least four nines of uptime. Generally, discrete things happen, though, that might make it feel like it’s not working the way that you want it to. And so when that does happen in a given silo, given the silos are actually still quite big, the impact actually is significant. There’s a bunch of customers who might be, you know, frustrated, when something bad happens, you know, a queue gets backed up, and something’s not getting processed in a timely manner, you know, some other sort of underlying issue. So we have a fairly robust sort of incident management process, and we have tons of automations around it, a lot of it’s driven off of slack. And so I know, you can just buy tools like this now, you know, you would type into Slack command to start an incident, and it would automatically create a, you know, a Zoom Room that would be recorded, it would invite all of the right people who are on rotations into a shared channel, it would put notifications in different places, so that there was, you know, high visibility would automatically log an entry. So all that sort of stuff happens. And you have a bunch of people sort of swarming it, you know, no matter, you know, the hour, although almost almost nothing is sort of happening in the middle the night anymore, which is fantastic. Because, you know, in the early days, it was like me with a backpack, and, you know, wherever I went and in the middle of the night, I need to leave my ring around, just in case.

Tim Veil 14:13
Interesting on that particular topic. We did a webinar not so long ago with, he works for us now, but at the time, this gentleman Sean from DoorDash, and I think we use the term in the webinar, you know, you know, what do you do when things go bump in the night and I thought his response was a really interesting one I never thought about, is it like, for example, DoorDash they were less concerned about what happens at night, you know, a bump in the night. They were more concerned what happens during the day, you know, like, hey, you know, it’s peak hours in the middle of the day what happens if failure occurs then? Because it can you know, at that time can be quite costly and if it’s in the night, maybe nobody’s looking that’s okay. But you don’t want it to you know, go down when everybody’s trying to get their their feedback in.

Mike Boufford 14:58
Yeah, no, that’s that’s an interesting perspective we, we do have a bunch of customers in Europe. That’s true. Yeah, Asia and so it’s daytime somewhere, but But of course, it’s always, always worse than the US. So yeah, when something happens, you know, we kind of swarm it. And I think, importantly, not everybody freaks out. So you had said, like our fire alarms going off, like, there are the alarms that get people into the room. But the important thing is that everybody stays sort of cool, calm and collected and is able to, you know, carefully and rationally figure out, you know, what’s going wrong, identify the issue and work on figuring out what the solution space looks like and apply the change. And so, you know, most of the time issues can be resolved really quickly, you realize exactly what it was, you have a bunch of mechanisms like, you know, rollback in place, you know, if there were some type of code change, that that caused the issue, we have certain patterns where, you know, we know that we can auto scale up certain resources if something’s happening. But there are other times where you actually have to do something a bit that requires deeper research, or a more fundamental or lower level change. Do you ever get worried, cool, calm? Energy in order to figure out do

Tim Veil 16:09
you ever get worried is like, you know, kind of one of the first engineers, you know, there’s gonna be some issue, and they’re gonna go back and get blame history, and they’re gonna say this. Wait a minute, this is Mike’s code. Mike, did this. Ever, ever

Mike Boufford 16:23
have done that? Now, most of my code that could cause issues has already been replaced by better code? I think so. So I probably wouldn’t get blamed anymore. But even if I did, I think that’s fine. I mean, we generally do the thing that I think most tech companies do, which is like, we have a blameless culture, we, of course, you know, we, if we blame anything, we’re blaming, you know, the process or the guardrails and trying to iterate on the environment that people are developing software in and not, you know, getting getting too caught up on the individual developer, because you know, writing software is really complicated as

Tim Veil 16:57
it is so hard. You know, I mean, we say a lot to here. Nothing is easy, nothing. Out of curiosity, how big is the engineering team?

Mike Boufford 17:08
So in total, I think I just yesterday, it’s like a 145. And that’s not not including, like product and design, and all those folks, in terms of people really actively working on the product, I think it’s probably a little

Tim Veil 17:22
over 100, how often you guys releasing

Mike Boufford 17:26
many times per day. So last year, I think we did something like 1200 releases. So that’s an indicator we have, yeah, we have full, you know, continuous integration, continuous delivery. You know, we’ve had those pipelines in place, we really invested in developer tooling pretty early. And so if we go all the way back to the beginning, like a lot of companies that were started in 2012, we were able to use Heroku. And we were all like, Oh, my God, this is so great, you can do all of these things super easily, that would have been pretty hard. And I think Heroku did an amazing job of innovating. But they also wound up doing things like pricing their databases, like six times more than Amazon. And so eventually, everyone was like, I guess we got to, I guess we gotta go. And so we got on the same boat, but we didn’t want to give up all those capabilities. So again, not all that uncommon at that moment, but in like 2015, or 2016, as we’re migrating off, we wound up building similar types of tools and how so that developers could scale up and down, you know, servers or workers or provision new things. And that tooling, ultimately led to us releasing a capability around ephemeral environments, in I think it was early as 2016. So we were the only startup I knew of at the time that had these ephemeral environments, somebody makes a new, you know, pull requests, and then they could put something, you know, on a server, you know, in a in a clean state right away, you know, that was all containerized and be able to promote it all the way through. And then also provided, I think, a nice level of encapsulation, sure. Because, you know, the interface that we provided, that was the our Heroku like interface that we actually ended up calling it de joku because the original version of greenhouses name was de JOCO, Dan John company, they really to, to change, they were like, let’s pick a bad name. And so it’s kind of like a play on those words, but we’re able to swap out the back end, like go from, you know, NIZO synth marathon to Kubernetes and adopt, you know, sort of more modern practices as we as we went without having to change the interface the developers that used to

Tim Veil 19:27
do have a technical follow up question, but since you mentioned names, and you know, we’re were named after a pesky little bug and people I swear, you know, to this day, like why, why did you do this? What is the story behind I mean, obviously, you just shared kind of what the, the original aim was, but you know, the the name greenhouse is there, is there a kind of

Mike Boufford 19:47
there is So, the cofounders of Greenhouse as part of their sort of painted door experiments of like, let’s see if this idea is valid and true tested out there. They wound up creating a structured hiring During class at General Assembly, so this was in like late 2011, early 2012 I think it was called How to make hiring the strength of your company. And it was really well attended and one of the people who attended was a person who specialized in naming things. Like that was that was literally her job. She was like, you know, okay Rana sir brand consultancy that focused on like picking names for products. And and you know, she had met Dan and was like, You seem really good at business stuff, Can we trade. And so she proposed I will help you name your company, and you give me some business advice for how to scale up my brand company. So she created this whole deck, which I actually ended up reviewing, like, I think my videos a month into greenhouse while they were still picking the name. And they went through the whole story of like, well, you can do like a really literal name like, you know, job fighter job that sir, you know, snag a job right there. Yeah, exactly. You know exactly what it isn’t. And it’s very clear, no ambiguous, no ambiguous, ambiguous nanny. Or you could go with something really abstract like Altria, it’s like, they don’t sound like a company that might be killing everyone, but they might be right. And so you have no idea what they’re doing. Or you can try to pick a name, you know, that evokes a certain type of emotion, but is founded in a real word. And so like, what are the things that people feel? And you know, think about when they think about hiring, it’s like, well, you know, it’s growth, it’s like, the next stage of my career, it’s that, you know, things might be a little sunnier. Right, so you can think of a lot of hopes, and associations from greenhouse with, you know, getting a new job or hiring or growing. And, and so that became kind of the core of it.

Tim Veil 21:45
That’s really, that’s really fascinating. Yeah, that’s actually kind of an uplifting, positive. I love the visual imagery of that. I mean, unfortunately, when we have to describe our name, we have to talk about people,

Mike Boufford 21:58
that was a little bit technical, which, so one of the things that brand DAC was, well, you could also use this sort of plant theme to name future products. And so you could create new products like greenhouse rose, or greenhouse, you know, oak, or whatever it was. And so I thought, oh, that’s, that’s really interesting. And, you know, clever, we should probably do that. We didn’t end up doing that broadly. But one of the first things we needed to name was an API that we created so that people could do data migrations, and pull and pull their data out, you know, if things hadn’t worked out in the early days, and so I wound up naming it harvest. And so harvest all of your data, one of the being the name for, you know, the API more broadly, and all the other stuff that we dangled off of it, but a bunch of other ETS companies wound up creating harvest API’s, as if this was like a type of API as opposed to data off of the greenhouse brand. And so occasionally, you know, customers will get on and say, like, Do you have a harvest API? As if it’s like a first class citizen of the API world?

Tim Veil 23:03
That’s so funny. Yeah. You know, I mean, again, being named after a bug we just get, we celebrated our eighth anniversary. And so there’s kind of like a lot of reflection. And in a cockroach, everything is named after the bug, right? Or some, some part of the bug. So you know, like a cockroach is is they they grow and mature. It’s called molting. So in our onboarding process, right, you don’t tie you know, I don’t know what it’s called, and other other places, but we molt, and when we get together, it’s a rope fast. And we have camp Roach, and it’s just so you know, we don’t have this like positive. I mean, I love it.

Mike Boufford 23:32
We call it onboarding.

Tim Veil 23:36
Yeah, we don’t wait, it’s molting. And

Mike Boufford 23:38
when we get together, we call it gather, or something.

Tim Veil 23:42
I like it. I like it. All the

Mike Boufford 23:45
positive brain associations. Okay.

Tim Veil 23:47
Speaking of API’s, and I know you and I touched on this a couple weeks ago, but if you don’t mind, I’d love to just kind of revisit this topic, just because it’s always been kind of a, an interesting topic for me architecturally, as I as I’m sure you’re well aware, you know, the, the industry for many years that just fell head over heels in love with this idea of micro services, nano services at you know, just, I mean, you know, it’s probably better than anybody that kind of the lure of, of converting your application to these, these kinds of concepts. You know, what’s been your take on that? And, and, you know, as you guys have, have evolved the architecture over over the last couple years. You know, are you big microservices shop? can or should, yeah, that, you know,

Mike Boufford 24:40
I would say that I am fundamentally not dogmatic and don’t get into, you know, the religious discussions about these types of things or, you know, get super into whatever the trend is. There are times when microservices are absolutely the right approach. There are times when it’s not worth it. overhead. And so, you know, the ultimately you want to sort of understand like, what is the business justification for any significant technical change? And what is the cost associated with, you know, with whatever the thing is. And so in certain cases, it makes a lot of sense to have something across an HTTP boundary. And other times, you really just want isolation. And actually, it’s only a hindrance or slows things down to, you know, have something, go go over a network, forget, forget HTTP specifically, but go go over a network to make certain types of requests. And so there should be a reason that you need separateness, you need some scaling, you need, you know, your test suite to run a lot faster, or is it going to change frequently, and one of the justifications people often end up using which I think is sort of incomplete as well, you know, we need teams to be able to operate independently, you can do other things, even around a monolith, in order to make them operate independently, you can, you know, assign components and make sure that they’re strong component, air ownership doesn’t have to be across a network boundary doesn’t have to be a totally separate code base that’s deployed separately. And you know, people can still be pretty productive. Other teams can pull requests in, you know, just just the same way. So I think a lot of the underlying patterns of we should have isolation so that teams can have a high level of ownership can be achieved without microservices being a architectural constant, and how you build everything. The cost, of course, you know, if you have many, many databases, you know, that are all small, you have to maintain many, many databases. Anytime you want to join data from one thing to another, you know, that also requires, you know, that you do a bunch of extra, you know, extra work, when you’re sitting across databases, where you might just write a join, if you are on the same database, and so you have to monitor all the services separately, they’re going to be finicky in their own ways. So there are times when it’s good, and times when it doesn’t make sense. For us, we have like a monolithic core with a bunch of micro services around it. And I remember hearing a story, I’ll just give you one, which was from I will, I will just not name the company, sure not to cause issues. But there was a company that was doing a bunch of development in New York and have like 1000 engineers working, you know, not not even exaggeration. And their main thing was convert the codebase from monolith to microservices. And that was kind of like the goal, six years worth of work with no new features. Like ultimately, what happened. So did it scale. Yeah. And it was, you know, architecture really beautiful in certain ways. But ultimately, like, you know, if you sacrifice six years worth of product development advances, that’s quite a big sacrifice. So there has to be a good reason that has to be the solution, as opposed to something else. And so I think we should just be pragmatic when we make these, you know,

Tim Veil 27:47
it’s, that’s why one of the reasons I’ve so enjoyed talking to you, you know, these last couple weeks is that, you know, like this idea of pragmatism, right? Not being so dogmatic because you’re absolutely right, right. I mean, some of these things do have this, like religious fervor around them. And, you know, in my role, you know, both the cockroach and in previous lives, you know, you end up working with companies of all shapes and sizes and engineering teams have, have varying levels of sophistication and maturity, and it is interesting, I mean, there’s a lot of people out there who, you know, read a blog, or go to an event and like, we’re going to adopt this technology come hell or high water, because it’s the thing to do right now. And oftentimes, you know, maybe not as much attention is paid to, you know, you know, what does this actually mean to, to the business? Can I? Or will I achieve, like, actual goals when going down this path? And, and that, you know, that story that you just shared does not surprise me, we used to run into folks all the time, and still do to some extent, who are, you know, just hell bent on, on some technology or some architectural concept, regardless of how well it works for them, you know, because it’s, like, perceived as the thing to be your thing to do.

Mike Boufford 29:01
Yeah, and I think, you know, the best developers really understand, you know, what are the costs and, you know, value associated with the decisions they’re making. And when they do fully understand that they tried to vet it out, I think that should provide a more skeptical lens on on certain types of, you know, sort of new hot technologies, also just being around for a while and seeing all these waves, where it’s like, you’re not doing things in a spa, then you, you know, clearly have the wrong architecture. It’s like, Well, again, it depends, right? There are certain things were like, Yeah, that was an innovation that, you know, made certain types of applications better. And for other applications that made things harder and worse, like so, you know, you know, we should look at these trends, understand them, not rush and maybe not be first adopters for all of them. And we shouldn’t buy all of the value that’s being pitched by the Zealots who are out there advocating for any given architecture. You know, most of the time, you know the consequence to show up a little bit later, in blog posts, like we switched everything to a spy to our companies, that might not be the reason. But it’s like, you may have wasted a ton of time as a result, maybe that didn’t really

Tim Veil 30:11
solve the problem. So funny is

Mike Boufford 30:15
the fact that I have three little kids, and they’re constantly sick. And I’m constantly sick as a result, we had to reschedule this. Because I was second, you can probably still hear the end of a cold. Oh, thank you. Even Even now, but you know, they wake up in the middle of the night when when they’re sick. And you know, I mostly feel bad for them. When they were doing it every night when they were newborns, you know, I mostly felt bad for me. But at this point, I, you know, mostly feel bad for them, like, Oh, they’re so stuffed up and try to help them another night. But they literally keep me up. Non literally, I think the same thing that everyone else is dealing with, which is just there’s there’s a lot of uncertainty, it’s hard to plan during periods of uncertainty, you know, do we, what bets do we place on the future? Is it that, you know, we’re heading into a economic rebound? Is it that we need to be more careful with, you know, where we invest our energies over the next few years? Because it could be a long Rocky Road? No, nobody knows. And anyone who says otherwise is obviously full of it. And so that’s, that’s, it doesn’t necessarily keep me up at night. But it’s a thing. I think that everyone, you know, not just across the tech industry, but maybe express, especially the tech industry is worried about right now.

Tim Veil 31:29
Oh, couldn’t agree more. It’s it’s tough out there for us, you know, for everyone that just woke up this morning read about, you know, more layoffs happening in different corners of the world. So yeah, I think the uncertainty is adds just another layer on top of kind of the big fun tension cake that we all are anxiety cake that we all live and deal with every day. But on a more positive note. We’ll end with what are you hopeful? For? What are you excited about this? This coming year?

Mike Boufford 31:57
Yeah, let’s see, maybe I’ll give a multi part answer. So you know, for me, personally, I’m just excited to be sort of like out there in the world, so much more, you know, we had newborn twins during a pandemic, and you know, I’m fully sort of engaged back out there in the world. And, you know, I feel like a tremendous amount of positive energy, there’s more travel happening, seeing people, there’s, there’s a, there’s, there’s actually a really amazing energy, I think, in parts of parts of humanity right now, that I think I’m pretty excited about. In terms of work stuff, I’m really grateful to be working, working for a company that is being conservative and careful. And, you know, we were already pretty good at, you know, not sending lots and lots of money on fire as we were building the company. And so, you know, we’ve not been feeling like we’re in dire straits, despite the fact that, you know, the economy sort of is what it is. And I think that’s been, that’s been amazing to feel like the comfort of that. And then, you know, I’m excited to see how things are, are meshing with, you know, this generation of the team, we’re over 10 years in, and one of the things we always took pride in is that, you know, people who started working at Greenhouse wanted to stay here long term, last year out of, you know, all the 140 some odd people that that are, you know, on my team now, one person left all of 2022 Wow, one. And so, you know, just being part of a culture that feels as positive as it does is, like, an everyday gift. You know, I’ve worked in places where people are, you know, wake up unhappy. And, you know, they are unhappy throughout the day, and they go home feeling unhappy. And, you know, that’s generally I think, is not the case that people, you know, may be get a little bit more fulfillment out of their day, they get a lot of kindness and empathy from colleagues, and they get to do good work. So I’m happy to work for a place where we’re all that’s true.

Tim Veil 33:58
That’s awesome, Mike. Well, listen, this was a fantastic conversation. I do so deeply appreciate you spending time with us. Just great, great stuff. And looking forward to Well, I’m not sure I’m going to look forward to continuing to add feedback into greenhouse, but I will certainly, I’ll certainly do better next time. And if you can, talk to engineering team, see if we can get that. get that fixed. So I don’t I don’t keep getting in trouble.

Mike Boufford 34:24
No problem. We’ll just put a string literal right in there. If Tim if Tim

Tim Veil 34:28
Vail. No alerting. Mike, thanks so much. Appreciate it. Thanks again for joining us on the Big Ideas and App Architecture podcast. I knew to this so if you have any thoughts or feelings would like to drop us a line and let us know how we did. I’d love to hear about it. I look forward to talking to you again soon. Thanks. Bye