S2E26 – Out of the wartime crisis trap

Show Notes

 In this episode of the Tactics for Tech Leadership podcast, hosts Andy and Mon-chaio explore where leaders should spend their time, touching on the importance of signaling dedication, performance, identity, and power through time management. They discuss the contrast between crisis, wartime leadership, and peacetime stability, emphasizing the Eisenhower Matrix as a tool to prioritize urgent and important tasks. The hosts share insights from their experiences, including how leaders often misidentify crises and the impact of time use on organizational culture. Listeners will also learn about the surprising benefits of sometimes letting things fail to improve overall system resilience.

References

  • Eisenhower Matrix – https://www.mindtools.com/al1e0k5/eisenhowers-urgentimportant-principle
  • Signs of Our Time: Time-Use as Dedication, Performance, Identity, and Power in Contemporary Workplaces – https://doi.org/10.5465/annals.2018.0148
  • Peacetime CEO/Wartime CEO – https://a16z.com/peacetime-ceo-wartime-ceo/

Transcript

Andy: All right. We’re back with another Tactics for Tech Leadership podcast. Are you ready Mon Chaio?

Mon-Chaio: I am ready. Good to see you back in your normal digs. How was your trip to Ireland?

Andy: My trip to Ireland was amazing. I didn’t know how nice the West coast of Ireland is. I did learn, however, that there are midges in Ireland. I thought they were entirely a Scottish thing. And Mon Chaio, you’re looking at me like, what the, what is a midge? A midge is a little, tiny, itty bitty, biting insect. They are so small that the netting on a standard tent that keeps out mosquitoes does not keep midges out. They will crawl right through it.

Mon-Chaio: Did you find that out or did you learn that?

Andy: I knew this from my wife going camping in Scotland and her calling me up frantic saying, they’re coming through the tent wall, they’re coming through the tent wall. But the topic for today, let’s go onto that. Let’s move back to tactics for tech leadership.

The topic for today is going to be where leaders should be spending their time. And Mon Chaio, as we were just talking about this to get ready, we were like, man, that is a broad topic. What do we do with this?

Mon-Chaio: Yeah, it really is a broad topic. And we also thought we would find a lot of research around it. It feels like a fertile area for researchers to dig into. Are leaders spending their times in the right areas? Are they segmenting their times correctly? Are most leaders spending their times on, spending their time on areas that aren’t going to make impact?

But strangely, Andy, there wasn’t a lot of research to pull from here. Was there?

Andy: No, the thing that I did come up with was where do developers spend their time, but not where their managers spend their time or where leaders spend their time. I’ve, I’ve searched for where to CTOs spend their time and I found very little.

Mon-Chaio: Well, and I think part of that might be because I don’t even know if this is true. You know what? I don’t even know this is true. I was going to say that’s because leadership, the work of leadership is much more nuanced and much less predictable than the work of engineers. But I actually, speaking that out loud now, I think that’s false.

Andy: Yeah. Yeah. In fact, the little bit of information I did find about where to leaders spend their time. The models that they had, or maybe this is the explanation, the models they had about where leaders spend their time were much less nuanced than where developers spend their time. So the developer time breakdowns I found, they had all sorts of things in there.

They’re like, oh, they’re seeking information. They are writing code. They are debugging. They are, collaborating. They’re designing. They had all sorts of these breakdowns about where are developers spending their time. And then I get into where do managers spend their time? And here’s one that I have that actually was drawing from a fair amount of research, but it was, it was managers from all over the place, not just tech.

And basically this meta analysis split it into where do they spend their time on desk work or meetings or phone calls. That was

Mon-Chaio: Wow, absolutely.

Andy: covers it.

Mon-Chaio: Well, and it sounds like what you found for developers might even overlay a little bit about how managers spend their time or how leaders spend their time. Information seeking. We talk a lot about understanding the system or sensing the system. So there might be some parallels there, but maybe Andy, we should move into why is it even important for us to talk about this?

To Stress test with ourselves and hopefully for our listeners. Should they even keep listening? Is this an important topic? Why are we going to spend 40 some odd minutes discussing this topic?

Andy: Yeah, why, why should it matter that we even discuss where you should, where you are spending your time or where you should be spending your time? I’m going to bring up one thing that I think we both love talking about, which is, I think it’s important, for one, because it sets up your culture. Where you spend your time indicates to other people what you consider valuable and what they should consider valuable.

Mon-Chaio: I like that. And honestly, Andy, I hadn’t really thought about that before you mentioned it. And for me, I think this is important because one, in my experience, I have seen leaders mostly spend their time in the wrong areas, at least to me, in my estimation.

Andy: And what’s the impact of them spending their time in the wrong area?

Mon-Chaio: Time is finite..

By spending your time in the wrong area, at best, you’re having a null impact on the wrong area, or maybe a slight positive impact on the wrong area. But zero value in the right areas. At worst, you having a negative impact in the wrong areas and a null impact in the right areas, which makes your contribution worse than nothing.

Right? It makes your contribution actively negative.

But is that just me, Andy? Or like in your experience, when you have viewed your leaders or leaders in general through your tech due diligences or your consulting, have you also felt that perhaps they’re spending their time in the wrong areas or not?

Andy: Yes. Yes. Yes, they are spending their time in the wrong area. And I’ll, I’ll bring up an example, actually. So there’s an engineering manager who I’d been coaching. And he was fairly new to the job. And he was asking me where should he be spending his time.

And I was trying to figure out where he was spending his time. And the place that he was spending his time primarily was on individual tasks. He was acting as the go between. in a lot of cases, between product management and the development teams, taking these tasks and making sure that the tasks were ready for the teams to see them.

And I said, this isn’t all that valuable for you to be spending your time on.

Andy: Now, in my head, I have a very simple model of what he should be spending his time on, which is paying attention to the system, and, and seeing the whole interplay of what’s going on, and then spending a lot of time talking to people to work out how they can change what’s in their head to change what that system is, because so much of software development, the actual system, is what people have in their heads of what’s going on.

But by spending his time in the wrong places, It had a lot of impacts on the team. One of them was that it kind of, de skilled the team.

They no longer could take ownership in Mon Chaio and your kind of triple A stuff. They no longer really had autonomy over a goal. They, they were given individual tasks because of this structure of where he was spending his time. .

Mon-Chaio: I like that example. Let me reinforce that with two of my own examples. One is somebody that didn’t know they were spending their time in the wrong area. This occurred when I was working at Uber. I was talking with one of my leaders and they were saying, I need to know all of the details of everything all of my organizations are doing, because I need to be able to pull levers on a daily to weekly basis to get things to change.

That might seem reasonable, and we’re not going to dive too deep into this, but depending on what type of leader and what level of leader you are, that might seem reasonable.

As an example, if you’re an on the ground leader, with three to five engineers underneath you That you’re responsible for a you’re responsible for a component perhaps I can see that being really important and you might still disagree and say even at that level. They should monitor the the system as a whole and I can get behind that but I can also get behind look you’re very tactically in the details there.

Andy: Yeah, no, I’d agree with you. At that level, you are, in many ways, a highly leveraged coder. You should understand, technically, exactly what’s going on.

Mon-Chaio: and I think at that level Saying that you need to be able to pull levers on a daily or weekly basis to change the direction of things I think is very reasonable. Oh, I see that bad code is going in here I need to be able to pull a lever to do this that release was broken I need to really dive into the details to figure out what’s going on so that the next release in two days or three days We’re crossing our fingers right like most orgs don’t release that often but in an ideal org.

Need to be able to make sure that that goes out well But this was not where this person was sitting. This person was sitting over an 80 person odd org, and let’s take numbers out of it for a second. This person was sitting in, in what I would call a triple A organization. They own some very key business APIs and underneath them weren’t just components of a system.

There were multiple systems that would roll up. And so this was pretty high level. And they felt like they needed to be able to steer the ship On a daily or weekly basis by pulling different levers. And so of course they spent their time on the wrong things Right. There’s more to get into there. But I think the impact of that was a lot of randomization I often say when you go down into the details, Gemba walks, for example Don’t put more work on the people below you You In order to give you the information you need, go to the source integrate yourself as much as you can.

This person was not doing that and so it was causing a lot of work. The second example I will give is Leaders that actually knew they needed to spend time in different places. And so one thing I often do with my leadership teams, especially early on, is I give them a survey to say, look, can you bucket out where you are spending your time?

And I usually give them four or five different buckets, and it varies by company, right? Companies have different buckets of work, but often it’s things like strategy, thinking about strategy career development of individuals problem solving or collaborating with your peers, that sort of a

Andy: It’s not just desk work or meetings.

Mon-Chaio: Uh, and phone, wait, phone.

Andy: meeting or phone calls. It seems seems like you have a slightly more granular taxonomy there, Mon-Chaio.

Mon-Chaio: A little bit. Not super granular but more granular than that..

And I think there were four or five of these folks underneath me at this time managing teams. They would, they, they responded to the survey and they said, this is where we’re spending our time. And then of course we had a discussion as a leadership group.

Is that where we want to be spending our time? And the answer was no. And I’ve run these on four or five different organizations now. And the funny thing is they always say no. There has never been somebody who said yes. They always say no. Their behavior never changes.

Andy: That’s an interesting one that I’m not sure if we should get into now or some other time. We’ll see what happens. Maybe, maybe we’ll just drift down that path.

Mon-Chaio: Absolutely.

Andy: But I wanted, I wanted to respond to your, to your first one about the person who was going down deep into the details and pulling on the levers.

Using that as an example of the way that how you can spend your time varies at these different levels.

Mon-Chaio: Mm

Andy: So, as we said, like, if he was down in one of those teams, a five person team or something, and he’s, he’s one of the developers, lead developer, and he’s, he’s setting that direction, he knows intimately all of the details of what’s going on, that absolutely makes sense. The, the engineering manager I was working with, I actually gave him something that he can be doing at kind of the next level up, or even maybe a little bit higher than that, not quite that whole 80 person. I think you’d change it again at that level. I gave him that he shouldn’t be concerning himself too much with the absolute details, but what he should be concerning himself with is, are they learning from those details?

So in this case, it was a root cause analysis for a bug that had been released, and they, they were having all sorts of quality issues. They’d released a bug. Normally, it’s just run of the course. That’s fine. In this case, though, they really need to be learning fast from what’s going on. And so I suggested he really needs to do a root cause analysis.

I could tell from his way of thinking that that seemed very disconnected from what he thought he should be doing. He thought he should just be pushing along to get the next, to get the bug fixed and get onto the next task. And I said, no, no, no, your role is to do the step back and make sure that the system is learning, that you understand how this came about.

And you understand how it could be changed and how it could be affected. Now, the next level higher than that, I would expect the person who’s overseeing a whole 80 person organization, they’re not doing the root cause analysis. They’re not running it. But what they’re doing is they’re watching that they are happening and how they’re being done.

Mon-Chaio: I like that. And Andy, I generally agree with you. I think in my experience, so for example when I was at Uber, I saw a lot of leaders attending root cause analysis meetings. And they weren’t just there to see that they were happening and making sure that the process, the system was operating in a healthy way.

Andy: hmm.

Mon-Chaio: They were there to see if there were, I mean, they were also there to do that. But a big part of their role was to push. To say, I have knowledge. What about this?

You say that we should fix this in three months. Why shouldn’t we fix it in three weeks? Which I think has value. It’s really important that those types of things come out. But when that starts to override, and to the point we mentioned earlier about why does it matter where you spend your time?

If you spend more of your time on that, And then you forget to spend your time actually thinking about the system. Are the right people invited? Is the right cadence happening? Is it, did they not think about this because the template was wrong? Am I not incentivizing the right behaviors during development?

And instead, focus more of your effort on what can I add? What is my unique knowledge that I can push? I think you’re doing yourself a disservice.

My question to you also is, as you’re giving this feedback to as you’re mentoring this engineering manager, do you think that part of his confusion stems from what his manager and his company is asking and expecting of him?

Andy: Yes, yes, absolutely. No hesitation at all. Yes. And, and that is, that is actually one of the hardest things is that the where you spend your time, and this goes back to that cultural thing I mentioned at the beginning, where you spend your time, signals to other people. Where they should spend their time.

Mon-Chaio: Mm hmm.

Andy: And so I’m going to bring up a model about signs of how your time is being spent and what it, what it signals. So there’s time use as dedication, time use as performance, time use as identity, and time use as power. Time use as dedication. You’re spending time there, and what it’s doing is it’s signaling to other people your dedication to that particular aspect of the job.

It can also be signaling your dedication, your anti dedication to some other thing that you’re not spending time on. So you have to think both in the positive space and the negative space on these things.

Mon-Chaio: hmm.

Andy: And so, if In this case, one way of looking at this is that that manager who’s sitting in that meeting dedicating their time, their thought time, to that particular problem of, Have you thought of this?

Have you thought of that? Now, you can view it as they are dedicated to making sure that these judgments are being made.

You could also see it as they’re not dedicated to like watching that system and training the people to make sure that they do those judgments themselves. It’s hard to see, but it comes down to in the aggregate, where are they spending their time? And what do others interpret that to mean? That’s the key part of this stuff.

This is what others interpret it to mean. So time use as performance. That’s the, that you have this underlying assumption that spending more time equates to getting more done, which equates to better performance. So this could be that that manager is spending their time on that, which means that more of these good decisions are going to get made, which is better performance. And I think that, for a higher level manager, they’re, they’re mistaking how they get better performance. They get better performance from the overall system working well, and they’re trying to get better performance from individual judgments.

Mon-Chaio: And also, I think this gets back to one of our earlier episodes on the feedback fallacy. They believe that the system is getting better performance because there’s a lack of knowledge. It’s the empty vessel, and so they are pouring into the empty vessel knowledge, and soon that vessel will be full, and therefore the system will be better for it.

Andy: Right. Yeah the third one is identity. It’s where you spend your time defines a particular valued or not valued identity. So, in this case, like, I imagine, I’ve never worked at Meta or Uber, but I imagine they have fairly strong cultures of identity to like doers, makers, we, we build this stuff.

And so if that manager spent their time working on this amorphous system that no one can see the lines of code getting produced, they would be spending their time on an identity that is not, not valued there.

Mon-Chaio: Uh huh.

Andy: And so this is where that, that kind of fractal nature of where your manager or where your leader spends their time signals to where you need to spend your time, because they’re starting to set up what is that identity that’s valued or what’s that identity that’s not valued.

Mon-Chaio: Huh.

Andy: I know at the place that I worked, Tim Group, me spending my time on root cause analysis meant that analysis of a failure. was highly valued. Like, we got amazing analysis of when something went wrong, because that’s where I spent my time. I was very interested in that. We didn’t get a huge amount of time spent on why a particular feature took longer than we were interested in, because I wasn’t all that interested in that.

I was very much along lines of, eh, let it happen. But I was very interested in that we had an identity of kind of like researchers. That we had this very scientific identity of, we, we research, we understand we move forward. There is no like random chance in the way computers work. It is all describable.

And so we would describe it and that was our identity. The last one is power time use is power, which is that and power is that you have control over resources. You have control over how something gets done, what gets applied to it. And this is particularly over the number and predictability of hours one is expected to work and power over how one uses time at work.

So if you use your time sitting in the cafeteria, drinking a coffee, and chatting with people. You’re signaling that you have the power to not sit in those other meetings. Now, that also then signals a particular, a kind of identity, and what performance is, and what dedication looks like. But it also signals that I have the power to not attend that meeting that you all know that I was invited to.

Mon-Chaio: Yeah. I like that. So, time use as dedication as performance, as identity, and as power.

And I like how you mentioned multiple times, especially through this model. But even outside of this model, this idea of signaling where you spend your time signals what’s important. And as I was thinking about where folks spend their time. I thought, you know, I bet it’s because of companies wanting to signal a certain importance level and I thought, Oh, you know, there’s this concept of like wartime leaders and peacetime leaders. And I thought this was super original on my part. And I felt, you know, really accomplished. But then I did a search online and realized that I probably read it somewhere because there’s a very famous author.

Andy: Because there are no original ideas anymore.

Mon-Chaio: Somebody, a very well known person, Ben Horowitz who is a co founder, I guess, of Andresen Horowitz the big the big VC firm. And years and years ago, he wrote about this concept of wartime CEOs versus peacetime CEOs. And so I read that, and I said, Ah, this is probably where I learned this years ago, and then I just forgot.

You mentioned it at Uber, at Meta. It’s not that they just value makers, right? They value what I would consider wartime behavior. It doesn’t matter what you signal in wartime. Going down and fixing a problem in wartime, the problem is what needs to get fixed.

Who cares about the signal? So you look like an asshole. Nobody cares. So, you know, you set your organization back three years because they can’t make their own decisions. Well, it’s wartime, right? I have an existential threat. So why do I care what happens in three years? Doesn’t matter.

Andy: if you want to win the war, you do care. Unless it’s a very short war.

Mon-Chaio: And, and I think there’s different definitions of wartime, but I think you know, the, the Horowitz definition would be some existential problem solved immediately.

Andy: you don’t, if you don’t deal with this right now, there may be no tomorrow. Is that kind of

Mon-Chaio: And like one example he gives is Intel had a leader they were trying to get out of the memory market, the memory chip market, because of You know the Japanese and overseas producers producing them much more cheaply and quickly and that one of the things he had to do was do something like fire 80 percent of his company Because they were all dedicated to making memory chips And so that’s like a wartime behavior, right?

Who cares how I think about retention and career development and growth of my employees? I’m getting rid of 80 percent of them because it’s an existential threat for my company. Right? But I think these companies still very much value this type of wartime behavior.

And even something that you’ve said before, I think you were consulting with a company perhaps or maybe working there where a CEO would come to you and say, Hey Andy, how does this thing work? And expect you to know it right off. Oh, here’s the details of how things work. That’s a very wartime behavior. Think one of the things that was written in the original Horowitz paper about differences between wartime and peace pine behavior.

He says something like a wartime CEO cares about a boil on a gnat’s ass. If it isn’t towards the right, in the right direction or something. Right.

Andy: If it, yeah, “Wartime CEO cares about a speck of dust on a gnat’s ass if it interferes with the Prime Directive.” I’m guessing this is not the Star Trek Prime Directive.

Mon-Chaio: I’m guessing not. And so you can see for a CEO that values wartime behavior and values those sorts of signals, he would expect you to know about that speck of dust on that gnat’s ass. No detail is too small. So, I think that is also a problem because so much of where you spend your time is signaling what’s important and building that culture. Whereas so much of wartime behavior disrespects that. Not in a bad way. It’s saying in wartime, culture and signaling just aren’t important. It’s just getting stuff done that’s important.

Andy: Mm hmm. I, I would, I would probably, in thinking about these, change the name from Wartime CEO to Crisis CTO or CEO and peacetime to Non crisis.

Mon-Chaio: Sure.

Andy: And the reason I say that is because, from what I asked you earlier on a war can last a long time. And the longer it goes on, you can’t behave that way. Because the machinery, like thinking about like the Second World War, the machinery to keep that thing going is so large and so intricate.

That you can’t know those things. You can’t demand some of those things. Yes, you, you still want results, which you should want all the time. You know, it’s like, no, this is what we’re aiming for. That’s what we’re trying to do. But that ultra crisis management approach, I think, I think one of the things I see in, in clients is when they’ve been doing that for too long, they don’t know how to do anything else.

And then they come, then their problem is. “But we can’t seem to get anything done anymore.” And everything feels like this heroic action to do anything, and to do it at a quality that they want to see happening anymore. And a lot of it is because, well, that’s the system they created.

Mon-Chaio: When I was at the Plato conference, I don’t remember if we talked about this talk or whether it was one of the cutting room floor things. A talk that I attended was a person who’s talking about how in times of crisis, you need to get down into the details.

Andy: Mm hmm.

Mon-Chaio: This is the classic wartime behavior, right? And he mentioned it as, I needed to lay off a director of like a whole group. And so now I had no leader. So, I could either assume that role or I could get really down into the details to fix things. And he said, that’s, what’s needed in a crisis, which makes a lot of sense.

I think that needs to be said more. I think some leaders forget that in crisis modes especially when you You know, when you have a skill gap because somebody has left, you actually need to go and assume those responsibilities. Great. One thing that person also mentioned was you need to get in and then you need to get out.

Andy: Yeah. Yeah. That’s the thing. Don’t prolong the crisis.

Mon-Chaio: right. However, and I think in smaller companies, getting in and getting out makes a lot of sense, but I think for a lot of larger companies, leaders can hop from crisis to crisis. Because there’s so much solution space, especially if your organization is, let’s say 4, 000 people, right? You hop into a crisis, you feel really accomplished.

You spend two months there, you solve it. You hop out. You’re like, look, I hopped out. They’re great. But now I can hop into another crisis. And I think sometimes you start to think and see crises. It’s the whole, you know, if all you have is a hammer, everything’s a nail. If your favorite leadership tactic is to manage via crisis, You see crises everywhere.

Andy: This is the same failure mode as in software developers, if you have people who are always doing heroics. They see the only way to resolve anything is heroics, and then you just keep getting situations where you need heroics. Huh.

Mon-Chaio: Weird, right? But I think it’s a little bit different. I think, maybe it’s not, you tell me. I feel like in the software world, often for engineers, it’s they create, they unconsciously create situations where heroics are needed. Where I think, especially in senior leadership, what I see more of is they misidentify a situation as a crisis when it is not.

Andy: I believe that that’s true, but I also believe that they probably create the situation that causes the crisis.

Mon-Chaio: Yeah, I can see that. But, and by mis what would you call it? By inattention perhaps that spending time, you don’t spend time to develop the system, which allows the system to get into crisis mode so that you can go and solve the crisis.

Andy: and then you solve the crisis. You’re like, hey, it’s taken care of. And then you jump into your next crisis that is possibly happening once again because the system wasn’t being managed.

Mon-Chaio: Mm hmm.

Andy: And, and now you think, oh, there’s another crisis that I need to handle. Whereas actually, this would probably be one of the most difficult things to do is you shouldn’t jump into the crisis.

Mon-Chaio: Mm hmm.

Andy: You should almost let it fall apart so can understand even better how the system is breaking.

Mon-Chaio: Ooh, there’s a whole episode on letting things fail. I’m a big fan of that. Obviously, we think a lot alike. So, listeners, if you’re thinking, this is the dumbest thing you’ve ever heard, you should challenge us. Because we reinforce each other’s beliefs. Yes, I absolutely believe that one of the best ways to get things stable is to first let it fail.

Andy: Sometimes even induce failure.

Mon-Chaio: I was just talking to someone yesterday about that, and I was saying it’s the burn the boats thing. Sometimes what you do is you burn the boats and then you’re like, look, oh, you’re failing all over because I burned your boats. Sorry. I guess now you got to learn how to do it without boats because as long as the boats are around, people will default back.

Right?

Andy: I was, I was talking to a client about they have a code freeze. They have code freeze in their process. And I was like, a code freeze is a terrible thing. You do not want to have a code freeze. But the state that you’re in, let’s make use of the code freeze. How, and it became this question of like, So you’re releasing a bug because you haven’t fully tested.

So how long, because you haven’t automated your tests, how long does it take you to get through all of your tests? And he’s like, oh, that would take, it would take days. It’s like, all right. So you’ve got an entire development team. They go into code freeze. And now for a few days, all they do is run your manual tests.

He’s like, but. There’d be so much going on. Like, I was like, no, no, no, you, you use this because this is the only thing you can do to release tested software. And what it does is, yes, it starts creating that huge pressure on everything else to understand why this is such a problem. Because if you start relaxing that code freeze and saying, oh, well, this thing was still being worked on and we’ll put that in during it.

It’s like, no, no, no, you’ve, you’ve invalidated everything you’ve just done. If it wasn’t ready by the point of the code freeze, it has to go into the next release.

Mon-Chaio: Yep.

Andy: And you don’t get to push off bugs until then. If it, if it was a bug that was known before the code freeze happened, no, that’s a bug for next release.

Mon-Chaio: Mm

Andy: Or you’re going to have to have the conversation that this release isn’t ready and you’re going to have to lift the code freeze and start all over again.

Mon-Chaio: Mm hmm.

Andy: Bye. You use, you induce that failure so that can understand what’s actually going wrong.

Mon-Chaio: Well, and threat of failure, as you were mentioning, causes pressure. And that pressure causes you to re evaluate all your beliefs. Because you need to meet that pressure. And so all of a sudden, all of these things that you thought were important, is it really important that we have a code freeze? Is it really important that everything be on a release train?

Is it those fall away when you’re like, Hey, something’s releasing in two days to production and we can’t stop it because we no longer have the mechanism to stop it,

Andy: Yeah.

Mon-Chaio: So then you start to change the way you work. And I think yeah, that, that really creates positive pressure. But interestingly, I was thinking.

Actually about these layoffs, right? This is a classic example of crisis versus system in my mind Because you have this economic downturn or whatever and so companies are doing a bunch of layoffs. That’s crisis management That’s getting down there and saying hey, I can do what my shareholders expect me to do cut costs and lay off a bunch of people The question in my mind is how many of those senior leaders are going back and really thinking about the system?

And saying, look, what was it that caused us to get into the situation in the first place? And how do I change the system to be more resilient to that in the future? Versus, well, I’ve done my job and I’ve laid off X people. Now we’re stable. And, ooh, you know, in two years, hiring’s picking back up again.

Dang, my competitors are hiring. I’d better keep up and hire a bunch of people. Right? So this is an example, I think, crisis to crisis versus the unsexy job, I would say, of thinking about that system, thinking, okay, well, what do I do to prevent this from the past in the future? Oh, what is my real hiring strategy?

What is my recruitment strategy? How does my business strategy fit into it? Should I change my business strategy so I don’t get into this sort of situation? All of those are more difficult questions to answer.

Andy: And let’s, let’s give a tactic, an old tactic for getting out of the crisis.

Mon-Chaio: hmm.

Andy: Because we’re talking, we’re trying to talk about where leaders should spend their time, and they should be spending their time Making sure the crisis is resolved, but also making sure that they’re not just producing another crisis.

Mon-Chaio: Mm hmm. Mm

Andy: And so, I’m glad that we were actually just talking about wartime CEOs, wartime leaders, because the thing I was going to bring up is the Eisenhower Matrix.

Mon-Chaio: Mm hmm. Mm

Andy: So, those who don’t know, Eisenhower, famous U. S. general in the Second World War, then a president. And the Eisenhower Matrix is It’s a very simple idea.

It’s, you’ve got things that are urgent or not urgent, and important or not important. And the urgent versus not urgent is basically a time thing and a whether or not it’s in your control thing. It’s kind of those, those are the two aspects of it. And important is, is it in your control and is it about your larger goals?

And ideally You don’t really have many urgent things. They’re going to come up, but you don’t want to be having entirely urgent. And what you want to be doing is spending a lot of your time in the important and not urgent, because then you have the space to work on it.

Mon-Chaio: hmm.

Andy: This is also why when I was a wartime CEO, I was like, well, but the wartime leaders would say you don’t do this.

Mon-Chaio: Absolutely.

Andy: Because they want to make sure that they’re not constantly in crisis. And so you do that by making sure you spend your time on the things that are important and not urgent. And then you spend your time, if I think I’ve got this right, and then you spend your time on the things that are urgent and important.

I think I have that the wrong way around. You kind of have to get the urgent and important stuff out of the way first. Let me just,

Mon-Chaio: Yeah, you have fix the crisis can fix the system.

Andy: Urgent and important, and then important but not urgent, and then not important but urgent, and then not important and not urgent. If you are really doing that, you’ve done an amazing job to somehow get to the not important, not urgent stuff.

Generally, just expect you’ll never do it.

Mon-Chaio: ha. And this gets back into identification, right? Because I think a lot of leaders also spend their time on the not important urgent .

Andy: Yes.

Mon-Chaio: Because it feels that there’s that signaling thing it feels whatever that that’s the performance you have to put in that time to show that performance.

Andy: Because it’s someone else’s thing.

Mon-Chaio: Mm hmm.

Andy: And you’ll get the recognition for solving that problem for them.

Mon-Chaio: Mm hmm.

Andy: And this goes then to what you’ll try to set up is what you’ll recognize people spending time on. So you want to You want to help people find ways of spending time on the important stuff, and not on the not important stuff.

Mon-Chaio: Yeah, I agree.

Andy: And don’t confuse important and urgent, because it’s not In my experience, I’m trying to apply this to myself. That’s one of the hardest things, is making the distinction between what’s important and what’s urgent.

Mon-Chaio: Mm hmm. I agree. That’s a, that’s a challenge I have as well. And I would imagine most people have that challenge. It requires a lot of thinking and introspection, often, in order to be able to make the distinction correctly.

And I think a really important part of that as another tactic for leaders is, Andy mentioned this in talking about the Eisenhower Matrix, this concept of it’s somebody else’s problem, not your problem. If you as a leader make everything somebody’s problem, then everything falls under urgent and important.

They can never get out of crisis. And this is something I see a lot of people who have unsegmented responsibilities, right? Oh, well, that’s your problem too. And this is your problem. And that’s your problem. And companies sometimes like to say that. They like to say, nothing is nobody, nothing is not my problem.

As if, if you see a problem in the company, you should feel free to solve it. Nothing is somebody else’s problem. I like that sort of mentality, but you also need to really strongly temper that with this concept of these are the things that you’re focused on, and kind of to the failure mode part, these are the things that you can let fail a little bit.

Not only are they somebody else’s problem, but hopefully they grow up stronger because you’re thinking about the larger system around them.

Andy: Yeah. Nice. Should we should we try recapping this?

Mon-Chaio: Oh man, I don’t know, but let’s, let’s try recapping.

Andy: All right, so what we’ve got is that you should think about whether or not you are in wartime or peacetime. And I think we came to agreement on try not to spend much time in wartime. Don’t, don’t jump from crisis to crisis.

And a way you can stop jumping from crisis to crisis is to make, make sure you’re very clear on what’s urgent and what’s important, applying the Eisenhower matrix, as well as sometimes letting it fail. Sometimes you’ll learn more from letting it fail than you will from trying to get it to fix. Then we had that you can think about how you spend your time as what you want to signal to others is important. Looking at that in terms of the len in the lenses of time use as dedication, as performance, as identity, and as power.

And if you think about how you’re spending your time and what it’s signaling to others, then you can also start analyzing that in terms of what do you want to signal to others

Mon-Chaio: agreed. And one thing to tie that together with the wartime peacetime stuff is, if you find yourself valuing those wartime behaviors, think about it through that lens. Why is it that you value that? Why is it that you spend your time there? What is it that you’re signaling and what is it that you want to signal? And that may be a good way for you to start to reduce those wartime behaviors by making some sense about what’s causing you to be in that space in the first place and evaluating that sort of that sort of work in the first place.

Andy: If you have any thoughts on where managers and where leaders should be spending their time, and how they can help themselves do that more, where they should be spending their time we’d love to hear from you. In fact, the world would love to hear from you.

If you could share this episode and share your thoughts on it on whatever social media platform you use. I don’t know if we’re on TikTok. I know I’m not on TikTok and you’re not on TikTok, but I don’t know if we’ve been shared on TikTok. So if you want to share us on TikTok, maybe you can make us go viral like, Rabarbarkuchen.

But if you want to just share it privately with Mon Chiao and I, we are hosts at thettlpodcast. com. And if you are interested in getting some help on where you spend your time, both Mon Chiao and I do this for a living. We consult with companies and help them out on their management and leadership woes and growth.

So just reach out to us. You can reach out to hosts at thettlpodcast. com as well, or you’ll find us online. But until next time, Mon Chao, be kind and stay curious.


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *