Watch the Episode
Listen to the Episode
Join us as our hosts, Tim and Mike, talk to startup engineering leaders Mike Garrett and Ian Lotinsky. Mike Garrett, an Engineering Manager at Caribou, is no stranger to startup life and has experienced the startup lifecycle from pre-money through acquisition. Ian is the VP of Product, Engineering, and Design at Imagine Learning. He’s been building web products since the mid-90s for organizations of all sizes. In this episode we take a deep dive into the build vs. buy software debate.
You’ll learn:
– How real tech leaders make the decision to build or buy software
– The pros and cons of building vs. buying software
– Practical tips on how you can make the right decision for your team
Subscribe 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. Join host Tim Winkler (creator of hatchpad) alongside co-host Mike Gruen as they bring together two guests to dissect topics at the intersection of technology, startups, and career growth.
Sign-Up for the Weekly hatchpad Newsletter: – https://www.myhatchpad.com/newsletter/
Follow us on Social!!
~https://twitter.com/my_hatchpad
~https://www.linkedin.com/showcase/hatchpadcommunity/
Transcript
Welcome guys! As you’re aware, this is The Pair Program. I’m your host, Tim Winkler, accompanied by my cohost and right-winger Mike Gruen. Mike, it’s good to see you.
Yeah. Nice to see you. For those not watching we’re both wearing our hockey jerseys. I am not a conservative right wing. Just put that out there.
But yeah. So yeah, welcome to the episode. And we’d like to start every episode by asking our guests what their favorite pairing is. Ian, why don’t you, why don’t you lead us off and what’s your pairing?
Sorry. I practice this one at home with my kids last night. My favorite pairing is gadgets and awkward silence.
That’s good. That’s good. Do you have any dad jokes up your sleeve or that wasn’t dad joke that wasn’t that year? I should’ve waited for more awkward silence. You know how you measure dad jokes? On the seismograph.
And they may have the awkward silence. Perfect silence. Yeah, Mike, what’s a good pairing for ya. For me. It’s a bourbon and popsicles. That’s an interesting, any particular flavor pops. Okay. Whichever ones are in the fridge or in the freezer. I’m an adult so I can have whatever I want.
That’s true. Just don’t mix those up when the kids are around.
I’m gonna go with Alex Ovechkin and the Washington capitals. Based on the fact that I’m a huge DC cats fan here. And Mike, you were wearing a Rangers Jersey, I guess that makes my favorite pairing heartbreak and misery. So
I’m watching football team fan here as well, so I can certainly relate. Awesome. Good stuff. Why don’t we jump into the, the reason that we’re all here today and riff on this. Discussion around a build versus buy or buy versus build. Obviously something that is debated, amongst, engineering leaders, product owners, founders of different startups on a daily basis.
Mike, why don’t you give us like, your definition of build versus buy and kick off with your thoughts on. 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, buying a solution?
There are schools of thought, hence, why we’re both here on both sides of the issue, but it really boils down to what can we do as an engineering organization to advance our own.
Nice Ian. Any, anything on that note or is similar feelings? Sure. Yeah, I think the, usually for any particular. Component you’re looking at or service, you’re trying to decide, do we build or buy this thing? But when you’re looking at the whole portfolio of some sort of a product or company it’s usually not entirely buy versus build.
It’s usually what are we buying and what are we building? So that we’re strategic in our scarcest resource, which is usually. Obviously money is involved. The economics do play into it. But a lot of times it’s about opportunity costs, as your product company weighs different different options for different aspects of your total.
Yeah. I think that leads into a great point on opportunity cost and build spy. And I think there’s hidden costs as well. As you hinted at even when you’re buying a solution, it’s not just buying a solution, right? There’s going to be some time costs to implement it integrated into your systems.
And I think that’s one of those hidden things. I’m curious what your guys’ thoughts are on that. Yeah. Yeah, I think when it comes to hidden costs or just things to take into consideration, there’s more than just the price tag of, build versus buy there’s things like what’s the long-term cost of this in terms of maintenance because whether you buy or build part of your team probably is going to have to support something.
Is this thing that we could buy stable enough to rely on, or is it going to be hidden and cost and having to patch, problems either, some sort of open source project that you can contribute to or something that you have to negotiate with a product team somewhere that you’re paying or even having to.
Sometimes pat around issues, using a capsulation to encapsulate a service or something and figuring out how do you fill in the gaps? Whether those are capability gaps or technical gaps, because something just doesn’t work. You have to really look at total cost of ownership, kinda like when you’re buying a car.
It’s good to know now what’s not just to make a model and the cost of acquiring this, but what’s the maintenance typically look like for, the sort of. I could certainly talk to, when you talk about building something as well. The cost of recruiting right now is at an all time high.
The cost of acquiring talent, is becoming more and more difficult these days, given the market and engineering salaries are increasing at drastic rates, more so than they ever have in years past. And. You’re going to inherit that cost. It’s also gonna take some time to find the right individuals.
And so if you’re going to be pretty particular, which most startups tend to be with finding that right engineering mold, it’s going to take a little bit of time and you’re going to pay for it. So weighing that into the equation certainly should play apart. So yeah, I’m curious There’s the cost side.
And then there’s other decisions, what other factors do you want to take? 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 it or build it in house, buy it, some sort of something in between. I don’t know, Mike, what your thoughts are, but obviously I do actually, cause we talked a little bit about this, but but yeah, I’m curious, what what other characteristics you look for constraints you.
Yeah, outside of the monetary, cause they’re all, there’s also the human cost. So cost of like we mentioned, maintaining the software itself also acquire knowledge. So for a piece of technology where it’s not our core strength or it’s not something that the 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 maintaining a cluster having a knowledge about ha when we could, acquire something that has all of that and a whole company standing behind making sure that those things are, thought of and are, have an SLA behind there’s also that, and the other cost is in choice.
I think back to assembling, at least on the front end with, choosing between like angular JS and react where one was an all-in-one tool kit, and the other one was, best of breed build up your own. That’s 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’s front end language do we use versus we use we integrate someone else’s SAS product that has. All that kind of behind the scenes and we just interact with a connection string. It really reduces the amount of cognitive load that your team has to deal with versus, building something up where, all the intimate pieces of it.
But is that worth it? I think it’s in 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 what you’re hinting at. Mike Ian, I’m curious what your thoughts are. Yeah, I think. Cost is important, housed African eSports.
This is important. A lot of times though, it needs to start with what’s the strategic value of this. Does this 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.
Make it better or extend it because of that feedback or that market strategy? Or is this something that’s just a commodity service that’s something that’s not going to need a lot of iteration, something that. Really it’s the same sort of service or functionality across all, all or most web products or software products or whenever you’re building that can just be outsourced without worrying about having to have it differentiated from other people’s products.
It’s a great way to involve, the business team in the conversation around build versus bias, 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? Yeah, I think that’s right to the whole Core to business is always one that I’ve used as a main driver.
Is this really part of our actual intellectual property? Is this what we find is this really where we want to be spending our time? Is this where we want to hire developers? And I think what’s amazing about, and you guys, we’ve all experienced it over the last 10, 20 years, which is everything is becoming more and more commoditized.
So it used to be the case that you needed to have somebody who like, if you wanted to build an authentication system, you had no choice, but to build that in yourself and now there’s, authentications to services, it’s basically becoming commodity. There’s a bunch of players in that space.
Infrastructure is another place, databases time and again, I think that’s just the direction that everything is going is pretty soon. It’s really just a simple. Third-party pieces that do all of the things that you don’t want to have to deal with. And I think that’s, I think it’s the build versus buy decisions.
Just getting that much more complicated because in the past it was a little more straightforward. There were less options. And so it’s, I think sometimes I, and I’ve experienced this recently at places I’ve worked where it’s it’s hard is this corridor business is actually sometimes a really hard question to answer.
There’s more discipline that has to go in now into not accidentally just adopting something because it’s available. That and these, 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 even if we do decide to buy right now, What’s the future switching costs involved in in, in the inevitable future that tends to come at some point, especially in a multi-year journey where you’re doing having to convert stuff that is purchased to custom, because your, as your needs develop, just switching from one, one thing that you’ve purchased a different thing, right?
Like every, you can outgrow a thing or I can think of a number of. You get in early at a company, like it’s an early adopter to their platform and then, you’re using it and you, and they make maybe a pivot and then next thing, you’re this like legacy customer using the system that they don’t really want to support anymore.
You’re left okay, now what do we do? We have to find somebody else to migrate to. So there’s that type of stuff as well. Yeah, absolutely. And that’s when it comes with super important. How old are your data and coal that sacred because you do, you will want to switch from one platform to another, as you outgrow one where it be where either the early adopter or it Metro needs at one point, but now they’re 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 in that a lot more, more quickly. You’re able to swap over. If you hold onto your data in a way that it makes that transition transparent to your company, to, or users and it gives you that value versus one where you’ve built it up from scratch and you can no longer, you don’t have that autonomy.
You are just at the mercy of whatever you have assembled. Yeah, man. 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 building these things.
I’m curious, I’ve got a quick question. As far as the key stakeholders that go into that decision, that final decision, is it is it usually. A group decision, let’s loop in the product team as well. Let’s get the CTO and board or where, what is the, who’s the team at hand that’s going into this, decision making process, at least for me and my team, it depends on I guess the size and the impact.
The thing that you’re trying to integrate in if it is, a one-off tool that can help your team move quickly it’s not too terribly expensive. The decision can rest within our team. If it’s something that’s going to impact more of our users Yeah, very centralized piece of technology, like an authentication system.
That’s going to require the full engineering team and like 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 look the monetary impact to the rest of the company.
Yeah. I think for when I think about it, right? Those stakeholders are, first of all, not every tool is necessarily not everything that you’re thinking about is a user facing. So if it is end user facing, then probably product needs to get involved. If it’s 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 I think that’s, those are all important things to keep in mind and making a good case. I don’t know, a cow, like I think a lot of startups 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. Everybody’s yeah, no brainer. I’ve definitely experienced all of it. So I’m curious what you guys’ experiences have been?
I’ve got an answer with Ian love if he’d start. Yeah. So whenever it’s involved money, it’s definitely needed to have a little bit more due diligence because. We’re going to be spending cash that could be used on our burner, our staff burn rate. So that’s one thing that comes to mind.
And I think there tends to be a default assumption that we can build all things. And so you have to just break out of that mold. And I think sometimes it’s upon the build team to be the ones who. Mr. Paul, the con bond court and say, hang on, we are stopping the assembly line here.
We’re going to talk about the strategic, talk about the costs, long-term, short-term et cetera and try to figure out because they’re the ones who have to maintain this, what’s the right process to be convinced. And I think when we talked earlier about that spectrum of commodity versus strategic value, extra strategic value for your.
That comes into play and is something that your whole product team has to lean into whether or not they’re part of the engineering team that support this are implemented. Yeah. Makes sense. Yep. And then from my prospective same thing, we write out a document and it’s designed to basically lay out if we.
If we built this, these are the important things to think about it. 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 costs, or if you buy something now depending on how long it takes to integrate it, it could be, you fully utilizing all of its feature set within a month or so versus building something it’s going, gonna take a full year and you won’t get to that same place until.
Next next year. That’s something to think about in terms of planning. 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 spending a lot of energy, things like compliance and just industry compliance. That’s something that also you can get from something that’s going to cost a little bit more versus something that you have.
Great. And then go through the compliance and auditing a cycle to get that same, like a certificate or compliance level. That’s important to someone that, either is investing in you or to your company. 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, the, these people can supply this.
I almost feel like it’s a requirement where he’s going into the, going into that decision making, you might not have even considered that as something that you needed. And next thing 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. W what goes into the process of comparing one vendor versus another. So you’ve settled on this feature that you think will add some value. Is there a specific research arm w within the department that’s, tasked to go out and see what else is out there before we settle on that?
That would be awesome, but no, that, to me exactly what Mike said listing out the four or five features that you actually need for this piece of your architecture, starting with that, and seeing who does those things really well, putting those into our short list and then comparing them on other dimensions, like price or ease of use or ease of integration.
That’s the beginning of it, the journey, it’s a mistake to go the other way around saying which company is like the most well-known and can give me, a hundred different things or who’s the company that can give me 120 things, but you’re only going to use five or 10 of them. I do find it funny that you bring that up because when I was building out the our data stack at cyber dairy I had an idea of this is a pretty common.
Architecture or whatever, but I’m going to go out data science, team myself. We’re going to go out and we’re going to look at all these different things. And in the end we basically spent several months, probably several weeks doing all of these like experiments and weighing all of our options and would have, and ended up going with it turns out the standard stack is actually the standard stack.
For what we were doing, it was funny how that can prevent, but you’re right. It’s a pitfall to look at what’s. What’s the well known and and then just going with that can sometimes lead to bad outcomes as well. I’m curious, Ian, what your thoughts are on how you go about that comparing vendors and stuff?
Yeah. I think everything, we, I agree with everything we’ve said so far about starting with what’s critical and building out from there. And I want to go back to something that like I said earlier, which was around, the industry you’re in the supporting infrastructure that has to be in place.
Sometimes. The group you’re integrating with has more than just software. Maybe they’ve got a support team that comes along with the service. Maybe there’s a group that then has to integrate, that software with your customer’s software or their it infrastructure. Maybe.
You need to get to know that, that team to understand 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. 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 this support system around this, either for you or for your customers or for your market. Yeah, it’s definitely the support aspect of are we in the 80% 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 starting to test client or does that mean we’re going to get worse support because we’re not core to their business and they’re not really sure yet if this is really the direction they want to go, I’ve definitely experienced.
Yeah. And one that we’ve we’ve experienced a little bit has been just understanding the connection with competitors or even if this service is. A competitor an hour could be a competitor later. Sometimes companies acquire the companies and some of them, sometimes those are your competitors.
And as much as we’d like to believe that people are making decisions in a vacuum altruistically. This is not the way the world works, there’s a competition. And. You have to be able to assess and empathize, like if we were in their position how would we prioritize, our own company here to make sure that you’re going to get your know your needs met.
Yeah, that’s a great point. 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 the same build versus buy, but they decided to buy a company rather than just buy the product or buy the service.
So next thing you know you’re in a scramble mode where now you’re, you had a relationship that just got acquired by one of your competitors, and that’s always a tough situation. We actually see that more and more often is companies 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 five engineers, let’s just go buy this. It’s just go buy this company, right? Yeah. Obviously on the higher, 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 heard it on a podcast, a company called micro acquire, which is startups, SAS companies selling.
At the very infancy stages, but they’ve got some sort of an MVP, they’ve got some sort of a product that’s being used is generating some sort of revenue and scoop it up via this, no hassle kind of startup acquisition platform. So that’s interesting, more and more frequent. Yeah. So we’ve been talking a lot about just build versus buy, but Ian, I know, before we started recording, we were talking a little bit, and I think you have an interesting story about a, like a middle ground where, you know, you, you came up with a.
Sort of an interesting way of not making that. Like it doesn’t have to be just purely build versus five there’s other options out there. I’m hoping you understand what, yeah. In addition to the traditional, buy versus build perspectives, there sometimes can be creative ways that you can apply capital to to accomplish.
Goals perfectly as it relates to open source. And there’s a story I love to share where back when I was working at a startup called living social, I was leading a team that was working on a product called takeout and delivery. And it was for ordering food for takeout delivery. And we needed to be able to let users search for things within their delivery range.
And we needed. Geo search capabilities in Spanx, 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. And I’m trying to figure out, do we add this ourselves? Do we totally switched to a different index? And what would it look like to contribute to this open source project?
And there’s your, my team, Andrew Hunter 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.
We’re not just things that we needed. It was stuff that really anyone who was doing geo and swings could utilize the 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 meet. We wouldn’t have to, keep in line with all the updates that were happening upstream to the main project and try to keep, our customizations in line with it. We could basically benefit for as long as they can do to support, that sort of core functionality on the.
And I was a real creative way of thinking about how to apply capital to basically a a build ability. It was the build and buy, we were paying for build on top of a buy that that ended up just working out for us and for the open source project in this community.
So I’ve used this a few times now, and it’s a, it’s actually worked 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 teams time to join their team for a period of time to go build the thing that we need.
And thankfully each time that I’ve offered that it’s eliminated excuses and people have actually built what we needed. But that’s always something that I’ve offered in a pinch to try to get get stuff that we need built into this stuff with. Alright, P living social, by the way. That was one of the DC start-ups sweethearts back in the day.
I think it was Groupon that bought them, wasn’t it? They did. And yeah, it was a great group as a group of engineers and a lot of folks that I have relationships with now professionally, he came from that great organization. Yeah. It’s a lot of entrepreneurs actually that’s that, spun up.
The next wave of startups in the area came out of living social, the really cool stuff. There’s a lot of buying and a lot of building that’s right, good stuff. What do we have any other closing thoughts on the topic? Before we jump into the wheel of a hatchback community over here.
Yeah. It’s not a build versus buy black or white issue. Obviously there’s a lot of nuance in it, really. And it’s not just for everything that you’re doing. It could be for one part of your architecture or one part of the company. But it’s something that you really should think about. For me earlier on in my career, it was just let’s build everything.
I know how to do. I’ve seen a video. I can do it, but no later on, and 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. Cool. Mike G do you add anything else you want?
I think off of what Mike was saying, the like I think from a career perspective, that’s a great point is like early on, I think a lot of engineers think about just, they want to build things. They want to build things like. The advantage to integrating something and seeing how something else has built.
And then that’s a, that’s just a great skill set in general is learning how to integrate services together and mask, shortcomings in other party, and other people’s stuff. But I think that’s, I think that’s a somewhat journey that I had, which is like right in the early days I wrote everything.
And then now it’s really I think. About what is, where do we really want to spend our time and what do we really want to be doing? And I think that’s something that I think comes as you progress in your careers as a developer or as a product manager or whatever is really making sure to focus on the value on what you’re trying to provide to your customers.
Said, all right on that note, why don’t we wrap up the the main topic here and transition to something that obviously is a part of, our podcast touching on career development. We obviously want to add value outside of just the pure tech talk.
And this wheel here will help serve. And guiding us down some different topics. So what I’ll do is spin this wheel and grab gravitate towards a specific category. That’s third around career development, such anticipation of the fine wheel. Promotions. All right. So the way that we’ll do this is just 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. But I think this is an area that a lot of folks don’t really. No, how to anticipate asking for a promotion. So I’m curious to hear how you would navigate yourself, asking for promotion and your role. Yeah, I can start Navigating promotion for me.
It’s the same advice I give to the people that are also on my team has to do so in an evidence-based way. So we use a ladder that has, what our current position is, what our current level is and then the next level up. So I would say I would go to that next. Get those four or five different bullet points that are in all the different categories and then map them to what you’ve done in over the last quarter.
And then that gives a very solid piece of, or a solid document that has everything that says what the next level what you’re expected of at that next level. And the fact that you’ve done it. So there shouldn’t be any no qualms about bumping you up there. If there if it’s the time to do so in your.
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. And obviously if it, 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. And if if you don’t know the process by which your company or your manager evaluates 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 when you’re first joined up, right? Whether that’s new joining a new company, or you be reporting to someone new in an organization.
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. Definitely ask about, Hey, how does one progress, in this organization, what’s the criteria, what’s the cadence, is this is our annual review processes or not.
What’s what are the things that I need to be mindful of? Being clear on, 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.
Although you do need to be really clear about, what are the, what’s the criteria, what’s what should be my expectations and their expectations, et cetera. Just knowing, what they value and maybe even ask that explicitly, or, what are the things you want me to focus on, right?
Meaning into personal development on the job and communicating with your leader very clearly that I’m eager to grow. That usually translates to demonstrating Success because you’re paying attention to what your leadership cares about. And when it comes time for promotions or pay increases and things like that, hopefully you’ve connected enough.
With what your leaders are pushing for that that you come to mind. Yeah. I think both of you are saying similar things, which is, it’s not a backward booking conversation, as much as it’s a forward-looking setting expectation conversations of what do I like? It’s not about, this is the, this is all the things I’ve achieved over the last year.
I deserve a promotion. Difficult conversation, I think to have as opposed to more of a forward-looking what are the things I need to accomplish and what are your expectations of me 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. Especially earlier in your career where you might not even realize that’s a conversation you need to have, like what is, what does career growth look like here? What are my options? What do I have to do? But those are definitely the conversations you need to have to make the other conversations about promotions, much easier.
Otherwise you’re just surprising your manager and it’s going to be a, to be an awkward conversation. One thing that is advice mostly, I think the folks who. Maybe you navigating us for the first time, sometimes you even check off all those boxes and you might even get your manager to agree that yeah, you improve here.
Are you doing this now? But you’re still not getting, 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 Psalm does not always equal the sum of the parts or like the total.
It’s not equal to some of the parts. And that’s just a, it is a thing about how businesses work in terms of deciding who’s in what position and ultimately deciding on promotions and pay. Sometimes there are, you have to take a step back from the details and look at the complete picture and just saying it, does this make sense for our organization?
Does it 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 them. Bicker over why had this? And I did this and I got into it. You’re probably never going to win that argument. Instead I think it’s best to just express, honest disappointment.
Oh, I’m disappointed. Like I, I thought, I was on track to to get into the next level. What else can I do? And. And and it is a manager or leader’s job to lead people, and to be clear about where they need to grow and even be clear about constraints that exist in the organization that may be in the way, but 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.
You’re not always necessarily tied to an annual review or promotion process, sometimes things happen mid-year or even partway through the year. So leaning into those as opportunities rather than seeing them as fights to be had can just help you achieve that goal. Maybe even more directly because you’re having this difficult, but explicit conversation around what does.
Yeah, get to the next level. I can even speak to the, I think there’s different phases within the startup ecosystem, right? Where, when you talk about super early stage companies, you’re at a point where, call it under 10 everybody’s almost a bit of. Generalists. And you’re expected to partake in different departments and step up when needed.
Then you start to evolve outside of that scope and that size, like similar hatch, what would happen is once we got beyond, I’d say, 12 to 15, you start seeing departments forming and people become specialists, and then they want more autonomous. When they’re, when you’re talking with them about, what path do you want to go down?
Do you see yourself be being more in the marketing department? If that’s the case, then posing that next question of, do you want to be a people manager or do you enjoy more of this IC type of role? Creating multiple paths will have different outcomes in terms of promotion, pay level of effort that you’re responsible for.
And so what we see is like a startups evolve and departments start to gain more head count. That’s a clear sign. Start thinking through what were your career growth paths here? If you haven’t already we on the concept of build versus buy, we actually invested in a software that was, for people management and it had clear cut outlines.
Career growth tracks that then you can use as a template, but, it’s personalized to your business. And it was with that, that, it was really helpful for us to make sure that, our team members were aware that we do have development paths here. Like we’re not just going down this stagnant path, but as a startup, oftentimes that’s just you’re thrown into that. It’s not so natural of a situation. And so I think it’s interesting to think about it too, from a, the size of the company. And when you. Be pushed into this path of thinking about promotions for folks. And I think on the 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.
Move between them over the course of your career. I don’t know what your experiences are. You in both like mine. I, I manage, I led teams and then I went back to being an IC and then I went, then I was a manager again. And then I went back to being, a lead developer again, and it’s one of those things.
It’s not once you choose a path you’ll, you’re, it’s, gonna forever dominate your destiny. It’s you can move, you can, you don’t always have to. And I’m sure that’s you guys have had similar experience. Yeah, absolutely. You’re not destined to go on this upward ladder.
You can go up and you can go down and you could do lateral moves. Like you said, go from a people manager, going back to an IC. It’s all about what you want at that stage in your life and that stage in your career. But it’s also about, Making it known what you want advocating for yourself because you could be on this, 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’ve come through through our hiring pipeline who have been at that next level up and are applying for jobs that are lower down. But it’s, this balance between, what do you want to do in terms of.
Growing your career versus having less responsibilities, but more free time. That’s up to you to decide. You could still be great at all those different levels. It’s just for you to decide where do you want to be in your career at that moment? We’ll say. All right. I think that was a success.
I think the wheel is proving its worth right now. So we flipped the wheel around and it has your favorite cocktail on there that you’ll have to pick from. No, thank you guys. It’s been really fun hanging out. Definitely a great insight. Looking forward to putting this one together and pushing.
Nice. Awesome. This was fun. Thanks for joining us. Great.
