S1E17 – We Need More Heads … or Do We?

Show Notes

A new project comes down the pike and Engineering asks for more heads to ship said project. Is this a reasonable request or are there other tactics we can use to “do more with less”? Mon-Chaio and Andy explore this common situation from both sides and offer specific diagnostic techniques to move the business forward, whether that’s with additional headcount or without.

Opening music from ⁠Flight of the Conchords – Hiphopopotamus vs. Rhymenoceros⁠

References

• ⁠Cost center⁠
• ⁠Slack time⁠
• ⁠Pair-programming⁠
• ⁠Horse trading⁠
• ⁠SaaS⁠
• ⁠OKR⁠
• ⁠Sunk cost fallacy⁠
• ⁠Hiphopopotamus

Transcript

Andy: Welcome to another episode of the TTL podcast. Today, Mon Chaio and I are going to talk about hiring. Maybe it’s cause we’re going to hire some help, but I don’t think that’s why we’re going to talk about this. It would be nice. But we’re going to talk about hiring because this comes up pretty often.

It’s this topic that perennially has sat on my mind, which is: how do I know when I should hire? And this came up for me recently. I was talking to a client and they were saying, “this is our plan, this is what we’re going to do, and we just need to hire.” And there was something about that that just sat wrong for me.

It sounded like the default assumption is, if you want to do something, you hire people. If you want to do a new project, you hire people. I don’t think it always happens. We all know that we move around and on projects, and we might get a new thing added that our team is responsible for.

But then that actually just adds even more to the mystery of this question of, when should I hire? You’re a new manager and you’re feeling your team is a little stretched, should you hire? You’ve got a few teams on your remit and you’re looking at them all and you think, there’s this new strategy that the company is asking for, should you hire? And I think that’s really what we’re going to be talking about today, Mon-Chaio. Is that on your mind?

Mon-Chaio: It absolutely is. Hiring is often also a source of contention between management and teams. A team is often working and executing well, and they have their plan in front of them. And down from up top, leadership says, by the way, could we do this project also? It’s really important that we end up doing this.

Andy: And you ask can we stop doing this other thing? And the answer is no.

Mon-Chaio: Of course not. Just let me know what it would take for you to do this project. Also, it’s really important. We have to get it out by next quarter. Often teams come back with well, okay, so that project costs four engineers worth of time. I guess that means I need four more engineers. Of course, from the leadership side, they often think you already have 12 engineers. Why can’t you just absorb this? Why is it that every time I want to do something and I want to push the boundaries, you always tell me you have to hire. That’s your default answer. I have to hire. I have to hire. So there’s this contention between these two groups.

I don’t think it’s healthy and I think it would be excellent if we could come up with some tactics for both of these groups to help them understand the problem better and perhaps have the same language and the same model to think about when is it that you should hire and perhaps when is it that you shouldn’t?

So I think that’s what’s on my mind.

Andy: All right. I think we’re aligned. So I was going to say from that, one of those, one of the things you just described there, that disconnect in what people are thinking, that I want you to do this project. Okay, I need four more people. Why are you always asking for more people? Shows right there that there’s a confusion and no shared understanding about when you should hire and why you need to hire.

If they’re saying, here’s a new project and you’re thinking, then that’s more work, that means more people. Then your mindset if you’re the tech lead or technical leader, your mindset is probably along the lines of work equals people. If we get more work, we need more people. Whereas maybe the person asking for it, they’re not making that same connection, that work equals more people. And why is that, Mon-Chaio? What is it that might be going through their mind to not fit that mode of thinking? What’s a a way of breaking out into that mold and thinking of it in a different way?

Mon-Chaio: That’s a really good question Andy. I wonder if it’s because the abstraction levels are different and perhaps both abstraction levels are not quite correct. From a senior leadership perspective, I feel like maybe they often think about organizations as cost centers or budget centers.

Their orgs can be big enough that they don’t even know the number of people in it. They just know, oh, it’s approximately maybe a hundred people and I pay them X amount of money a year. And so for them, it’s very likely in my mind that they’re thinking for a cost center that costs this much, I should be able to get X out of it. And I’m just asking for this additional thing. And so just tell me, it’s like a black box system, right? I should be able to put inputs into it and you can churn however you do and churn outputs out of it.

Oftentimes they even see that teams have been able to do this before in emergency type situations where, oh, I have an outage, you somehow absorb that. So that must mean you have some way of absorbing work. Sometimes teams will talk about slack and they will say well, can’t you just utilize slack time? Sometimes teams have other activities, retrospectives, learning activities. And so for them, they see it more, I think on a team basis, which is right, I think, but there’s some wrong aspects of that.

Moving back down to the teams, oftentimes at that level, you see it as individuals. And so instead of thinking about what is my team and how can I achieve what I want to do, you start to think about, Joe over here can do X and Y and Jane over here can do A and B. And so now if I have C, that means I need new employee, Phil. And this actually shows up in the way that people estimate. It shows up in the way that people do backlog planning and everything, right? Everything is a card, is assigned to a person. And each person can have so many hours of work. And if I add them all together, I get my team. And so, from the planning on the lower levels, it’s so individual based that of course if new work comes in, Joe already has his slots and Jane already has her slots. So I need a fill.

So I think perhaps that’s the reason why there’s this disconnect because the model, the thinking model is different between those two groups. Does that resonate with you?

Andy: I think so. And it also just brings back my flashes of anger at Atlassian, that they still haven’t allowed me to assign two people to a card in Jira. Pair programming is a thing.

So Mon-Chaio, there’s something that you said in there that I think might also fit into this, which is that the person asking for this extra thing to be done, who’s saying I don’t really want to hire. I think probably they’re also thinking about it, and you touched on this, from more of a return on investment type perspective. I’m already investing this much into progressing our system, our application for what the company wants to do. And yes, we want this thing, but we don’t really want to invest more. And basically investment in this sense is usually down to people’s salaries. It’s, in some way they’re saying, I don’t want to pay more for what we’re getting right now. And so when they hear we need to hire more, it doesn’t quite land because in some way they’re saying, but I don’t want to pay more and now you’re telling me that the only way to do this is to pay more.

So I think right there it starts getting to a bit of the answer of when should you try to hire? There’s one very clear thing. If you’re willing to pay for more salaries. That’s one clear indication that you might be in a situation where hiring is going to be okay.

Mon-Chaio: That doesn’t tell you whether it’s objectively correct to hire, if there is such a thing as objectively correct in any sort of management.

Andy: Yeah, because you may have the money, but it might not be a smart idea to spend it on people right now.

Mon-Chaio: Right, absolutely. It certainly is a signal that perhaps you can hire. And I think oftentimes, senior leadership does have in the back of their mind that probably they will get an ask to hire more people. Just because of history, that’s always been the response.

Andy: The engineering teams have trained them to know that it’s coming.

Mon-Chaio: That’s right. And if you’ve ever been in any of these planning meetings, and I’m sure you have, I’ve certainly seen it at many different companies both through working there and consulting, then you start to have this conversation where it’s okay, okay, I have this thing, engineering team is going to say to hire, I’m going to try to get them down to three people.

Andy: It’s a horse trading game now.

Mon-Chaio: Absolutely. I hate that word horse trading. I think it is one of the worst practices in software development and it is still so prevalent. In fact, I know somebody who I respect quite a bit, not in the leadership side, but in other aspects, who really believes in horse trading as a central part of managing software projects.

That’s a discussion for a different day.

But often, leadership, in their minds, they’re thinking about money. And so they say I’m willing to maybe spend this much extra. And so there’s three people I’d rather not, but maybe I can swing it. And my engineering team is asking for five people and I want three. So then what happens in that case, then you start breaking down why is it five people? And all of a sudden you start to dig down into well, I need to build these x systems and this requires this much time and this many people.

Which I think is also irresponsible, especially if you subscribe in any way to sort of agile philosophies. Now our hiring plan, which we’ll talk about later is more of a long term thing, is being bound by these architectural short-term decisions before we even know what the system is going to look like, right? We’re saying, oh, I need to build three platforms and it’s going to have to have two data stores. I need one data store team, which is two people. And then I need a gateway team, which is three people. So that’s five people. How do you even know you need that?

Andy: Yeah. And then what happens when you’ve built that data store? Are they gone? We’re getting to a very weak foundation for deciding that you want to employ someone long term.

Mon-Chaio: And I think this discussion is going to move that way. It will definitely come back to hiring, but I think we do have to, at some point, talk about this concept of employment in general, employing someone long term. How we think about employing people and how we think about employing teams. I do think we should probably dig in that a little bit to have a strong thesis on then should we hire for a specific situation and how do we know.

Andy: Yeah. So, I think it brings up a few things, is that in that analysis of why do you want another person, as you said, you’re probably thinking about we’re gonna need to build this and we’re gonna need to build that. That immediately brings up the question of do you need an employee or do you need a contractor, or do you need a consultant?

Each one of these has a different purpose to bring into the organization. And if what you’re saying is, look, there’s a very short term thing that we need to get done. Once that’s done, we move on and we don’t need those extra people. That’s sounding like something where you want to bring in contractors. And that might be a better discussion to have.

If you’re thinking like, this is just a short term, we need some people with some expertise in this field, in this area, building these kinds of systems. We are a web app system and what we’re getting now is to build a mobile app. Okay. You have a choice. You can say you’re going to now build out a mobile app development team or add that capability into your existing team, or you’re going to hire an agency and say, you know what, let’s build an app and we’ll take over small amounts of maintenance, little bit that we can learn. Because we’ll build it, it’ll sit there. Maybe you’ll design it in a way where the web app team can even do some of the updates, you’re not going for a full native just because it doesn’t fit your strategy. Key word here. We’re going to get back to strategy.

Mon-Chaio: Foreshadowing, yes.

Andy: And you decide, just contract it out. I think sometimes we forget about this within software development teams.

We forget that there are other disciplines and other approaches to the work than full time employees that will actually fit the situation really well sometimes. Bringing in contractors for those kinds of short term jobs or for something completely different is completely different from hiring someone.

Bringing a consultant, if what you’re looking for is someone who’s done it before and you just need advice. You need someone to be able to walk the path with you and show you what you don’t know. If that’s the whole thinking behind the hiring, it’s like we’ve never done AWS before. Okay, let’s get a consultant to tell us about AWS, walk us through it. Maybe do a little contract type work with it to get us onto it. And then the team does it. We don’t need to hire to do it.

Mon-Chaio: Let’s explore this a little bit more Andy. I’m gonna try to play devil’s advocate here.

As a senior leader, I might say, that’s fine and great. I understand that I can hire a consultant or I can hire a contractor. But I can also just hire an employee. And hiring employees is what I do. And you haven’t told me why I should consider not hiring an employee and hiring a contractor instead. Often times, they’re more expensive. They’re not part of my team, is there a problem with just hiring employees? Why should I hire a contractor or consultant instead? What are the benefits that I get? Or the disservice, perhaps, to do a little foreshadowing, of just hiring an employee?

Andy: Mon-Chaio very kindly just gave me the cue for the kind of answer he’s asking for there. The disservice.

So I think one of the benefits is that you’ll be bringing in someone who has a very different mentality of how they’re approaching this work. A contractor or a consultant is going to come in and they have a job to do. They have a very specific thing. Now, this can be great. It can also be very annoying. I understand that. I’ve worked with contractors that act this way, and it can get very annoying. But they’re there to solve the problem that you’ve brought them in for. If you bring them in for a particular problem, assuming they’re a good contractor, they will just get it done.

Now, they’ll also take your direction. Hopefully very well as well. They’ll say you want to get it done in this way inside your systems. Cool. Now, if they’re really experienced contractors, they’ll give you a bit more of advice along the way. Maybe they know how to create the build systems a little bit better than the way you’ve got them set up and they can, and that’s a great thing. It’s like bringing the outside in, bringing in that external knowledge for a short term. But they’re really there to complete the project that you’ve brought them in for. And so that’s the mindset they’re going to have. That’s a double-edged sword. It’s great. It will be there. It’ll get done. They’ll move on. It can also be bad. They’ll complete it and move on. And now you’ve got it. But it’s a very real thing.

Now, an employee, in my mind, maybe this is old fashioned, but in my mind, an employee, you’re setting up a long term relationship. You are bringing them in and letting them be part of your organization and setting up all of those dynamics with the team and the team will reshape around them. The whole organization possibly will reshape around them depending on the impact level of the individual that you’re dealing with. And so if you bring them in and it turns out that the only thing that actually fit what they are and what they want to do is that one project. And then that project finishes and they look around and they’re like well, this is not at all the company I wanted to be in, you’ve moved someone who wanted to be an employee and have that kind of relationship and security to possibly have to think a little bit more like a contractor, where that relationship is fleeting and transactional because, well, what they thought they were there for doesn’t exist anymore and now maybe they need to go look somewhere else.

Or maybe you just lay them off because you didn’t think that through. Which is also a terrible outcome.

Mon-Chaio: You’re right, Andy, and you said it was perhaps an old fashioned way of thinking. If it is, I am going to subscribe to this fact that I tend to be old fashioned too. I really do think organizations have a responsibility to their employees that oftentimes they don’t take seriously enough.

Let’s use this hiring topic as an example. I often tell organizations, and perhaps this is the next portion of the topic we can get into, that hiring … it’s a long-term activity, it’s not a short-term activity. To put it another way, you don’t hire because you need to get a project done. You hire to make sure your organization is right-shaped and right-sized for the future. Maybe that’s a year, maybe that’s three years, whatever the horizon that you’re looking out for is. And some of the pushback I get from that is we don’t know what that looks like. I can’t say that this team needs to be seven people or fourteen people in two years, because I don’t know what’s happening in two years. So how could you possibly expect me to say my hiring plan is to double the size of this team in two years, and that’s how I hire without thinking about every specific project that they’re working on.

I think it’s really interesting that a lot of organizations are willing to stand on that platform, or stand on that pulpit, and make that argument, while, to use the example you gave earlier, they’re very willing to hire two people in to write a data store, and then abstract away what’s going to happen with those two people after the data store is built. “Obviously there’ll have to be some maintenance, and you know we’re growing. There’s absolutely always going to be some room for these people and things to do.”

Without really considering what is it that these people want to do. And so, you are absolutely projecting one way or the other. I feel like for many organizations, it feels more comfortable to project one way …

Andy: Mmm.

Mon-Chaio: … in the way that’s less responsible to the employee than to project the other way in the way that’s more responsible to the employee.

Andy: Absolutely Mon-Chaio. And I think there’s a key point in what you just said as well, which is that long term has two meanings. Long term is both, it takes a long time, often, to hire people, it’s a long term plan to grow that team and bring people in, but it’s also a long-term commitment, ideally, is what we’re looking for, is we don’t want to bring those people in one year and then they’re gone in six months.

We want them to be around for years. We want them to be understanding our systems, our customers, our domain better and better, and becoming part of that group. Because, as we’ve talked about in other episodes, that builds that trust, that builds that ability to do so much more and really create effective teams.

And so the question I think becomes, to the point of we don’t know what’s going to be here in two years, you need to. You need to just for that hiring. If hiring is going to take two years, you already have to have an idea of what you’re going to be doing for two years.

But ideally, you’re basing where you’re going to be in a few years off of an overall strategy of what you’re trying to do as an organization, where you’re positioning yourself in the market, how you treat your customers. That’s all strategy, whether or not you’re high touch or low touch. Are you doing an online app? Are you doing a software as a service? Are you doing something where really the software developers are writing more of internal tools. That’s all your strategy about how things play out. And your strategy will also encompass things about, like, how are you going to grow your market? Are you going to enter this region and then that region? Are you going to go after this kind of customer, then that kind of customer? All of that should have, at least a little bit of thinking around it and that starts giving that framework on which you can start building up, okay, this is when we’re going to need a bigger team when we’re going to need more people. Not when you decide, oh, because we learned that Postgres didn’t scale in the way that we wanted, we’re going to create our own data store, and that is a short term thing that you finish it, you fix it, and you’re done. That’s not a strategic thing. I hope not. Most of us are not in the realm of our data store as a strategic investment. But it’s not a strategic thing that defines what your team structures really need to be over the long term.

And so Mon-Chaio, what is this strategy? What does a strategy look like that could inform hiring? And if I’m that person who’s normally the one saying, yeah, you’re asking for that, I need to hire four more people, what’s in this strategy that I should be looking for that would help me see that’s maybe a reasonable request or not.

Mon-Chaio: This is sort of a big topic, isn’t it Andy? Because strategy isn’t just about hiring. As you mentioned, it’s about all parts of the business. I would hope that even if you are not having this question around hiring, that you have a clear and well-defined strategy for your business because it’s needed for alignment, it’s needed for morale, it’s needed for a ton of other stuff that we won’t have time to get into here. So let’s just take it a priori and say strategy is important.

But we do need to talk about a little bit what is it so that we can talk about how does hiring fit into it. Strategy to me needs to clarify the intent behind any actions taken, which of course includes hiring. Hiring is an action that you take. So I think that’s one aspect of a good strategy. You need to be able to look at it to determine actions. One of my managers at Metta actually used to say something that I now steal because I really like it. He used to say strategy is how you snap back to good. Anytime you feel like you’re off track, strategy will be your guiding beacon where you can look to it and say I have plan A and I have plan B. Which one should I pick? And it’s whichever one snaps closest to your strategy.

Andy: I think that one makes a lot of sense. Cause we often have these questions, like when we’re designing something or when we’re putting together the architecture, you have this question of should we make it for this or should we make it for that? Should we make it for this other thing? Which one is correct, is very context dependent, and the strategy of your company, what it is you’re trying to achieve, provides that context, which defines for you, which one of those is good. And so for hiring, likewise, hiring will give you an idea about what is good hiring. Should you be heavy in one kind of discipline or another?

Maybe your strategy involves almost nothing about sleek UI. We don’t need a sleek UI, that’s not our strategy. Our strategy is getting it so that the decision makers want to buy our product, and it’s good enough for the back office people and corporations to use. It’s not sleek, maybe, but it catches errors.

And so you’re going to have very different hiring goals in that. You’re not going to be hiring graphic designers who do very fancy, sleek looking UIs. You’re going to be hiring people that are maybe very much into testing and how do you cause the system to do the wrong thing. And so it will determine quite a bit about what kinds of roles do you actually need to hire.

Mon-Chaio: I liked a lot of things about your example. One thing that I think is super important to point out is the strategy that you mentioned is more abstract, right? It’s about the why and not about the what. You didn’t say that our strategy is to not build a React Native UI, and you didn’t say your strategy is to build three pipelines that are going to process this kind of data, right? It was more around how do we deliver value? And I think that’s really important because the more specific your strategy is, the less it’s used as a beacon and the more it’s used as lanes on a road or guardrails on a very narrow road.

If there’s only one way to execute your strategy, then that’s not really a strategy. That’s just a plan I suppose is what I would call it.

Andy: And as it hits the reality, people’s actions won’t align to it because they probably can’t. Very quickly, just through the nature of people no longer paying attention to it, the strategy becomes meaningless. Yeah, your strategy needs to be a bit broader. It has to allow for different approaches.

And so, in those approaches, though, it will also tell you what’s an approach that’s not allowed. For instance, on my example of, it won’t be a sleek UI, you might say and we’re not going to try to garner the Instagram likes for our UI. It’s just not interesting to us, we’re not that kind of business, it’s not the kind of thing we’re going to try to do.

Another example about how you might see that strategy defines who you want to hire or the shape of the organization, is your strategy may be that you are going to deploy new versions of this software on a regular basis, and you’re going to customize it for your individual customers.

So you’ve got two parts there. One, you’re going to deploy on a regular basis. So let’s say we’re going to deploy new updates to please these backend users at least once a month. All right, that’s now put constraints on the way that you can operate. That means that you need to have that kind of ability to iterate, at least within a one month cycle. I would say, ideally, even faster, because if you can only iterate once in the month, you’re going to start struggling. But it starts setting constraints about how you’re going to have to operate internally, and what kind of tactics you’re going to need, what kind of practices the people you’re going to hire need, and what structure your organization needs to have.

Because if you’re on a cycle like that, you probably need much more cross-functional teams. You can’t create a structure where the requirements gathering happens in one group, and then they hand it over to someone who does an architecture, and then they hand it over to someone else. Your strategy will define that is an unworkable structure. You need to reduce the handovers. Now, you might think, but that’s the way you should always organize a tech team. But that’s not necessarily true. You may work in a very compliance driven environment where some of this documentation and handovers is so important that you have to have it. And so you’re going to need to set up an organization that creates those things. And you’re going to need to structure your organization to make sure that you create those things. I can say I do not like working in those kinds of organizations. But that means I wouldn’t be a good hire for that kind of an organization.

So, the strategy and what you’re going to go for kind of starts playing into the structure your organization can have. Not only the departments, but also the specialties you’re going to hire. And then if you take the other part of what I said, you want to be delighting your customers. That means that you’re also going to need to set up an organization that gets customer feedback. And you want to do this through a very hands on process, for instance. That means you’re going to need someone in more of a customer success type role or a customer support type role. In that, you now have the idea of how many people do they support? How many customers do they support? And that starts setting up a bit of the economics of how you’re going to work.

I also said you’re gonna customize for them. It may be that you’re almost doing more of like custom software, in which case you grow with your customer base. Your headcount almost invariably has to end up growing with your customer base because they put demands on you. That becomes a strategy defining when you’ll hire. If you’re getting a few new customers, you’re going to hire a few new people because that’s just what you do. That’s part of the service you’re selling. Now, a lot of us probably work in companies that are like more software as a service. Their explicit strategy is that their customer base grows without growing their headcount. That’s what they want to do. That’s what a SaaS company is trying to do.

Mon-Chaio: Mmm hmm.

Andy: And so, if the customer base grows and that’s used as a reason to hire more people, well, that would be a reason that is counter to the strategy that the company is trying to run.

Mon-Chaio: I like both of those examples. I’m glad that you both touched on one where your strategy very clearly connects to hiring. And then you started going into the SaaS model, Andy, where you said well, it’s less tied, right? It’s less dependent, it’s more fluid. I think even in that model, you can start to tie your strategy and hiring by thinking about the business outcomes that you want to achieve over the next … whatever your time frame is.

So if your business outcome for the next year is you want to achieve X, Y, or Z. And then the business outcome over the next two years is you want to achieve A, B, and C. Well, those start to look a lot like KPIs or OKRs, right? What are the metrics we’re going to use to judge success? And we’ve talked a lot about building teams on top of those types of OKRs.

And if you think about building teams on top of those, then all of a sudden you can have that discussion. In order to have a team that’s able to do this, in order to have a team that’s able to support 100 million video calling users, in order to have a team that supports 20 percent year over year growth in Asia, how many people do I need? Of course, you’re going to be doing projection, that’s the whole point of this stuff. But it is really important to be able to right size your teams in that way because going back to the hiring aspect, a. it’s going to take a long time to hire those people.

For our listeners, how many of y’all have ever gone into roadmap planning and said, hey, we want to ship a project in the next quarter that requires four people And bang, those four people appeared the next week and you were off and running. Versus how many of you have ever done that and then at the end of the quarter you ship the product but you’ve only hired two people. Because it takes so long, right?

So one, the long term part of hiring, as Andy had mentioned earlier, means that you have to plan ahead. But second, to that responsibility of the individual, to say to a person, look, you’re coming in and your team’s mission is to grow Asia 20 percent over the next two years. That is a long term thing where a lot of different things can change within the company, but for that person wanting to make a long term commitment to the company, they can look at that and say, yes, I see that that’s possible or fun, and I’m willing to join that mission. Versus, hey, by the way, we’re hiring you ’cause we need you to build a data store. And by the way, there’s lots of other interesting work. Look at all these things that we’re doing in the future. So, much more mission driven and tied to strategy than project driven and tied to the next thing that you have to ship.

Andy: So Mon-Chaio, I think we’ve banged on the drum of “tie things to strategy”. And one of our listeners tries to do it. They say, I think this is tied to the strategy. I think we should do it. And after maybe a very informative discussion, they realize it’s not really all that tied to the strategy. And there’s no willingness to spend more headcount. So what kind of options do they have available to them now?

Mon-Chaio: I think you mentioned a great option, Andy, and I am going to say that this still ties back to strategy, which is to take a look at your strategy and say, what is it that we’re not doing? And then bring that back down to see, well are you really doing anything, even, I don’t want to say in secret, but sometimes there’s this dark work, or there’s this work that’s accumulated over time, or there’s work that, because you’ve been doing it operationally, just sorta grows without anybody kind of looking into it, right?

Things like, “oh, well, I know we said we weren’t going to help customers debug, but there’s this really important customer that we said we’d make a one off exception for. And now they’re taking a lot of time. So let’s just build a quick little tool that we can use to help them debug. Oh well, this tool has bugs. So let’s like productionize it, make it a web UI, because …”

You know, that sort of thing that then starts to conflict with your strategy.

Andy: That sounds ,operationally, like a very good idea.

Mon-Chaio: Absolutely.

Andy: We need to do this because this other thing keeps happening and we just want to, we want to make that more efficient. These customers are coming in, sales keeps pulling us in to talk to them about this stuff.

I would say, if those are not aligned with the strategy, you make that very clear. And unless it’s going to destroy the business, you stop doing it. And you say that that’s what you’re going to do because that’s not the strategy of the company. And that’s the trade off.

Mon-Chaio: And I don’t think that’s a bad thing at all.

Andy: No! In fact it’s the whole point of having that strategy.

Mon-Chaio: Right. Even for the most successful organizations, even if you were seeing yourself as a model organization, you said, hey, I actually do everything that Andy and Mon-Chaio talk about on their podcasts because our tactics build the model organization.

Right, Andy?

Andy: Oh, they do. If anyone does something different from what we’re saying, I think they’re wrong.

Mon-Chaio: Absolutely. They are just wrong. And they can come to our conference talk and we’ll tell them how wrong they are.

But even for the most successful organizations, it’s actually a good thing that this operational aspect creeps up and creeps up and starts to try to make you more effective and efficient at the day to day work that you do, right? I think the challenge though is most organizations don’t take a good hard look at that regularly and snap it back to strategy. And I think that’s the piece that’s missing. And I think if more organizations were to do that, they would find that there’s many things that they could do to refocus. Getting back to hiring, they don’t have to hire. They could refocus and say, look, actually given our strategy and now that we’ve taken a closer look at it, there are these things that we could deprioritize.

Andy: Yeah. And I want to clarify that when I said, oh, you just stopped doing it, that was a bit extreme. What you should do is start working out how do you wind it down? Some things you can just cut. Other things you do need to wind down. Like that engagement with the user where you were saying you need to debug. You start extracting yourself from that situation. You start pushing back on them and at the negotiations about it, you just start saying, look, this is far beyond we ever expected to take it, and you start pulling it back. But with the engagement of the more senior leadership, the ones that were part of that discussion about why are we doing this, and getting that clarity, that alignment on we’re doing it because it’s not part of our strategy.

And I also want to add one thing to not take away from this is that you should not stop investing in operational efficiency, getting rid of the friction that slows you down. No, absolutely. In fact, you want to be very targeted in that, because quite often, when you get those requests, and you’re like well, we need to hire, because we have to keep doing all this other stuff, investing in efficiency that lets you stop working on the stuff that isn’t all that strategic, and to work on the stuff that is, is really beneficial. You don’t want to get stuck in this pattern of business as usual and just letting the friction build up. And so you want to find ways of moving that away.

And there is actually a reason why someone may say, we’re not going to hire. Because they want to create that back pressure for the teams to do that. Because if you just keep hiring, if the answer is, we have all this extra stuff, now we need to hire, there’s no back pressure to say, actually improve the efficiency of all those other things. Get it so we don’t have to spend so much time on those things and move us along.

So one of the ways of doing this is to actually just constantly put a little bit of investment, a little bit of effort into improving those systems, so that you’re not constantly pulled off onto we need to restart this server every four days, and it takes three hours to recover properly once we’ve done it. No, no. Even if it takes a few days or weeks of some engineer to fix that, you’re probably better off fixing it than saying hiring another person, because there is a cost that we never talked about, but I’m pretty sure all of our listeners know: growing the team makes everything harder.

One last thing that I think we haven’t brought up yet, which is when you do have to talk to a group about the stop working on something, that can bring up a lot of negative emotions, a lot of morale problems. And a lot of pushback, because they’ll see it as very important. I hope they see it as very important, because they’ve been working on it. Maybe they’ll be relieved. Who knows? Some teams are relieved when you tell them, please stop working on that. They’re like, Oh, really? Oh, thank God. Okay. We finally have allowance to stop doing this thing. But sometimes they’ll have invested themselves into it. They might even see it as part of their identity.

And there you’ll have to have that conversation about, why do we not want to do that anymore? A company I worked at, the application I had worked on, they moved everyone off of. Because strategically, it didn’t make sense for the company to put effort into it. And so, they came up with a plan to document things, to fix up some of those operational issues that had to be worked on all the time, and get it to the point where they could just walk away.

And for some people, that was probably hard because it was a project that they had worked on. It was a program that they had worked on and it was their team for years by that point, but it was the right choice because there was no growth in that. I don’t think we’d made a sale of it for several years. And it could sit with its few small customers, just bringing in a couple hundred thousand pounds every year with absolutely no effort. In fact, it got to the point where we actually had a little bit of a problem. A lot of us forgot how it worked. And so when a problem did happen, we had to sit there and go like, wait, how does this thing work again?

Mon-Chaio: Wouldn’t we all like to have a system in our back pocket that brought us in a couple hundred thousand pounds a year and we wouldn’t have to do anything …

Andy: Yeah. Yeah. But the thing about that is to talk about that emotional reaction and to talk about, you might even need to name it, the sunk cost fallacy. The idea that you don’t need to just keep investing into it to hope that it will be better later, but you should really think about it and say, is this really what we need, tying it back to the strategy or is it not? And if it’s not, we should be ready to just let it go.

Mon-Chaio: And Andy, it’s actually a two way street here. We’ve talked a lot about the team itself having an identity. Perhaps their team name was Product X.

Andy: Yep. It was. We even had a mascot. It was the Hiphopopotamus

Mon-Chaio: Oh my goodness, now we’re dating ourselves, right?

So we’ve talked a lot about the team having these emotional reactions to what’s been before and their identity and having to change it. The other way works as well. Oftentimes, you will find that companies and leaders become attached to initiatives. Maybe they came up with them or maybe it’s just one of those things where It’s just the way things are being done.

I’ll give you an example. How many times have you ever talked to leader and said, you know what nobody’s using this feature, we should just remove it, and how many times have people gotten the response, oh, we can’t remove a feature, right? There’s that emotional reaction of, we’re actually subtracting from the software. And so it works that other way too, where the teams can convince leaders, let’s look at our strategy and this thing doesn’t fit.

And for those leaders, they have to understand that sunk cost fallacy as well. Just because I’ve dedicated three million dollars into it over the last three years, doesn’t mean that I should continue to dedicate 15 dollars a month into it now. Because where we all started was, do we have to hire and how do we know when we have to hire? If we don’t do that, we can bring one engineer, half an engineer, quarter engineer back. Wrong way to think about it, we don’t like to think about engineers that way, but to use that vernacular, and then we could work on something else and that prevents us from having to hire.

So don’t forget that the path goes both ways and it’s not just the top down thing. It could also very much be a bottoms up push to re-examine your strategy, think about, no, we not going to do this, we’re going to refocus and that way achieve more without having to hire.

Andy: And that is a very valuable thing to do during the quarterly or yearly or bi-annually strategic review where you start planning out what is this group gonna be doing? You can re-examine what are you doing, what is on that development plan, can you tie it back to this helps us on our strategy?

And if there’s activities that you’re doing, there are things that you’ve taken on that you’re like, this doesn’t seem to fit anywhere. And it’s taking our time, it’s taking our attention. Sometimes things don’t take much time, but they take a lot of attention.

Mon-Chaio: Mmm hmm.

Andy: You can bring that back up and say, hey, look, there’s these things. We propose to sunset them over this time span with this effort. Because they’re unconnected from what we’re trying to do and they become just a distraction for us. That’s kind of where you can bring that in and say, look, we don’t have to be doing everything.

I wanted to bring in a really quick anecdote here, Mon-Chaio, something you might remember from a time that we worked together. And it’s about talking about things a little differently. Do you remember that at one point we wanted to delete some functionality from a site that we worked on and we were told, okay, you can get rid of it, but don’t get rid of the code. We might want that again in the future. Because we used the word delete the code and delete the feature. And we were told no, no, no, don’t get rid of it, we might want to use that again.

Mon-Chaio: Mmm hmm.

Andy: And we went back to our desks and we were like, what the, what? We want to keep it around? We don’t want to keep this in our code base. We’ll have to keep changing and then we’ll just break and we won’t realize it. And it’s just pointless. And we’ll keep changing it for reasons that don’t matter. And then it dawned on us. It’s like, well, it’s going to be in source control. At the time I think it was still CVS. We might’ve moved on to Subversion by that point, but we came up with the idea: let’s call it “archive”. We’re going to archive this feature. And suddenly the CEO was happy. He’s like, okay, if you’re archiving it, that’s fine.

Mon-Chaio: Mmm hmm. Yeah, those lessons that we learned from back in the day. Now, I absolutely do remember that. And yes, the words you use matter, and we touched off this small section talking about the emotions. And we have get past that, not get past that, but we have to clearly communicate it, bring to the surface, understand that not everything is going to be this logical reaction, that there’s going be emotional play into this, and being willing to examine that. And use that to move forward on the best possible way to move our business forward.

Andy: Mmm hmm.

Mon-Chaio: Which is, at the end of the day, what we alll want.

Andy: Yeah. All right, Mon-Chaio, I think we’re at a point where we’ve flogged this hiring beast to death, to go back to the horse trading analogy.

Mon-Chaio: Oh, Andy, that’s not true. We have so much more we can talk about for hiring, but in order to usher our listeners along to the rest of their day, I think this is a really good place to stop. I think we’ve examined the issue. I think we’ve presented a few great tactics, and hopefully everybody agrees.

Andy: If not, we’re still waiting to hear for feedback on these episodes, and we would love to hear their disagreement.

Mon-Chaio: Yeah, absolutely. And if you do have disagreements or any feedback, this is not the first time we’ll tell you this, give us feedback. But for the first time, we’re going give you an explicit way to do it. You can email us at hosts@thettlpodcast.com and we will probably read your email, I would say we will definitely read your email, so please, send us feedback, send us comments, hosts@thettlpodcast.com. Also like, subscribe on your favorite podcast platform, the listeners are the lifeblood of any podcast. We’ve had a great time talking through these topics and we hope you’ve enjoyed them too.

Andy: All right. Till next time, be kind and stay curious.