Show Notes
One way of categorizing problems faced by engineering organizations is Keith Grint’s framework of wicked, tame, and critical problems. These problem types, each with their unique characteristics and challenges, require distinct approaches to effectively address them.
Join Andy and Mon-Chaio as they provide practical insights and real-world examples to illustrate how engineering leaders can effectively switch between leadership, management, and command roles depending on the nature of the problem at hand. They also share strategies for developing the flexibility and discernment needed to identify the type of problem and apply the appropriate approach.
Tune in to gain a deeper understanding of Grint’s problem-solving framework and enhance your ability to lead your engineering team through any challenge. Whether you’re dealing with a wicked, tame, or critical problem, this episode equips you with the tools to tackle it head-on.
References
Transcript
Mon-Chaio: All right, Andy, another episode of The TTL Podcast. Today we’re talking about a concept that you brought to my attention. I don’t know where you first found it, but it’s the concept of critical, tame, and wicked problems, I believe, by a gentleman named Keith Grint. I don’t know if I’m pronouncing that person’s name correctly …
Andy: Seems reasonable pronunciation.
Mon-Chaio: um, I believe he was drawing on somebody else named Thompson’s work from before. I have to admit, I didn’t read Thompson’s work about messy solutions. But, Grint proposed that there are these three classes of problems, and that by using this taxonomy of critical, tame, and wicked, it can help, well I don’t know, I guess we will talk about what it help do.
Andy: What does that do? How does that help you?
Mon-Chaio: Maybe we should just jump right into, well, what is a critical, tame, wicked problem? How are they different than each other, and how can we do our leadership jobs better by understanding using this taxonomy. Does that seem reasonable?
Andy: Yeah, I think that sounds good, let’s dive in. So as I love doing, let’s start with some definitions. What is a critical, what is a tame and what is a wicked problem? I bet a whole bunch of our listeners have probably heard the term wicked problem before. I, think that shows up in programming. I’m from the Jargon File generation of programmers, and I’m pretty sure wicked problems showed up in the Jargon File.
Mon-Chaio: Oh, I’m not familiar with that.
Andy: Oh, you’re not familiar? Oh, look up the Jargon File. Look up the Jargon File. It’s full of hacker lore from the early days of programming. But I think that if we just start with what are these terms, because everything’s going to kind of flow out of that.
So a tame problem. It may be complicated. I’m going from the definitions presented in the paper. A tamed problem may be complicated, but it’s resolvable through unilinear acts and is likely to have occurred before. It’s a known thing. We have a known answer. It’s kind of like if I do X, Y will happen. We can kind of map a few of these things to the Cynefin framework that we’ve talked about before. So it seems like that maps to it pretty well.
A wicked problem is more complex. It cannot be removed from its environment, solved, and returned without affecting the environment. So I can’t take a wicked problem, pull it out of its context, analyze it scientifically, come up with a solution, and then say, okay, now I’m just going to go put that back in and everything will be fine. The wicked problem is inherently connected to everything around it, and it can’t be pulled out.
Mon-Chaio: Hmm. Okay.
Andy: It says “such problems are often intractable.” Their example is the National Health Service. The health system of the United Kingdom is, at its basis, a scientific approach. So it seems like the health system should be a tame problem. It’s all scientific. But if you were to practice medicine that way, you’d probably have pretty bad outcomes in a lot of cases. You have to take into account not only their medical needs, but the person and the situation that they’re in and all of these other things to get a better outcome.
And critical problems are presented as self evident in nature, encapsulating very little time for decision making and action, and is often associated with authoritarianism. So the idea is a critical problem is one where there is just an answer, and you need to just do it. And there’s a time constraint.
So you could almost say that a critical problem is one which the time constraint is so small, it doesn’t matter if it’s tame or wicked. It doesn’t matter. It’s just, you do this action and that’s all you have to do. The problem presents the action to take.
Mon-Chaio: Sure. And I think we’d be saying there’s not one right answer. There may be multiple answers. However, because of the time constraint, you simply need to pick one answer and execute it. The execution is much more important than the nuances of the answer and whether it’s the best one and what is it going to be in the long term and all of those types of things.
Andy: Exactly. And I have an example for us to use for this. At a client that I have, they are at a critical problem. That critical problem manifests itself as their customer yelling at them about the quality of the releases of their code. That every single time they release, there is regressions in functionality that had been working before. Possibly a regression that had happened two releases prior had been fixed. Then there’s a release and then it gets regressed again. And they just keep finding these again and again and again. And to me, the self evident aspect of this is you just need to test. You just need to test your system before you hand it over to your client. And the time critical nature is the longer this goes on, the less trust the client has, and the more likely that they’re just going to cancel. They’re just gonna walk away. And so, that ends up presenting as a critical problem.
Now, underlying it, there’s probably a wicked problem. And this is, I think, a thing where we can probably talk about. That thing of, there’s many different answers. Underlying this critical problem is probably a wicked problem. And so each person’s view on what’s going on provides a different way of coming up with what’s that critical action you need to do to address this critical problem. Because the underlying system is so complicated that there’s all sorts of things you could do.
Mon-Chaio: And Andy, you were talking to me about this engagement that you were having with a client, and I think I heard about this or we were chatting about this even before this concept of critical team and wicked problems came up. And when we decided that we were going to talk through this taxonomy of problems, I think one of the things we talked about was the fact that it’s clear to you coming in that it’s a critical problem, but there are some very senior people in the company that perhaps consider it a wicked problem or didn’t realize that it was a critical problem. Is that right?
Andy: Yes. Yeah. So throughout the company, most of them didn’t see it as a critical problem. They didn’t see this as like, this is imminently. going to result in a very bad situation. They saw it as , actually, they saw it as a fairly tame problem. And we can get into why I’m categorizing it as they saw it as a tame problem, but one way you can see that is that the engagement that I had with them initially started as a little bit of coaching on help us think about quality better and get better at automated tests.
Mon-Chaio: So, by definition, tame, right? You’re the consultant coming in. This problem has a known solution. It’s been tackled many times before, in many different contexts, in many different companies. And you are going to teach them how to do it. That’s a tame problem, right?
Andy: Yeah, there’s a very clear answer. And we just need to do that. Now that sounds vaguely similar to what I said to me is the clear action from the critical problem, but there’s a difference. In the critical problem, the clear answer is run your tests. You have tests, you need to just run them. In the tame way of looking at it, they thought, no, no, we need to go through a process change. We need to get that better process in place. Whereas in the critical aspect, basically it’s screw the process. Just do it. No matter how, I don’t care. Just do it.
Mon-Chaio: I imagine that in the tame problem, if you were thinking about it that way, it’s more than perhaps just a process. There’s debate around, well, some of the tests work and some of them don’t. Some of them are slow …
Andy: Yep.
Mon-Chaio: Perhaps of them …
Andy: And that’s what I was dealing with. Yep. Some of them are slow. What do we do when they fail? How do we address a flickering test? How do we fit that into our process? How do we organize automating a few more tests? What’s the right approach here?
Mon-Chaio: Or this test tested functionality that we removed, but we might want to bring it back in, or it’s being brought back in in a very different way. Should we change it so that it fails, or should we just, like, ignore the failure, right?
Andy: Mm hmm.
Mon-Chaio: That makes sense in a tame problem set, but when it’s a critical problem, you don’t have time for those discussions, do you?
Andy: No. No, it’s the patient is about to bleed out.
Mon-Chaio: Mmm hmm.
Andy: It … you put the tourniquet on, even if it means that blood will be kept out of their leg for a while and you might have to amputate. It’s amputate or die.
Mon-Chaio: Mm hmm.
Andy: So yeah. And that brings us to kind of the next part of the analysis that Grint has in this paper, which is that for each one of these different types of problems, you’ve got the critical problem, the tame problem, the wicked problem, each one of them in this analysis takes a different form of, I guess, guidance or organization is what I’ll use.
So as you could probably guess, the critical problem uses what he terms Command. You provide the answer, you just do it, you give the order, there’s no debating this, and there’s just, there’s just do it. And he calls that Command. The wicked problems, these problems where it’s unclear what a solution might be … if there’s a solution, maybe there’s only getting a little bit better, and that’s all you can do right now. That takes what he calls Leadership. And that’s, you ask questions, pull in information, find new ideas, try them out, get better. And in between, you’ve got the tame problems, and that’s what he calls Management. You organize process.
And so you can see in what we’ve just been talking about, yeah, in the Command, if I view this as a critical problem, the answer becomes find the command to issue and ensure it gets carried out. If it’s a tame problem, find the process to organize. and get it organized. So get us to think about quality the right way, get us to learn how to prioritize automating a test over adding a new feature, that kind of thing. And if it’s a wicked problem, well, you need the wisdom of the group. You need to pull people in and ask the right questions. Not just ask, how do we solve this?
But what is the implication of X? What is the implication of not running all of our tests. What is the implication of a flickering test in our automated build?
Mon-Chaio: What is the implication of releasing every time the tests pass?
Andy: Yeah.
Mon-Chaio: Does it mean that we release broken software sometimes? Should we have multiple different testing environments? Right?
Andy: Yeah. Are our testing environments reliable? Sorry, that one just came up today.
Mon-Chaio: Top of your mind, huh?
Andy: Yeah. And so it has actually been on top of my mind during this engagement. As I look at this, I’m like, okay. This is a critical problem. My leadership style has to be Command. I’m going into this very clear to myself that I am exercising command. I’m not looking for people coming up with ways in which we could automate our tests a little bit better or that we could pull in other people who’d have more knowledge about writing this code in a particular way.
That is not the problem. The problem is that we are releasing bugs and we’re not executing our tests.
Mon-Chaio: And this ties very clearly to our episode around leadership styles and how there are many different styles and there’s context for what style you should employ at what time. And it also ties into, we had an episode around how do you evaluate leaders. And what we talked about was that there’s a very clear tie between transformational leadership as a leadership style and performance an organization. But there’s nuance behind this, right, when we start to think about it this way. If your company is in a stage where there is a critical problem or multiple critical problems, transformational leadership probably isn’t the style you be using, is it?
Andy: No, no. In fact, it will get you into a worse and worse problem because you’ll be acting as though you have time …
Mon-Chaio: Mm hmm.
Andy: … but you don’t have time.
Mon-Chaio: Right, time is more important than ideas in that case.
Andy: Yes, yeah! And that’s actually been a message I’ve been using with this team. I’ve been saying, look, we do at some point want more automated tests. But test automation at the moment is not our primary driver. Time is. So use your judgment to say, will automation on this save us immediately this week more time to automate it and run it than to do the test manually?
And there could be a case where there is, but the, command is time is the issue right now, getting that test done is the issue. And so if you find a case where it’s like, I can automate this test and go through 50 different variations, and I can do that automation in 30 minutes, but to do the 50 variations that I would want to check is gonna take me two hours.
That fits with the critical framing. Do the automation.
Mon-Chaio: Mmm hmm. Well, and the reason that time is important here is because they may not have a customer in a month …
Andy: Yes!
Mon-Chaio: … if this critical problem doesn’t get fixed. And to me it also ties back to our last discussion with Ed, when we talked about hiring. And I was mentioning that there was a group that I was talking to that were talking about how should we hire this very senior PM that they want to hire. And well, they have this internal candidate which has a lot of domain knowledge and they want her to be the PM lead. But they really want somebody very senior to come in to run the day-to-day that’s done PM duties before. And are they going to be able to find this person?
So should they hire this person? Should they hold out for the senior PM that has all these things? Or should they find a junior PM who’s pretty good, and then partner him with this internal person who’s stepping up to lead the PM organization? And the CEO brought up a good point, which, I felt like I had to reinforce because I didn’t feel like it was being heard.
The CEO brought up the point which was, look we have six months. Like our next thing is six months and if we don’t do this thing in six months we might not be here as a company. And so if you’re waiting to hire that perfect hire and it takes you three to four months, that’s time, right? And so I think a lot of times people, organizations, leaders forget about time.
Which, I think is actually really strange, because it comes up in all other cases where it’s less interesting and important, and it’s brought up as really important, and then when it’s really important, it’s kind of overlooked sometimes.
Andy: When, when’s this feature going to be out? When is it going to be out? Cause I’d want it out right now, but our company won’t exist in six months. Let’s not consider that as the prime problem here.
But that, that concept as well brings up that I think that there’s an aspect of this, of what power can an individual exercise? Because each one of these different styles, Leadership, Management, Command, you’re exercising a different kind of power. So, in Command, as uncomfortable as it may seem, you’re exercising coercion.
I, with this team, I laid it out, black and white, they are testing. There’s no question about this. This is what they are doing. They’re coming up with a way to do it. They’re coming up with a way to manage the test cases and hand them out to people, and they will be executing those test cases, and we are running them.
, I shut down dissent as we got into like, oh, but how about we write the code this way, or we do that? It’s like, no, no, no, that is not our issue. I was exercising coercion.
Mon-Chaio: Which is an important skill for authoritarian leadership.
Andy: Yes, absolutely. And I will say, it is not one that comes naturally to me. I find very difficult. Back to our thing about introverts and extroverts, and that there’s your tendencies on these things as well, it’s like, no, I have to think about doing this. It takes a tax.
Um, management is very rational. It’s very process oriented. I think the conception in this paper is more along the lines of the Taylorist scientific management-type thinking of like, well, you have a process, you optimize your process, you get people doing that process. It’s a very rational, mechanistic way of working with things. And so your influence you’re using there is one of rationality. That’s the way you’re going to communicate with people.
Leadership, it’s normative and emotional. It’s about who are we? How do we feel about this stuff? How can we get ourselves aligned? Those kinds of things is the idea there. And the reason I wanted to bring this up is because not only is it that each person has their kind of like tendency, which one of these that they’ll lean towards, but also their place within the group might limit their ability to do some of these.
So, for instance, if I had been a long term manager in this, in the company, the client that I’m working with, unless I already had the authority to exercise coercion, if that was something that was kind of seen that I could do, I probably would struggle to exercise coercion. But I’m not. I was brought in as a well, gun for hire …
Mon-Chaio: Specifically to coerce, if needed.
Andy: … specifically to coerce.
When the CTO shifted my contract with them, our discussion was, I am there to coerce. I am, he even at one point told me, you’re there to be the bad cop.
So, if I had been part of that group already, I \ probably would have really struggled to get people to accept that change of role that I’m now running. I, I might not have had the ability to use that, use that power structure.
Mon-Chaio: Well, and it might have also been difficult for you, because when you fix this problem, you can scamper on your merry way. And perhaps somebody posts on Glassdoor, or I don’t know if there’s a contractor-rating Yelp or something, about this guy named Andy who came in and put his iron fist down and I really don’t like him and nobody should ever hire him.
I actually don’t think that site exists. But idea for our listeners, anybody that wants to, you know, put that site together.
Andy: Rate your consultant.
Mon-Chaio: But if you were somebody that had to exist with these people long term, perhaps that puts a damper on your ability to exercise coercion. You’re burning sort of your trust capital that you’ve built with these folks. Do you have enough capital to burn? When this critical problem is over, how will you be viewed? Does it, for larger organizations or some, even some smaller organizations, does it affect your ability to get promoted? Right? Because if getting promoted requires you to build bridges and show your ability to exercise indirect influence. Yeah, maybe the impact section of your promotion packet says they were able to solve this big problem. But without recognizing that the only way to solve this problem was to forget about that other stuff. It may put your promotion on the back burner. Right? And so you might say, Well, I can kind of solve it in the 60 percent way. Uh, hopefully they don’t recognize it as a critical problem. And then I can get promoted, right?
Because I can be seen as building consensus or what not. So, a lot of different things here to think about.
Andy: Likewise, if, uh, thinking about it, I think the more common way is that does the organization really want to see more Command, and everything starts being viewed as a critical problem and coercion is the way that you get something done. And someone who actually solves wicked problems …
Because you can only solve a critical problem with coercion. You’re not going to solve a wicked problem with coercion.
Mon-Chaio: You can, but the solution is gonna be subpar.
Andy: Yeah, it’s, it’s going to, it’s going to be short lived.
Mon-Chaio: Mmm hmm.
Andy: So if you want someone who’s actually making real progress on those wicked problems, they’re going to be more of that leadership style that’s not going to look like what that promotion rubric is going to be wanting.
Mon-Chaio: Exactly. It also makes me think of two other things. I think about dissent a lot when I think about this taxonomy of problems, and about how dissent is treated. So, when I think about tame problems, I generally think there’s very limited dissent. Normally dissent is from an ignorance issue. Hey, I don’t agree with this. Oh, it’s because you don’t have this context. I don’t think we should do it this way. Oh, it’s because you’ve never worked in this way before. Everybody else has worked in this way and understands that this is the known solution. And so, you’re working in a way where there’s very little dissent, and so you’re kind of building blocking your processes up, it’s very, very execution based. A slower execution based, but everyone’s kind of on board. And dissent, naturally I think shows up less.
I think in the wicked problem set, dissent shows up all the time. And it’s because everyone has a different context that they’re coming into the problem with. And you want a lot of dissent in a wicked problem. If you don’t have dissent, you either, I feel like, don’t have a wicked problem, or you don’t have maybe the right people to help you solve the wicked problem. And so you should be looking for dissent, and dissent should be recognized and welcome, and it should be brought in and challenged, and discussion should happen.
And then I think in the critical problems, I think it’s a critical problem. Dissent must be squashed. It simply has to be squashed because dissent causes more time, and time is not your friend in a critical problem.
Andy: I’m really struggling. We spoke about this paper is so big and so meaty, we were going to try to cut it in half, but I’m going to reference something a bit later in the paper when he gets into an analysis of what to do about this, because, to foreshadow this a little bit, this model that we’re talking about with critical, tame, and wicked, Management, Command and Leadership.
Basically, the question is, why don’t we see it all that often? Why don’t we see things properly matching? We’ve done our own thinking about it, but the author goes into his own thinking about, kind of, from a cultural perspective, what’s going on there. And out of that comes something that he says: “constructive dissent, not destructive consent”, to you’re saying, Mon Chaio.
Which is, to start handling wicked problems, which is really, I think, really where they want to get to, is how do you better organize things so that you can get to that handling wicked problems thing? Because a lot of stuff pulls you away from that. One of the things you’re going to want is you’re going to want to figure out how you get constructive dissent.
Because if everyone’s consenting, as you were saying, if everyone just consents to what’s going on, it’s actually destructive to you, when you’re trying to figure out these wicked problems. You’re not getting that different view, that different way of thinking about it.
Mon-Chaio: Yeah, I agree. And it’s only foreshadowing if there’s something to foreshadow. And I think you and I, Andy, talked about, I think there, it’s a pretty big paper, so we’ll probably have another episode on the second half of the paper.
Andy: Yeah.
Mon-Chaio: The other part of using this taxonomy of problems, I started thinking about hiring again, probably because our last episode was about hiring. I think about how often hiring and role descriptions are mismatched. And when I saw this taxonomy, I thought, wow, a lot of the mismatch can be mapped into this hierarchy or taxonomy of problems. So you think about a classic case. You’re hiring a leader. How do you bring someone into your company? You tell them it’s full of wicked problems, right?
Andy: You say, this is an interesting place. We’re not just like under the gun constantly, but we have these wicked problems, wicked dude, that they’re gnarly. You can just get your teeth into them.
Mon-Chaio: Exactly! And it’s not even so simple as just saying, well, we have these wicked problems, but then you get into the company and it turns out they’re all critical problems or they’re all tame problems. It’s a little bit more nuanced than that. Something I see a lot, and I’m going to be a little bit honest here, I myself have perpetuated this when I’ve hired leaders in the past, which is to tell them something is a wicked problem when internally it’s actually a tame problem.
I don’t have a specific example. I mean, I do. I’m not sure I want to talk about any of these examples. But the concept would be there is a problem that you say, look, you’re coming in. It’s a super interesting problem to solve. There’s all these future variations that we just don’t know where we’re going to go yet. And so, like, we’re really bringing in someone that has foresight to set up strategy and organizational design in order to be able to accelerate us past the barrier that we’re blocking. And then when you come in, you say, okay, well, I came in and I’m thinking about this problem you told me about in the interview, and I’ve got some really great ideas around how we execute. And instead it’s, no, no, that’s great. But for the next year and a half, we have a roadmap that we already have, that we already know. And your job is, to use Grint’s terminology, management, not leadership. You’re here to execute this roadmap. And all of your great ideas, that’s fine and everything. But the most important thing is to get your ducks in a row.
And I see that over and over and over again when you hire people for roles. And like I said, I have even perpetuated that when I’ve hired for roles. And so I think for people that are looking for roles or for hiring managers, I think it behooves us to like, ask that question. Okay. Well, how much of my time am I actually going to be spending on wicked problems versus tame problems versus critical problems?
Andy: That’s a really good question. And I’ll add on to that, because as you were giving that example, all I could think of was this client that I’m working with, because they were going for at least a year under the idea that they’re just in a tame problem. They wanted to organize process, they wanted to do the management. Not noticing that there was a critical problem sitting in the background, because, well, there’s a wicked problem going on based on the way that they were selling their product. It was basically they sold a whole roadmap and now they needed to execute. The roadmap plan was over like three year time span and it was all negotiated up front.
So there’s a wicked problem there. How do you resolve this? But they wanted to run it as a tame problem until you start getting to the end of that roadmap where everything becomes critical. ‘Cause you had this like ticking time bomb. You could kind of push stuff off, push stuff off, until suddenly you’re near the end. No one can push anything off anymore. And it goes to that kind of like, internally, not only externally, how do they portray it, but internally, how do they think about it? What do they think about it? Because they’re going to start portraying it as something along those lines once you’re inside.
If they were honest, they would portray that externally as well. But think a lot of think that doesn’t seem sexy, so we need to portray this other thing. Maybe sometimes you should just believe your PR hype about what the problems are that you’re encountering and re-evaluate should you actually just behave that way as though those really are the problems you’re encountering.
Mon-Chaio: I mean, I think it’s tough too, right? Because if you’re honest about what goes on internally to external people, it tends to affect your ability to recruit.
Andy: I had that once when I was recruiting when I told people, I want boring technologies. I want that particular part of our stuff to be tame,
Mon-Chaio: Mmm hmm.
Andy: And the person I was trying to hire was along the lines of, well, I know, I want a wicked problem there. I want to try new things out. I want to do new technologies. It’s like, no.
Mon-Chaio: Not quite the right fit.
Andy: Yeah,
Mon-Chaio: But I think you mentioned, Andy, that maybe believe your own PR hype. And I really do think that for many, many companies, believing your own PR hype might be a good strategy. These things that you think are tame problems that you’re trying to portray as wicked problems to attract people, what if they were wicked problems? What if you threw out your roadmap or let’s not say throw it out, but make it a lot more flexible? Maybe don’t plan three years out. That might be the first thing to do.
All right, is it tactics time?
Andy: I think it is. I think let’s wrap this up. Cause we’re trying not to start sliding into the next part of this
Mon-Chaio: And it’s so difficult. Okay, so if we just constrain ourselves to this concept of critical, tame, and wicked problems, and we have to bring in their associated solution sets of leadership, management, and command. What are the tactics here? What can we leave listeners with?
Andy: To me, the first one is analyze your situation. Don’t lie to yourself. Do a nice, rational, tame analysis of situation. So I might be wrong on this, let’s find out. Do a nice, rational, tame analysis of your situation of is this a wicked, a tame, or a critical situation? With tame being, there’s just a series of steps that if you apply them, you’re fine. And you can optimize that, you’re just working on optimizing that process. Critical, you have a crisis, you have a time constraint. The situation itself presents the answer that you need to use. And wicked, where everything’s interrelated, the more you try to pull it apart, the less it seems to come apart. Analyze it that way.
Once you’ve identified which of these areas you’re dealing with, do everything in your power to behave either as Leadership, so asking questions, Management, organizing that process, or Command, providing an answer.
Mon-Chaio: I like that, that’s very succinct. The one that I will add to that is, when you are executing a solution set, and somebody comes to you, with a different solution or with dissent, oftentimes it is because they and you don’t have a clear agreement about which of these taxonomies the problem fits into. And that’s why Andy and I love to start with definitions, right? Because if you can agree to definitions, you suddenly have a foundation in which to build on. And so if you can agree to those definitions, bring them back towards that. And say, look, are you proposing this because you think it’s a wicked problem? Are you proposing this because you think it’s a tame problem? And you might find that that can very quickly align folks to how we should be approaching the problem.
Andy: Yeah. And that gives me an idea of what to do with this client.
Mon-Chaio: Mmm. All right Andy, glad I could give you an idea of what to do. I think next episode we won’t be talking about the next part of this paper, I don’t think. I think we have something else queued up.
Andy: Yeah, we have another thing queued up, but we’ll get back to this soon because I like the rest of it.
Mon-Chaio: Yeah, I almost think the rest of it is more interesting than the beginning part of it. But we gotta start somewhere. But I think this is where we will leave our exploration of wicked, critical, and tame problems. If you’re having trouble in your own organization trying to figure out which category your problems fit into or perhaps you’re using this taxonomy but you’re finding it very difficult to get everybody on board, let us know.
We want to hear your stories, your success stories, and your failures. We talk about our failures a lot so it’d be nice to know that other people fail at their leadership jobs too. Or, if you need some help, both Andy and I do that, and so just reach out to us, let us know how we can help you. You can reach us at hosts@thettlpodcast.com. Also, if you haven’t already, we would love it if you would rate, like us, and our podcast. Not like us, I guess, like our podcast.
Andy: Please like us, though, too. I do like to be liked.
Mon-Chaio: Yes. And recommend us to your friends. or leaders that perhaps you feel need this advice more than they know they need this advice. It’s been a pleasure talking about this topic with you, Andy, and listeners, until next time, be kind stay curious.
Leave a Reply