The Build vs. Buy Software Debate: Tips from Startup Engineering Leaders | The Pair Program Ep01

Tim Winkler: 00:00:05

Welcome to The Pair Program from hatchpad, the podcast that gives you a front row seat to candid conversations with tech leaders from the startup world. I'm your host, Tim Winkler, the creator of hatchpad and I'm your other host, Mike Gruen. Join us each episode as we bring together two guests to dissect topics at the intersection of technology, startups, and career growth. Welcome guys. As you're aware, this is The Pair Program. I'm your host Tim Winkler accompanied by my co host and right winger, Mike Gruen.

Mike Gruen: 00:00:41

Mike, good to see you. Yeah, nice to see you for those not watching where both of our hockey jerseys, I'm not a conservative right winger just to put that out there. Uh, but yeah, so, yeah, welcome to the episode. Um, and we'd like to start every episode by asking our guests what their favorite pairing is. Uh, Ian, why don't you why don't you lead us off? And what's your

Ian Lotinsky: 00:01:03

what's your favorite pairing? Sir, I practiced one at practice this one at home with my kids last night. My favorite pairing is dad jokes and awkward silence.

Tim Winkler: 00:01:15

That's good. That's good. Do you have any dad jokes up your sleeve or that was a dad joke? That was a dad joke. Okay. I should have waited for more awkward silence, you

Mike Gruen: 00:01:26

know, how you measure, you know, how you measure dad joke on the size seismographs and then we have the awkward silence. Perfect. Yeah,

Tim Winkler: 00:01:40

Mike, what's, uh, what's a good pairing for you?

Mike Garrett: 00:01:43

For me, it's a bourbon and popsicles.

Mike Gruen: 00:01:47

That's an interesting, any particular flavor popsicle.

Mike Garrett: 00:01:51

Uh, whichever ones are in the fridge or in the freezer. Um, I'm an adult, so I can have whatever I want.

Tim Winkler: 00:01:59

Just don't mix those up when the kids are around. Um, I'm going to go with, um, Alex Ovechkin and the Washington capitals. Just. Based on the fact that I'm a huge DC caps fan here. And, uh, Mike, you are wearing a rangers jersey. Yeah, I guess. So

Mike Gruen: 00:02:16

then I guess that makes my favorite pairing. Um, uh, heartbreak and misery. So

Tim Winkler: 00:02:23

yeah, well, watching football team fan here as well. So I can certainly relate. Awesome. Um, well, good stuff. Why don't we jump into the, you know, the reason that we're all here today and, uh, riff on this. Discussion around, uh, build versus buy or buy versus build. Um, you know, obviously something that is debated, you know, amongst engineering leaders, product owners, founders of different startups, uh, on a daily basis. Um, Mike, why don't you give us like, you know, your, your definition of build versus buy and kick off with your thoughts on the topic.

Mike Garrett: 00:03:02

Sure. So for me, the definition of build versus buy is really what can you do to help your company achieve their goals, either by building it from scratch or, you know, buying a solution? Uh, there are schools of thought, hence why we're both here, uh, on both sides of the issue, but, uh, it really boils down to, you know, what can we do as an engineering organization to advance our own goals?

Tim Winkler: 00:03:33

Nice. Ian, um, any anything on that note? Or, um, similar similar feelings? Sure. Yeah,

Ian Lotinsky: 00:03:42

I think, um, the usually for any particular component you're looking at or service, you're trying to decide, do we build? Builder by, uh, this thing. Um, but when you look at the whole portfolio of some sort of a product or company, um, it's usually not entirely buy versus build. It's usually, what are we buying and what are we building? Um, so that we're strategic in our scarcest resource, which is usually time. Um, obviously money is involved. Um, the economics do play into it. But a lot of times it's about opportunity cost, you know, as your, your product company weighs different, different options for different aspects of your total solution.

Mike Gruen: 00:04:24

Yeah, I think that that leads into a great point on opportunity cost and build versus buy. And I think there's hidden costs as well. Um, as you sort of hinted at, right, even when you're buying a solution, it's not just. Buying a solution, right? Like there's going to be some time cost to implement it, um, integrated into your systems. And I think that's one of those hidden things. I'm curious what your guys thoughts are on that.

Ian Lotinsky: 00:04:49

Yeah. So, uh, yeah, I think when it comes to hidden costs are just things to take into consideration, right? There's more than just the price tag of, you know, build versus buy. There's things like, um, you know, what's the long term cost of this in terms of maintenance? Yeah. Um, because whether you buy or build part of your team probably is going to have to support something. Um, uh, is this thing that we could buy stable enough to rely on or is there going to be hidden cost and having to patch, you know, problems either, you know, some sort of open source project you can contribute to or something that you have to negotiate with a product team somewhere that you're paying, um, or even having to, you know, Sometimes patch around issues, right? Using encapsulation to, like, encapsulate a service or something. Um, and figuring out how do you fill in the gaps? Um, whether those are, uh, capability gaps or technical gaps because something just doesn't work, um, you have to really look at total cost of ownership. Kind of like when you're buying a car, right? It's good to know what's not just to make a model and the cost of acquiring this. But what's the maintenance typically look like for this sort of vehicle?

Tim Winkler: 00:06:03

I could certainly talk to, you know, you would talk about building something as well. I mean, the cost of recruiting right now is at an all time high. Um, the cost of acquiring talent, you know, is becoming more and more difficult. These days, given the market, um, engineering salaries are increasing at drastic rates more so than they ever have in years past. And, uh. You're going to inherit that cost. Um, it's also going to take some time to find the right individuals. And so if you're going to be pretty particular, which most startups tend to be, uh, with finding, you know, that, that right engineering mold, it's going to take you a little bit of time and you're going to pay for it. So weighing that into the equation certainly should, uh, play a part.

Mike Gruen: 00:06:46

So, yeah, I'm curious, like, you know, like there's the cost side, right? And then there's other decision, you know, what other factors do you want to take it? Do you guys usually take into consideration when you're trying to make that decision of do we want to build this? Do we want to buy build it in house? Buy it some sort of something in between. I don't know, Mike, what your thoughts are. But, um, you know, obviously I do actually, because we talked a little bit about this, but, um, but, yeah, I'm curious, you know, what, what, uh, what other characteristics you look for constraints you think of.

Mike Garrett: 00:07:15

Yeah, I mean, outside of the monetary costs are all, there's also the human cost. Uh, so cost of, uh, like we mentioned, maintaining the software itself, um, also acquiring knowledge. Um, so for a piece of technology where it's not our core strength, or it's not something that the. You know, team knows intimately thinking about like databases and maintaining those long term. That's something that you also have to think about to make sure. Is it worth us ramping up on, um, you know, maintaining a cluster, uh, having knowledge about A. J. Um, when we could acquire something that has all of that, uh, and a whole company standing behind, um, making sure that those things are, you know, um, thought of and are. You know, have an SLA behind. Um, there's also that the other cost is, uh, in choice. So I think back to, um, you know, assembling, you know, at least on the front end, um, with, you know, choosing between like angular JS and react, uh, where one was an all in one toolkit and the other one was, you know, best of breed, build up your own. That's kind of something you think about when you Build something you think about all the different pieces. What cloud do we deploy to? What database do we use? What, um, you know, front end language do we use versus we use, uh, we integrate someone else's SAS product that has all that kind of behind the scenes. And we just interact with a connection string. Um, it really reduces the amount of cognitive load that your team has to deal with versus. You know, building something up where, you know, all the intimate pieces of it, but is that worth it?

Mike Gruen: 00:08:48

Yeah, I mean, I think it's, um, and in, um, feel free to jump in, but like the sort of quarter your business versus, is it commodity? That type of stuff, I think isn't sort of what you're hinting at Mike, but I'm curious what your thoughts are. Yeah.

Ian Lotinsky: 00:09:02

Yeah. I think, um, cost is important. You know, how staff are going to support this is important. Um, a lot of times though, it needs to start with what's the strategic value of this. Um, does this, uh, is this something that is strategically core to our business in a way that we know there's going to be a lot of iteration on this aspect that we're going to be listening to user feedback and having to Make it better or extend it because of that feedback or that market strategy. Or is it something that's just a commodity service? That's something that's not going to need a lot of iteration, something that really is kind of the same sort of service or functionality across all, you know, all or most web products or software products or whatever you're building that can just be outsourced without worrying about having to have a Differentiated, you know, from other people's products. Um, it's a great way to involve, you know, the business team in the conversation around build versus buy is, you know, starting with, okay, what's the big problem we're trying to solve here? Is this solution part of our core value add in the world or is this something that is more secondary or tertiary?

Mike Gruen: 00:10:19

Yeah, I mean, I think, um, that's right. The whole, um, core to business is always one that I've used as a main driver. Like, is this really part of our intellectual property? Is this what we find? You know, is this really where we want to be spending our time? Is this where we want to hire developers? Um, I think what's sort of amazing about and you guys, we've all experienced it over the last 10, 20 years, which is, you know, Everything is becoming more and more commoditized. It used to be the case that you needed to have, like, somebody who, like, if you wanted to build an authentication system, you kind of had no choice but to build that yourself. And now there's, you know, authentication is a service. It's basically becoming commodity. There's a bunch of players in that space. Um, infrastructure is another place, you know, databases, um, you know, time and again, I think that's just the, the direction that everything is going is pretty soon. It's really just assembling 3rd party pieces that do all of the things that you don't want to have to deal with. Um, and I think that's, you know, I think it's the, the builders by decisions, just getting that much more complicated, because in the past, it was, it was a little more straightforward. Like, there were less options. And so. So it's, I think sometimes, you know, and I've experienced this recently in places I've worked where it's like, it's hard is this corridor business is actually sometimes a really hard question to answer. Um,

Ian Lotinsky: 00:11:47

there's, there's more discipline that has to go in now into, um, not accidentally just adopting something because it's available.

Mike Gruen: 00:11:54

Right?

Ian Lotinsky: 00:11:54

Right. That, um, and these, you know, these options are usually relatively inexpensive. And so it does have to be about what's the core value we add to the world. And, um, even if we do decide to buy right now, what's the future switching costs, uh, involved, um, in, in, in the inevitable future that tends to come at some point, especially in a multi year journey, um, where you do end up having to convert stuff that is purchased to, um, custom. Because your, as your needs develop or even just 1

Mike Gruen: 00:12:31

thing that you've purchased a different thing, right? Like every, you can, you can outgrow a thing, or I can think of a number of, uh, you know, you sort of get in early at a company, like it's an early adopter to their platform. And then, you know, you're using it and you, and, uh, they sort of make maybe a pivot. And then next thing you know, you're sort of this, like, legacy customer, um, using the system that they don't really want to support anymore. And you're, you're sort of left like, okay, now what do we do? We have to find somebody else to migrate to. So there's that type of stuff as well.

Mike Garrett: 00:13:02

Yeah, absolutely. Um, and that's when it becomes super important to hold your data and call that sacred because you do. You will want to switch from one platform to another as you outgrow one where be where either the earlier adopter or met your needs at one point, but now they are stagnant. They're not growing. Here's a new one that comes along that they've got a new team behind them. They're doing a lot more and not a lot more and more quickly. You're able to swap over if you hold on to your data in a way that makes that transition transparent to your company to your users. Um, and it gives you that value versus one where you've. Built it up from scratch and you can no longer, you know, you don't have that autonomy. You are just at the mercy of whatever you have assembled yourself.

Mike Gruen: 00:13:49

Yeah, I mean, I think that's right. The whole risk and offsetting that risk of what happens if they go out of business, if they get acquired, if they no longer meet our needs, whatever it is, that's something that really needs to be taken into account when you're, when you're building these things. Um, I'm curious. I

Tim Winkler: 00:14:02

have a question like, um, As far as the key stakeholders that go into that decision, that final decision, is it, um, is it usually a group decision? Like, let's loop in the product team as well. Let's, you know, CTO in board or where, what is the, you know, who's the team at hand that's kind of going into this, you know. Decision making process,

Mike Garrett: 00:14:26

at least for for me and my team, it depends on, uh, I guess the size and the impact of the thing that you're trying to integrate in. Um, if it is, you know, one off tool, um, that can help your team move quickly. Uh, it's not too terribly expensive. Um, the decision can rest within our team. If it's something that's going to impact more of our users, um, be this. Yes. You know, very centralized piece of technology, like an authentication system that's going to require the full engineering team and the VPs and CTOs to sign off on. And if it's something even larger, like a CRM, that's going to require everyone to sign off on because it's just like the monetary impact to the rest of the company.

Mike Gruen: 00:15:14

Yeah, I think, um, right for, um, when I think about it, right, those stakeholders are, you know, 1st of all, not every tool is necessarily not everything that you're thinking about is, uh, user facing. So, like, if it is end user facing, then probably product needs to get involved. If it's, um, if it's a tool that's going to be used by some subset of the people within the organization, obviously they need to get involved. And, um, I think that's those are all important things to keep in mind. And making making a good case, I don't know how, like, I think a lot of startups, um, sort of the making the case for a decision like that, especially during growth stages. And I'm curious what kind of regular you guys have seen put into those decisions. Is it something that is like, super formal? And you have to put together, like, a whole document explaining, like, The whole thing, or is it like just a, you have a quick conversation and everybody's like, yeah, no brainer. I've definitely experienced all of it. So I'm curious what you guys experiences have been.

Mike Garrett: 00:16:17

I've got an answer, but Ian, I'd love if you'd start.

Ian Lotinsky: 00:16:20

Yeah, sure. Yeah. So whenever it's involved money, it's definitely needed to, uh, uh, have a little bit more due diligence because. We're going to be, you know, spending cash that could be used on our, our burn, you know, our, our staff burn rate. Um, so that's, that's one thing that comes to mind. Um, and I think there tends to be a default assumption that we can build all things. And so you have to, um. Uh, kind of just break out of that mold and I think sometimes it's, it's upon the, the build team to be the ones who basically Paul, the con bond court and say, hang on, we're stopping the assembly line here. We're going to, um, you know, talk about the strategic, talk about the cost, you know, long term, short term, et cetera, and try to, um, figure out, uh, because they're the ones who have to maintain this, you know, what's, what's the right, um, process to be convinced. And I think when we talk. Earlier about that spectrum of commodity versus, um, strategic, uh, value, you know, extra strategic value for your business, um, that comes into into play. And it's something that your whole your whole product team has to lean into, whether or not they're part of the engineering team that has to support this or implement it.

Mike Gruen: 00:17:38

Makes sense. Um,

Mike Garrett: 00:17:41

and then from my perspective, same thing. We write out a document and it's designed to basically lay out, uh, if we, you know, if we build this. These are the important things to think about. If we bought this, these are also the important things to think about and weighing which one the pros and cons of the two. And it's really like thinking about things like opportunity cost. If you buy something now, uh, depending on how long it takes to integrate it, it could be, you know, you fully utilizing all of its feature set within like a month or so versus building something that's going to take a full year and you won't get to that same place until. Cool. Next, uh, next year. Um, that's something to think about in terms of planning. Um, and then the other thing is like, if we bought something, is it going to give us something that we couldn't get otherwise, or without, you know, expending a lot of energy, things like compliance and just industry compliance. Um, that's something that also you can get, um, from something that's going to cost a little bit more versus something that you have to. Create and then go through the compliance and auditing, uh, cycle to get that same, like, um, certificate or compliance level. That's important to, uh, someone that either is investing in you or to your company.

Mike Gruen: 00:18:54

Yeah, I think it's always funny when you fall in love with features that you didn't even realize you. Like, oh, wait, now that I know this guy, you know, these people can supply this. I almost feel like it's a requirement. Whereas going into the, you know, going into that decision making, you might not have even considered that as something that you needed. And next thing you know, there's some vendor out there that's actually able to do something that you hadn't even considered as an option. And now it's suddenly a requirement, even though you never thought of it in the planning stages.

Tim Winkler: 00:19:21

What goes into like the process of comparing one vendor versus another? So you, you've settled on this feature that you think will, will add some value. Um, is there a, you know, specific research arm, uh, within the department that's tasked to go out and see what else is out there before we settle on this?

Mike Garrett: 00:19:41

That would be awesome. But no, that's me. Uh, exactly what Mike said, uh, listing out the four or five features that you actually need, uh, for this piece of your architecture. And starting with that and seeing who does those things really well, putting those into a short list and then, you know, comparing them on other dimensions like price or ease of use or ease of uh, integration. Um, that's awesome. That's the beginning of the journey. It's a mistake to go the other way around saying which company is like the most well known, uh, and can give me, you know, 100 different things or who's the company that can give me 120 things, but you're only going to use 5 or 10 of them. I do

Mike Gruen: 00:20:23

find it funny that you bring that up because when I was building out the, um, our data stack at cyber, um, I sort of had an idea of like, well, this is a pretty common. Architecture, whatever, but I'm going to go out data science team myself, we're going to go out. We're going to look at all these different things. And in the end, we basically spent several months, not several months, probably several weeks, uh, doing all of these, like, experiments and weighing all of our options and would have ended up going with, like, well, it turns out the standard stack is actually the standard stack, um, you know, for, for what we were doing, it was kind of funny, um, how that can prove out, but you're right, that it's a pitfall to sort of look at, like, what's the, What's the well known and, um, and then just going with that can sometimes lead to bad outcomes as well. Um, I'm curious, you know, Ian, what your thoughts are on, on how you go about that comparing vendors and stuff.

Ian Lotinsky: 00:21:16

Yeah, well, I think everything I agree with everything we've said so far about starting with what's critical and building out from there. Um, and I want to go back to something, uh, yeah. Mike said earlier, which was, um, around, you know, the industry you're in the, in the supporting infrastructure that has to be in place. Um, sometimes the group you're integrating with has more than just software. Maybe they've got a support team that comes along with, um, you know, the service. Um, maybe, um, There's a group that then has to, you know, integrate, you know, that software with your customer software or their I. T. Infrastructure. Um, maybe, uh, you need to get to know that. That team to understand, you know, where are we going to fall in the rank of priorities based on how we're using the product, the size of the contract we're going to get into, are they going to be responsive to our needs and the needs of our market? Or are we. Kind of using this for an unofficial purpose, or are we so low on the totem pole that we're just not going to be able to get any help, even if there are bugs that need to be fixed. So I think understanding what's the support system around this, either for you or for your customers or for your market. Could be a helpful one.

Mike Gruen: 00:22:44

Yeah, definitely. The support aspect of, um, you know, are we in the 80 percent of the use cases that this company that this vendor supports? Are we in the 20%? Are we in a new market that they're trying to get into? And if that's the case, what does that mean? Does that mean we're going to get actually better support because we're sort of a test client? Or does that mean we're going to get worse support because we're not quarter their business and they're not really sure yet if this is really the direction they want to go? I've definitely experienced that. Yeah.

Ian Lotinsky: 00:23:11

One that we've, um, we've experienced a little bit has been, um, just understanding the connection with competitors, or even if this service is. A competitor an hour could be a competitor, uh, later, um, sometimes, uh, you know, companies acquire the companies and sometimes those are your competitors. And as much as we'd like to believe, um, that people are making decisions, you know, in a vacuum altruistically, uh, this is not the way the world works, right? There's a competition and, um, you have to be able to, to, to assess and kind of empathize. Like if we were in their position. Um, how would we prioritize, you know, our own company here, um, to make sure that you're you are going to get your, needs met?

Mike Gruen: 00:24:03

Yeah, that's a great point. Um, I've definitely experienced that as well, where a competitor of ours actually acquired. Companies that we had good relationships with because for them, it was sort of the same build versus buy, but they decided to buy the company rather than just buy the product or buy the service. So, right next thing, you know, you're, you're sort of in a scramble mode where now you're, you had a relationship that just got acquired by 1 of your competitors. And that's always a tough situation.

Tim Winkler: 00:24:32

We actually see that more and more often is companies, you know, being bought out just purely for the employees themselves for the engineering talent themselves versus having to go through the, the hassle of recruiting the next 5 engineers. Let's just go buy this. Let's just go buy this company.

Mike Gruen: 00:24:48

Right? Yeah. We'll hire.

Tim Winkler: 00:24:50

Yeah, obviously on the other end of the spectrum here when it comes to that, but there's also more options for that. I was just looking at a, uh, heard it on a podcast, a company, uh, called micro acquire, which is startups, you know, sass companies selling. At the very infancy infancy stages, but they've got some sort of an MVP. They've got some sort of a, a product that's being used as generating some sort of a revenue. And it's scoop it up, you know, via this, you know, no hassle kind of startup acquisition platform. So it's definitely becoming more and more frequent.

Mike Gruen: 00:25:26

So, so we've been talking a lot about just like build versus buy, but, um, you know, you know, Ian, I know, you know, before we, before we started recording, we were talking a little bit and I think you have an interesting story about, like, sort of, uh, like a middle ground where, you know, you, you came up with a sort of an interesting way of, of not making that, like, it doesn't have to be just purely build versus buy. There's other options out there. Right. I'm hoping you understand what I'm referencing.

Ian Lotinsky: 00:25:52

Yeah. So, um, in addition to the traditional, you know, buy versus build, um, perspectives, there sometimes can be creative ways that you can apply capital to, um, to accomplish, uh, goals, particularly as it relates to open source. Um, and there's a story I love to share where back when I was working at, um, a startup called living social, I was leading a team that was working on, um, a product called takeout and delivery, and it was for ordering food. Um, for takeout delivery. And we needed to be able to let users search for things within their delivery range. Um, and we needed, uh, geo search capabilities in Sphinx, which is a database index. And We're looking at how to build this ourselves. So we need to add these geo search capabilities to Sphinx. I'm trying to figure out, you know, do we add this ourselves? Do we, um, totally switch to a different, you know, index and, um, What would it look like to contribute to this open source project? And an engineer on my team, Andrew Hunter, uh, came to me and said, Hey, I have a great idea. Why don't we reach out to the maintainers of the project and see if we can pay them to do this work? Sure enough, they did custom work and gave us a quote for how to add the capabilities. And these are capabilities that were not just things that we needed. It was stuff that really we needed. Um, anyone who was doing geo in Sphinx could utilize the, um, the double benefit of us being able to pay for this was that they're going to build it into the, into part of the core offering. So we would benefit from the long term maintenance of this thing, even with the initial investment that we made, we wouldn't have to maintain it. We wouldn't have to, you know, keep in line with all the updates that were happening upstream to the main project and try to keep, you know, our customizations in line with it. We could basically benefit, uh, for as long as they continue to support, you know, that sort of core functionality on their product. Um, and, uh, I was real creative way of thinking about how to apply capital. To basically a, um, a build. It was kind of a build and buy, right? We were paying for build on top of a buy, um, that, uh, that ended up just working out for for us and for the open source project in this community. So I've used this tactic a few times now, and it's, uh, it's actually worked, um, for a few different open source projects. And I've even used it against some service providers when they're not able to ship something I've offered my team's time to join their team. For a period of time to go build the thing that we need. Uh, and thankfully each time that I've offered that it's kind of eliminated excuses and people have actually built what we needed. Um, but that's always something that I've offered, uh, in a pinch to try to get, uh, get stuff that we need, uh, built into the stuff we've already purchased.

Tim Winkler: 00:28:58

R. I. P. Living Social, by the way, that was one of the D. C. startup sweethearts back in the day. I think it was Groupon that, that bought them, wasn't it?

Ian Lotinsky: 00:29:08

They did. And, um, yeah, it was a great, great group, um, it has a group of engineers and a lot of folks that I have relationships with now, uh, professionally came from that great organization.

Tim Winkler: 00:29:21

Yeah. It's a lot of entrepreneurs actually that's, that, you know, spun up the next wave of startups in the area came out of living social. The really, really cool story.

Ian Lotinsky: 00:29:31

There's a lot of buying and a lot of building.

Tim Winkler: 00:29:34

That's right. That's right. Thank you. Good stuff. Well, uh, do we have any other like closing thoughts on the topic? Um, before we jump into the, the wheel of, uh, hatchpad community over here?

Mike Garrett: 00:29:48

Yeah, well, it's a It's not a build versus buy, uh, black or white issue. Obviously, there's a lot of nuance in it. Uh, really? And it's not just for everything that you're doing. It could be for one part of your architecture, one part of the company. Uh, but it's something that you really should think about. Uh, yeah. For me, earlier on in my career, it was just, let's build everything. I know how to do it. I've seen a video. I can do it, but no, later on, there's a lot more trade offs, a lot more things you can think about that can help you accelerate the amount of things you could be doing as a company, as a whole, if you think about it just a little deeply. A little bit more deeply

Tim Winkler: 00:30:26

cool. Mike g, do you got anything else? You want

Mike Gruen: 00:30:31

me? I think off of what Mike was saying, the, um, like, I think from a career perspective, that's a, that's a great point is like early on. I think a lot of engineers, um, think about just, they want to build things. They want to build things. You know, the, the, the advantage to integrating something and seeing how something else is built and then, um, that's a, that's just a great skill set in general is learning how to integrate services together and sort of, um, mask, you know, uh, shortcomings and other party, you know, and other people's stuff. Um, but I think that's, I think that's a similar journey that I had, which is like, right in the early days, I wrote everything and then, um, you know, now it's, it's really, um, I think. Okay. About like, what is where do we really want to spend our time and what do we really want to be doing? And I think that that's something that I think comes as you as you progress in your careers as a developer or as a product manager or whatever is really making sure to focus on the on the value on what you're trying to provide to your customers.

Tim Winkler: 00:31:34

Well, said, all right, well, on that note, why don't we wrap up the, uh, the main topic here and transition to, um, you know, something that obviously is a part of, you know, our, our podcast, um, touching on career development. Um, you know, we obviously want to add value outside of just, you know, the pure tech talk, um, and this wheel here will help serve and, uh, guiding us, uh, down some different topics. So what I'll do is spin this wheel and grab. Gravitate towards a specific category, uh, that's centered around career development, such anticipation,

Mike Garrett: 00:32:16

what a fine wheel

Tim Winkler: 00:32:19

promotions. All right. So the way that we'll do this is just, um, we'll bounce back and forth between both Mike and Ian on this here. And the question I've got here is centered around promotions. It's pretty general, uh, but, uh, you know, I, I think this is an area that a lot of folks don't really know how to anticipate asking, uh, for a promotion. So I'm curious to hear how you, uh, would navigate yourself asking for a promotion, um, in your role.

Mike Garrett: 00:32:56

Yeah, I could start. Uh, so navigating promotion for me. Um, it's the same advice I give to the people that are also on my team is to do so in like an evidence based way. Um, so we use a, uh, you know, a ladder, um, that has, you know, what our current position is, what our current level is, and then the next level up. So I say go to that next level. Uh, get those four or five different bullet points that are in all the different categories and I'll map them to what you've done over the last quarter. Uh, and then that gives a very solid, um, piece of solid document that has everything that says what the next level, um, what you're expected of at the next level and the fact that you've done it. So there shouldn't be any, uh, qualms about bumping you up there if it's the time to do so in your company. Do you be able to do that? Because you've done it. You've just demonstrated that for the people that need to see that. Um, and obviously if Yeah, if they don't want to bump you up at your current company, you also have the same body of work to give to the next company. If you want to apply for that senior role or the engineering manager role or whatever role there is nice.

Ian Lotinsky: 00:34:13

And if, um, if you don't know the process by which your company or your manager, uh, evaluates. Uh, talent and decides on promotions, that's where you got to start. And there's no better time to crack open that conversation with a new manager, uh, when you first join up, right? Whether that's you joining a new company or you be reporting to someone new in an organization Um, early on in one on ones, either formal or asking for some time, just talking about general things about the department and their leadership and how you can follow and support, um, definitely ask about, Hey, how does one progress, you know, in this organization, what's the criteria, what's the cadence, you know, is this, is our annual review process is or not, um, what's, what are the things I need to be mindful of, um, being clear on, you know, what, Your organization or leaders expectations are on that front is a good place to start. And no matter what sort of framework is in place, there's always a person or people behind the decisions around these sorts of things. So, um, although you do need to be really clear about, you know, what, what's the criteria, what's, what should be my expectations and, um, Their expectations, et cetera. Um, just knowing, you know, what they value and maybe even ask that explicitly or, you know, what are the things you want me to focus on, right? Leaning into personal development on the job and communicating with your leader very clearly that I'm eager to grow. Um, you know, that usually translates to demonstrating Uh, success because you're paying attention to what your leadership, um, cares about and when it comes time for promotions or, um, pay increases and things like that, you know, hopefully you've connected enough, uh, with what your leaders are pushing for that, um, that you come to mind.

Mike Gruen: 00:36:08

Yeah, I mean, I think both of you are sort of saying similar things, which is, it's, it's not a backward looking conversation as much as it's a forward looking setting expectation conversations of what do I like? Yeah. It's not about this is the, this is all the things I've achieved over the last year. I deserve a promotion, which is a very difficult conversation. I think to have, as opposed to more of a forward looking. Well, what are the things I need to accomplish? And what are your expectations of me? And so and so forth. And so that when it comes time for that promotion. Everybody's already established what that criteria is. And I think that's a pretty common. I think it's also a hard conversation to have when you like, especially earlier in your career where you might not even realize that that's a conversation you need to have. Like, what, what is, what does career growth look like here? What are my options? What do I have to do? But those are, those are definitely the conversations you need to have to make the other conversations about promotions much easier. Otherwise, you're just sort of surprising your manager and it's going to be a. Okay.

Ian Lotinsky: 00:37:04

Uh,

Mike Gruen: 00:37:05

yeah, yeah.

Ian Lotinsky: 00:37:07

And what one thing that, um, is advice mostly, I think, to folks who. Maybe you kind of navigating this for the first time, you know, sometimes you even check off all those boxes and you might even get your manager to agree that like, yeah, you improved here. You're doing this now, but you're still not getting, you know, such and such a promotion. That can be really difficult for engineers in particular, because we're very much. Caught up into the details and there's a, there's this concept called gestalt, which basically is that the sum does not always equal the sum of the parts or like the total. It's not equal to some of the parts. Um, and that's just a, it is a thing about how, um, uh, businesses work in terms of deciding who's in what position. Um, and ultimately deciding on, you know, promotions and pay sometimes. There are, you have to take a step back from the details and look at the complete picture and just say, you know, does this make sense for organization? Doesn't make sense for this person. And if you're on the receiving end of that, in a way in which you feel is unfair, it can be really destructive to then try to bicker over. I had this and I did this and I got, you're probably never going to win that argument. Um, instead, I think it's best to just express, you know, You know, honest disappointment. Oh, I'm disappointed. Like I, I thought, you know, I was on track to, uh, to get into the next level. What else can I do? And, and, um, and, and, you know, it is a manager or leader's job to lead people, right. And to be clear about where they need to grow. Um, and even be clear about constraints that exist in the organization. Um, uh, yeah. That may be in the way, but, um, it's possible to lean into that sort of disappointment still with some optimism and eagerness to work with your manager to figure out, okay, what's next? And you're not always necessarily tied to an annual, you know, review or promotion process, right? Sometimes things happen mid year or even partway through the year. So, Leaning, leaning into those as opportunities rather than seeing them as fights to be had, um, you know, can just, uh, help you achieve, you know, that goal maybe even more directly because you're having this difficult but explicit conversation around, um, you know, what it is you really need to. To get to the next level,

Tim Winkler: 00:39:18

I can even speak to the, I think there's, um, different phases, uh, within the startup ecosystem, right? Where when you, when you talk about super early stage companies, you're at a point where, you know, so call it under 10, uh, everybody's almost a bit of a speed bump. A generalist, right? Um, and you're expected to kind of partake in different departments and step up when needed. Uh, then you start to evolve outside of that scope and that size. Like similar at Hatch, what would happen is once we got beyond, I'd say, you know, 12 to 15, you start seeing departments forming and people become specialists and then they want more autonomy. You know, when they're, when you're talking with them about, you know, what path do you want to go down? Do you, do you see yourself be being more in the marketing department? Um, if that's the case, you know, then posing that next question of, do you want to be a people manager or do you enjoy more of this, uh, I see type of role, um, because, you know, creating multiple paths will have different outcomes in terms of promotion, pay, uh, level of effort that you you're responsible for. Um, and so what we see is like, as startups evolve and departments start to gain more headcount, uh, that's a clear sign of. Start thinking through what were your career growth paths here. Uh, if you haven't already, um, we on the concept of build versus buy, we actually invested in a, in a software, uh, that was, you know, for people management and it had clear cut outlines of. Career growth tracks that then you can use as a template, but you know, it's personalized to your business. And it was with that, that, you know, it was really helpful for us to, um, make sure that, you know, our, our team members were aware, like we do have development paths here. Like we're not just going down this stagnant path, but as a startup, you know, oftentimes that's just kind of thrown. You're thrown into that. Um, it's not so natural of a situation. And so I think it's interesting to think about it too, from, uh, the size of the company and when you might be pushed into this path of thinking about promotions for folks.

Mike Gruen: 00:41:33

And I think on the, um, the people manager versus IC, I think technology, especially like product engineering, there's a lot of roles where there's no reason why you can't sort of Move between them over the course of your career. I don't know what your, your experiences are. Um, and I'm like, but like mine, I, you know, I managed, you know, I led teams and then I went back to being and I see. And then I went, then I was a manager again, and I went back to being, you know, the developer again and sort of, um, you know, it's, it's 1 of those things. It's not like, once you choose a path, you'll, you're, it's, you know, going to forever dominate your destiny, right? It's like, you can, you can move, you can, you don't always have to, uh, and I'm sure that's, you guys have had similar experiences. This.

Mike Garrett: 00:42:13

Yeah, absolutely. You're not, uh, you know, destined to go on this upward ladder. You can go up, you can go down, you can do lateral moves. Like you said, go from a people manager, going back to an IC, uh, it's all about what you want at that stage in your life and that stage in your career. Um, but it's also about, you know, you know, what you Making it known what you want advocating for yourself because you could be on this, you know, continual escalator just because you've done the previous job and you've had X number of years of experience. Therefore, you should be able to do the next one. But do you want to do the next one? We've had a few people who have come through, uh, Through our hiring pipeline, who have been at that next level up, uh, and are applying for jobs that are, um, lower down, but it's, you know, this balance between, you know, what do you want to do in terms of like growing your career versus having less responsibilities, but more free time. Uh, that's up to you to decide. Um, you could still be great at all those different levels. Uh, it's just for you to decide where do you want to be in your career at that moment? All

Tim Winkler: 00:43:18

right. Well, I think that was a success. I think the wheel is, is proven it's worth right now. So we flipped the wheel around and it has your favorite cocktail on there that you'll have to pick from. So, um, no, thank you guys. It's been really fun at hanging out. Uh, definitely a good insight. Great. Um, looking forward to, uh, putting this one together and pushing it live.

Mike Garrett: 00:43:42

Nice. Awesome. This was fun.

Tim Winkler: 00:43:44

Yeah. Thanks for joining

Mike Gruen: 00:43:45

us. Great.