Show Notes
In episode 29, Andy and Mon-Chaio explored Grint’s taxonomy of tame, critical, and wicked problems and how different problem categories required different leadership tactics. However, Grint had a lot more to say about the tactics necessary to adequately address wicked problems.
In this episode, our hosts delve deeper into Grint’s paper and introduce his concept of elegant and clumsy solutions. They discuss how the two solutions differ, what role uncertainty plays in dealing with wicked problems, and how egalitarian practices of empathy and community of fate are necessary to truly address the most challenging problems engineering organizations face.
References
- Wicked Problems and Clumsy Solutions: the Role of Leadership
- Rage Against the Machine: Killing in the Name lyrics
- Cortés scuttling his ships
Transcript
Mon-Chaio: Happy summer, TTL Podcast listeners, or at least I hope you’re having a happy summer wherever you are. I just came back from a very, very warm area to a place that is also warm, just not in the same way. Seattle is having unseasonably warm weather, folks here are complaining about 80 degree heat. If you’ve never been to the Pacific Northwest, that can be very warm. But that also gives you an insight into how fragile weather wise we are here in the Pacific Northwest.
Andy: It’s a bit like England where, the area that I live, if it gets over, I think it’s 28 degrees Celsius, 27, 28 degrees Celsius for three days, that’s a heat wave.
Mon-Chaio: Hmm.
Andy: So yes, 82 Fahrenheit for us would be a heat wave.
Mon-Chaio: I think I looked this up once, and latitude wise, I believe London and Seattle are fairly similar, so I’d imagine the temperature fragility probably extends to both.
Andy: Yeah, London’s, I think a little bit further north, I think it’s closer to Vancouver.
Mon-Chaio: Okay, and for those geographically challenged, Vancouver and Seattle are about an hour and a half or two hours away from each other by car, so fairly close.
Andy: And, and I’m even further north than that.
Mon-Chaio: Uh, sure, absolutely! You’re another three hours by train, right? Or more?
Andy: Two and a half hours by train, by a very fast train. Or I think if people drive it, it’s closer to four or five hours.
Mon-Chaio: Okay, okay. Yeah, and I have no idea what that’s like because I’m also geographically challenged. What’s north of Vancouver to me is a complete mystery. I have no idea. Canadians, chime in if you know. Anyhow, Andy, warm weather aside, I think we have an interesting topic which we alluded to or foreshadowed a few weeks ago. And I think I mentioned on that episode that it’s only foreshadowing if we were planning to do it. And here we are.
So, uh, a few weeks ago we talked about Keith Grint’s paper around wicked problems. And to refresh everyone’s memory, he posited that there was a way to classify problems into a taxonomy. And a problem could either be tame, wicked, or critical. A tame problem is one with a known solution that has been repeated, possibly many times. A critical problem is one that has a time constraint that obviates all other necessity, and the time constraint is the most important part of solving the problem. And a wicked problem is one that is neither of the two, but somewhere in between, perhaps. And possibly combines tame and critical problems all into one. But is a problem that cannot be removed from its surroundings. That it has tendrils into weird places and if you solve a wicked problem in an incorrect way, it often creates another wicked problem that presents itself.
Andy: And it may have no solution. That’s a key.
Mon-Chaio: Very good point. It may have no solution. And what we talked about in that last episode was that depending on the problem, whether it was tame, critical, or wicked, Grint proposes that there are different leadership styles that are associated with each of those.
So if you have a tame problem, you should be employing what he calls management. This idea of utilizing processes and formalizing processes and getting better at the processes in order to solve the problem. If you have a critical problem, he posits that you should be using command leadership. This coercive, directive style of leadership where you’re telling people what to do because time is critical and you should have all the answers even if they’re wrong because inaction costs time and so uh, you know, any answer is better than no answer and you are the leader who is directing everything below. With wicked problems, he posits that you should be using something that he calls leadership. This idea of utilizing the community, asking questions, figuring out who has the best answer to portions of the problem and gathering them together. What I think of is analogous to what we have talked about a lot as transformational leadership or with a lot of similarities.
So that was the first part of the paper, and I think we talked through that. But as we mentioned in that episode, there is a whole other section of the paper, and I think it’s even longer. I think it’s, we maybe only talked through the first third.
Andy: Yeah, I think it’s about one third of the paper and then now we’re getting it into the other two thirds.
Mon-Chaio: And the second half of the paper kind of ties back to the first part, but it offers more interesting questions, which I think both of us thought would be fascinating for us to talk through. And I … this is one, I think where we haven’t really talked to the second half of the paper. We haven’t even briefed each other on what we thought when we read it. So I think this will be very interesting to talk through.
A quick summary of the second half is that Grint then talks about a framework, proposed by Mary Douglas, around this concept of cultures being divided into grid and group. Now I don’t think going into the details of the grid and group stuff is super important, but it does pan out into these three grids that Grint really focuses on. This concept of hierarchical grid cultures, this concept of egalitarian grid cultures, and this concept of individualism grid cultures. And he says that for all of those cultures they have a specific way of dealing with problems. The hierarchical culture likes to deal with problems with processes and hierarchy. I am the boss, therefore I tell you what to do. You are in charge of this problem, therefore you should direct your subordinates to do x or y or z. The egalitarians like to bring everybody along and create these democratic processes whereby they say, look, do we all agree? Do we disagree? Can we all get on board? Can we all agree to a solution? What’s best for the collective group, that sort of a thing. And the individualists are the ones that care about, well, the individuals, right? That if you enable the power of the individual, that individual will help solve your problem. This is kind of the give the problem to the person who’s most suited for working on it. This concept of like individualized genius, right? Innovation comes from one person’s brilliant idea that comes out of the fold. And what Grim posits is that when you have a wicked problem, you cannot box yourself into one of these boxes. Your leadership style must span all three cultural boxes, hierarchy, egalitarian, and individualism.
So, that’s lot of talking for my part to summarize this. I hope that means that people can still understand this conversation without having to read through the entire paper. But it is also a lot. So, Andy, where do we want to start?
Andy: Well, I want to go back to that grid a little bit, and talk a little bit about that. Because one of the things that he was drawing out of it was this difference between elegance and clumsiness.
Mon-Chaio: Mmm hmm.
Andy: And specifically that each of these different cultural groups, the Hierarchists, the Egalitarians, the Individualists, each one of these has elegant solutions to crisis and tame problems. Within each one of them, they have these great ways of doing it. So you could say that, for instance, the hierarchical one, the scientific method is a very hierarchical process. And for particular kinds of problems, if you just apply that process, you will get a solution. And it’s completely elegant. It’s amazing. And so he calls these elegant solutions. The ones that fit within one of these domains. and it just flows. To solve wicked problems though, elegant solutions don’t work. That’s the center of the claim that he’s making.
Mon-Chaio: Agreed. Yes. And so he contrasts that with what he calls clumsy solutions.
Andy: Yeah.
Mon-Chaio: And a clumsy solution in his mind is one that must cross all domains. And I think that makes a lot of sense in my mind. The part that didn’t really resonate with me was how he kept coming back to this concept of pure architect versus … I think it translates to bricklayer. I didn’t translate his language. Do you know what um …
Andy: Bricoleur? Uh, it’s a person who practices bricolage and bricolage is … what do we call it in English? It’s where you put a whole bunch of different things together, like found objects and just whatever you have on hand. It’s a form of art.
Mon-Chaio: I see. I see. Okay.
Andy: The idea is that you need to be a bricoleur, a crafter who’s just getting all of these things that you find and pulling them together into something coherent.
Mon-Chaio: And I’ll tell you why that didn’t really resonate with me. The concept of an architect on high in an ivory tower designing something. He mentions that that might work with elegant solutions. You’re all within your single cultural domain, and you can lay out the problem, you can lay out the solutions in a very architectural style. But in a wicked problem, he says you have to cross domains. And so his conception of it seems like somebody who doesn’t have a vision. Somebody who’s just taking pieces that they find and saying, okay, well, what’s the best solution to this particular part? And how does this piece fit in that I found? And maybe I can discard this one piece and bring in this other piece.
But I don’t necessarily believe that to be true. I believe even in wicked problems, it’s important for leaders to have some sort of that ivory tower experience of standing up top and saying, look, this is kind of the path we want to take. It can’t just be, I’m just going to move wherever the wind takes me. Which is a sense I get in his bricoleur analogy.
Andy: I think he also doesn’t want you to just go wherever the wind takes you. There is a place for having a vision, but he tempers it a bit with the idea of phronesis from Aristotle. He says it as “the Wisdom to acknowledge that the situation is not like any other combined with the experience to recognize that such Wicked Problems require a qualitatively different approach from Tame or Critical.”
So the idea is, you want to recognize that you might have an idea, but your idea might not be the right thing. And then combine that with what he says is one of the things you need from the hierarchical approach to things, which is you want reflection, not reaction. So from each one of these domains, he wants you to pull on a different way of thinking about the situation, a different way of behaving. And one of the three from the hierarchy is to reflect rather than react. So he’s saying like, no, you don’t get there by just reacting to things happening. You get there by I think having a bit of that vision of where you might want to be going, but reflecting constantly on, well, why aren’t we there?
In fact, he cautions against action. He says, ” we [too] often conflate ‘doing nothing’ with ‘reflection’, but they are not the same thing. The former implies indecisiveness, indolence, and weakness, while the latter implies a proactive, philosophical assessment of the situation.”
Mon-Chaio: Right. And I like his, uh, I hadn’t heard this before. I like his concept of the cliff and the mist.
Andy: Mm.
Mon-Chaio: He mentions that you’re standing on the edge of a cliff and a mist descends. If you’re jolted into action you may just go off the edge of the cliff whereby probably the best thing to do is wait a while and perhaps the mist will lift and you’ll be able to see more clearly.
Um I don’t know, I had a different reading of his concept of reflection. I agree that he talks about this concept of reflection in opposition to action and so it’s not just go forward. But in my reading of the paper, it does appear to me that he’s very much against this concept of a strategy or a known strategy or the leader having sort of this vision or path forward.
He really conflates it with the bricoleur, right? This concept of you’re moving and … I don’t know, I, I really do feel like it’s more where the wind takes you type of thing.
Andy: I think the way I think about it, because I very much agree with his way of thinking about this, so maybe that’s why I’m happy with it. I think the way I think about it and the way I think he thinks about it is, because there is no elegant structured solution, it’s not that you just go wherever the wind takes you. It’s that you don’t fight against it unless there is a very clear reason to fight against it.
Mon-Chaio: Hmm. I think your way of working is one that I generally agree with as well. I probably lean slightly more towards a concept of a more stable vision. But I don’t think we’re too far off. I guess I just didn’t feel like reading his paper that he leaned toward that. I felt like his posture was much more on the we’ll just sense make until the end of time because that’s what wicked problems require.
Andy: I would agree that he probably hid it. I think it’s in there. I could be reading into it. But I think it is a little bit hidden. Other places that I see it pop up, we’re saying, “this is not, then, the clean world of analytic models and rational plans for progress to perfection.” Sounds like, oh, well, then there’s no idea of perfection. And he says, instead, “this is the world where […] wise leaders are ‘opportunistic, ad hoc, devious, creative, and original.’ The assumption that wise leadership can be reduced to this might strike the reader as rather inglorious, even mundane, a reflection also captured in […] ground-breaking claim in 1959 that most decision-making mechanisms were little more than ‘muddling through.’” So he says “the first step here is for the hierarchist to acknowledge that the leader’s role has to switch from providing the answers to asking the questions.”
Mon-Chaio: Mhm.
Andy: So a thing that I see in there, but maybe this is my conception of how to ask questions …
Mon-Chaio: Mhm.
Andy: … a thing that I see in there is, to ask a question, I have to have an idea of what everything implies should exist. And to me, that’s a bit of what a vision is as well. It’s kind of like the shadows for Plato, we see these things happening, something else must exist. And so we can ask questions.
Mon-Chaio: And I think that’s, in my view, the right way to formulate and think about it. I don’t think that’s what I got out of the paper about what he’s positing. But that actually doesn’t matter.
Andy: It’s what we take out of it!
Mon-Chaio: That from our reading of the paper, whether it’s that or not, our guidance would be that that would be the way to ask questions. That a leader does have to have a vision. You have to have some place that you’re taking your group. Now it can’t be too structured in such a way that the wind is blowing you off course and you’re staunchly avoiding it to the point of failure, right, which is what Grint says happens a lot, when you get locked into one of these cultural buckets.
Andy: And I think what he’s pointing out is what’s happening there is that you are stuck on an elegant solution.
Mon-Chaio: Mm hmm.
Andy: Whereas, what you need is a clumsy solution.
Mon-Chaio: Mmm hmm. I’m not a big fan of myself using that terminology. I don’t necessarily agree with it. What I take out of it the most is his concept of learning to live with ambiguity.
Andy: Yes!
Mon-Chaio: And regardless of whether it’s an elegant solution or a clumsy solution, because I think some wicked problems can take elegant solutions, and I think some tame problems could probably be best with clumsy solutions as well. But I do think that for everything, this building of the ability to live in ambiguity is going to be so important. And I think that’s a key thing that I take out of the paper.
Andy: Yeah. And he calls that negative capability. The thing that I watch on teams that are not able to practice negative capability, this living with the ambiguity, is that they very quickly grab at an answer, because they’re unwilling to sit with this idea that we don’t know what’s happening.
Mon-Chaio: I think all of these things end up being a balance. And I think some groups, especially more modern groups that I’ve seen, that really try to lean into this transformational leadership style for their organization, often, I think, they lean into negative capability too much. And this gets back into Grint’s thing about they’re always sense making, right?
There are these groups that, I don’t know if you’ve seen them, Andy, in your work, I’ve certainly seen them, that seem to experiment ’til the end of time. Everything’s an experiment for all time because they feel like they never know anything.
Andy: Yeah, I’ve that.
Mon-Chaio: So I think there’s always this balance. And the story that I’ll use here, one which was not particularly successful, was I was working in a large company and they had two different platforms. One platform was for the front serving of the customer and the other platform was for reconciling customer details or back office, you might think about it. And the way they calculated a particular metric, the two platforms would deliver different answers.
And there were many reasons for it, right? One had to basically deliver an answer within milliseconds for the customer. The other was more of a reconciliation system. So you had to be accurate because you had to charge money out or you had to know what you were going to spend the next cycle or whatever the case may be. So the leaders of these two systems had to decide what to do about this. And we could decide what’s right or wrong, but one way of not living with ambiguity is to basically say, these two have to match and …
Andy: I’ve encountered that many times in systems where you’re like, no, inherently in this domain, there will be drift and we have to figure out what to do about that. But to say they have to match at all times, it’s like, hmm, yeah.
Mon-Chaio: And there was some, it has to match, but it was very much then of there should be one system that owns the logic performing this one calculation. And so I think the immediate conclusion that there needed to be one service or one group or one component that owned this capability, I think shows that like they’re not ready to sit in negative capability, right? They were uncomfortable with this.
And it does present discomfort. There’s a lot of problems with having different answers. You have customers asking wait a minute, you told me this and so I made this decision and now it’s a month later, you give me a report and you told me it was that. How can that be? But I think that there are multiple ways of resolving that that Grint might propose if he said that was a wicked problem.
Now, if that was a tame problem, then perhaps you come back and you say, look, three other companies have solved it this way. And yes, it is one system that owns this calculation and they’ve proven that it works, and so let’s just go execute it. And then, yeah, then you create a team to go execute that and whatnot.
So, um …
Andy: But then you different kind of wicked problem there. Too often, it’s like, it’s been done, but it’s not been done here, and it’s not been done by this group, and it’s
Mon-Chaio: And Grint makes that like … I actually very much dislike his writing. I don’t like the way he writes. But I do like the way that he pulls in little anecdotes that I hadn’t heard of. And I can’t remember what it was, but he talks about, he’s like, I think it was the health system. He said, if you go in with a broken bone to the hospital, that’s a tame problem.
But if you go into like, I think he said like your local sandwich shop with a broken bone, that’s a way … that’s a wicked problem ’cause they’ve never done that before.
Andy: And at this point I actually kinda want to bring in something one of our listeners sent to us. So Samir sent to us that he liked our discussion about Tame, Critical, and Wicked. And he wanted to add onto the wicked problems, or onto the tame problems actually, which is that underlying pretty much all tame problems is some sort of wicked problem, if you dig far enough. And I agree with him. I partly agree with him because I used to work with him, and I believe that I told him at one point that if a developer ever says, well this is easy, I’ve done this before, then they’re not thinking hard enough. Because, we’re developers, we automate. If we’ve done it before, if we’ve done it like five times, then we’re solving the wrong problem. We should be finding the hard problem in that, which is getting rid of the problem and addressing that.
And that was his point, is that underneath all of those tame problems, there’s probably a wicked problem. There’s always some sort of hard or wicked problem underlying a lot of these things that might be more valuable for us to dig up and look at.
Mon-Chaio: And in some ways I agree with both you and Samir. Because I think tautologically it’s true that going all the way down there are very very few absolutely tame problems. Maybe you can say that two plus two equals four is a tame problem. I don’t think there are any wicked problems underlying that.
Now, I do think that people too often … tame-rize problems that should be wicked problems. This is to Grint’s point this ability to not be able to live in negative capability. You want to jump to a solution. Let’s make it a tame problem so that we know the answer, or that so that we can start to do the things we do best, which is get a team together, put processes in place that we know work. If you’re good at that, and if you live in that cultural box, that’s where you default to.
So I do think that people tend to tame-rize problems too much. Uh, that’s not a word. I don’t know what the word is.
Andy: It’s a great word, though.
Mon-Chaio: But, and here’s a big but, I also see that there are times when the wicked parts of tame problems don’t matter in that time and in that aspect and in that context. I once had a manager who was really great at that. Every tame problem you would give this manager always had a wicked problem coming out of it. But what about this? Have you thought about that? And, you know, sometimes you just gotta get some stuff done, man.
Andy: Can I maybe blow your mind?
Mon-Chaio: Yes, blow my mind.
Andy: That issue that you’re just talking about, that people identify a tame problem when it’s actually a wicked problem, or identify a wicked problem when it’s actually a tame problem, or identify a wicked problem when the wicked problem is not the thing that’s all interesting right now, that’s a wicked problem! So dealing with that, understanding, okay, what is it we’re dealing with here? That is a wicked problem. So you’re going to need to be addressing the negative capability, the constructive dissent, not destructive consent.
These are all different things that he brings up are parts you need to deal with a wicked problem. The reflection, not reaction. So, like, oh, I think it’s this wicked problem. Well, let’s reflect on that a little bit before we just act on that suddenly. Or relationships, not structures. Oh, just hand this to the delivery team and we’ll be fine.
Well, we haven’t been fine for the past five times. Let’s go and talk to the delivery team and find out what’s going on.
Mon-Chaio: Mmm hmm.
Andy: Figuring out where you stand in this whole world of are we dealing with a wicked problem here, are we not? That is a wicked problem. And it’s one that just comes up again and again and again and again, and you’re just constantly living in it.
Mon-Chaio: Yes. And this is where I think we’ve all talked about this a lot. I think that is the crux of leadership of a technical organization. He talks a lot about it’s the system, not the parts of the system or not the individuals in the system that are broken. It’s the system that’s broken. And he’s positing a way to think about the system and change the system. And I a hundred percent agree with them. And I think, look, in leadership, you have a lot of different problems, but arguably the core problem is this wicked problem that never goes away, which is how do you structure your organization? What are your like hiring practices? What’s your cultural tenants? And those are the things that, we always talk about, you should be thinking the most about, right?
I mean the relationships versus structure he mentioned, right? Relationships versus structure problem, I think is a big one because he starts this paper talking about, there have been multitude of writings around change processes and yet we know that change doesn’t work. Why, right? And so he proposes this way of thinking about why change doesn’t work. And one of the things he says is we reorg ’til the end of time and yet we get the same behaviors. And says that’s because relationships don’t change. But if you don’t change the relationships within it, I don’t think the structure helps you change that.
Andy: A lot of reorganizations fall apart because the relationships between all those other groups, between all those individuals to get work done, they possibly never changed. And so the structure, the who reports to whom, does much less than if you just change the relationships.
And I’m watching that on a team I’m working with right now, where it was like, we’re gonna come together, we’re gonna become cross-functional teams. They were told, that’s your new structure. But their relationships didn’t change. Their relationships to each other remained exactly as they were. And no one really worked on the relationships. In fact, they continued behaviors that continued the relationships they didn’t want, which was that people worked separately. They wanted, through cross-functional teams, them to work together, but they never addressed the relationship. All they did was they said, here, put these four groups together, and you’ve got a cross-functional team.
Mon-Chaio: Well, and I believe, Andy tell me if you read this differently, I believe that when he talked about relationships, it was around sort of the cultural behavior of people. And when he talked about structures, it was more than just the reporting hierarchy, but it also encompassed the processes.
Andy: Yes, it’s processes as well.
Mon-Chaio: And I see this a lot, right? It’s not just that you reorg to be a different team, but, oh, well, we want more people seeing more parts of the code, so the process comes into place. Every change has to be reviewed by someone outside of your group. But if the relationships don’t change, does that really affect a behavior change?
In my experience, no. In my experience, you get these shallow sign offs by other people in the group, right? They reserve the last two hours Friday to go through their queue and be like, oh, these are my non-group sign offs that I have to do because I now have the process. And does that really affect meaningful understanding of different parts of the code? I think it affects shallow changes, but the meaningful changes don’t change, I don’t think, because the relationship’s never changed.
Andy: And the thing is, is this idea of relationships versus structures, it’s an individual thing. And this is a big message we haven’t gotten to yet about this, which is that to get change, it’s not just on the leader. To get a wicked problem solved, it’s not just on the leader, it’s on everyone involved. And so the relationship’s not structures. That’s not like the manager tells you, oh, you’re a cross-functional team, you’ll work together, and then somehow it suddenly works.
No, it’s actually an individual choice of each person involved. If they don’t have the agency, or if they don’t act the agency, then nothing will change. And in fact, he kind of brings that in, in this idea of positive deviance, not negative acquiescence.
Mon-Chaio: Right. I really like this concept of negative acquiescence versus positive deviance. Just like I like this concept of constructive dissent, not destructive consent. The acquiescence and the consent part are both things that I see way too often. I’ll just do what you tell me. Right? I have a way of working. You want me to do this. I’ll do what you tell me, but my way of thinking, of working, of understanding, of sense making will never change.
Andy: So you might outwardly be saying, I’ll do what you tell me, but internally you’re saying,” fuck you! I won’t do what you tell me!”
Mon-Chaio: And even if you’re not raging against the machine, I think people are less, um … I don’t think they’re so coercive necessarily, but people do what it takes to survive, right? And when you don’t change people, their survival mechanics kick in. And it’s not that they’re saying, oh, well, I don’t want to be a cross-functional team. They hear you and they say, listen, I understand that you want me to be a cross-functional team. So you reorganize this in this way, great!. But like the way that I work is still I think about a problem and I take in and write my own little spec or whatever. That’s the way I work.
So how do I fit that? How do I survive now within this new structure? I think a lot of leaders think that that’s not what they’re doing, that by forcing cross-functional teams, all of a sudden people will be like, oh, every spec now needs to be written by three different people and I need to get together on a whiteboard, but that’s not really what happens. And so you absolutely see that.
Andy, you were telling me this story earlier of a staff meeting where no questions were asked when a very controversial and actually unsatisfactory presentation was made, right? And I think that shows up a lot, this idea of negative acquiescence or destructive consent. Oh, they said that. Ah, I don’t know if I agree with it, but listen, whatever. I don’t want to get fired, so whatever they said, that’s great. And I’m just going to do my best to fit into that. But like my behaviors don’t really change at the end of the day, unless leadership really works on helping me change my behaviors.
Andy: And, for that, we haven’t talked about the egalitarian part of this yet. But I think we’ve finally hit on where it really comes in. Because maybe you’re getting this destructive consent and negative acquiescence. And you’re starting to wonder, what’s going on here? Why is this occurring?
And here, according to Grint, this is where you can start pulling in the egalitarian approach to things. And one of them is empathy, not egotism. He calls it that, to me, this is the Gemba Walk. This is going and seeing, trying it out, actually doing the thing, and seeing what is the experience of being in that situation.
Mon-Chaio: Mm hmm.
Andy: So you want “to generate an empathy that facilitates understanding of the other, and is a prerequisite for addressing Wicked Problems.” And I’m seeing that a little bit myself, where I’m working with a team where they don’t write very many tests. They have been put into these cross-functional teams and they don’t interact.
And so I’m kind of stepping a little bit out of where I would normally try to step as an engineering manager,
Mon-Chaio: Mmm hmm..
Andy: But I’m putting myself into situations where I’m like look, I’m going to look in the code. I’m going to try to interact with you guys, in the form of a developer. And from that, I’m learning the way that they approach these things. So I’m learning that they’re uncomfortable to follow the path of data and control into other codebases that aren’t theirs. They’re not adept at writing tests. And so I’m starting to see, okay, that’s why I’m getting more pushback on why we’re not getting as many tests written.
I also learned one thing, which is they have a lint rule turned on that a test method can be no more than five lines.
Mon-Chaio: Wow, that’s such a good rule Andy!
Andy: No! That was, cause I kept looking at, just to go off on a tangent for a second, I kept looking at the test cases and I was like, why are there so few test cases and why are they so mundane? And then in doing this, I was like, well, I’m writing some test cases for this. And I started coming up with more and more interesting scenarios. And as I tried to assert exactly what I was getting, to be more precise and make sure I could catch bugs, well, that got too long, so it kept telling me, it kept telling me, no, no, this method is too long.
Mon-Chaio: Well, weirdly, Andy, this isn’t a tangent, because this is a hierarchical solution to a non-tame problem, right? They thought it was a tame problem. The problem probably was two interconnected test cases that tested too many things, but they thought it was a tame problem and tame problems go by process solutions, and process solution was five lines,
Andy: Yeah, we’ll just tell you you have to keep them shorter. And what happened? Basically, you made it nearly impossible to write meaningful test cases.
Mon-Chaio: Another problem cropped up, right? Um, I want to touch on what you said about the Gemba Walk because I do agree and then I want to touch on something else that I think egalitarians bring in which is even a bigger deal than the empathy, not egotism part.
I think the Gemba Walks are things that we both really love, but I think you have to do it right. I’ve seen so many companies say, oh, engineering managers need to stay technical and connected with the system. That means they need to code. I think that’s absolutely wrong. So to use an example from his paper, he was talking about chief constables in the UK and their form of empathy, not egotism, their Gemba Walks was to go out on patrol, to figure out what constables are facing on a day to day basis. That’s absolutely correct. Yes. 100 percent agree. But the mechanisms of how you action that, there’s nuance there. Like, would I send out a chief constable on their own patrol by themselves to an area that they’re not familiar with? No! Right? Like, what does that mean? Would I give a chief constable their own precinct such that every week they had to go out on patrol? No! At least not for me, right?
My way of dealing with this would probably be I’d partner chief constable, I’d rotate them, and so once a month, they’d have to go out on patrol on different precincts with different constables and get to see what they face, right? So there is nuance on these Gemba Walks. And sometimes I think companies say, look, engineering managers need to own a particular section of code and that’s theirs and that’s how they gain empathy. I think is …
Andy: Oh, no.
Mon-Chaio: … completely wrong.
Andy: No, no. You gain empathy by pairing with them and joining them on the task. And if pair programming is already a normal thing for them, this isn’t an extraordinary action.
Mon-Chaio: Mm hmm.
Andy: So yeah, you kind of have to think how do you build in the ability to do a Gemba walk?
Mon-Chaio: Well, and I might have mentioned on this podcast, maybe even several times, but even organizations as large as 60 or 80, I used to pair. I used to try to dedicate at least one two-hour block. I tried to dedicate two two-hour blocks every week, but usually I only got in one, to pair program. And my managers thought it was super strange and IC’s thought it was really strange.
And I ran into all sorts of problems, which, this is not the right time to talk about them, but I do think that you need to build that way in. And I don’t think the right way for you to do it is to own code. I do think it’s this pair programming stuff. We can talk in another episode about how we structure that.
Uh, but I did want to talk a little bit about community of fate, not fatalistic community. Because when we start to get back into those staff meetings where nobody asks questions, when we start to get back into these destructive consent type scenarios, I think it is a lot of times because you have this fatalistic community.
Things are happening to me and maybe you don’t feel them as destructive, you’re just like, I don’t care that things are happening to me because it’s not my concern. The problem is it should be your concern. Almost everything the company does should be your concern in some way. And so for the egalitarians, to focus on what Grint calls building a community of fate instead. We are all in this together.
Now, the example that he gives is Cortez burned the boats, right? So that they had no choice. They were all responsible for each other’s survival.
Andy: So the only thing they could go was, just continue on with genocide. That’s …
Mon-Chaio: That’s right. Exactly.
Andy: … not what we want. That’s not …
Mon-Chaio: No, Cortez had his vision, Andy. He was not sense making here. He had his vision about what he wanted, right? Um, but I do think it’s important. Even more so, I think, in today’s engineering organizations, which are so individualism focused, that this concept of building a community of fate, of gathering everyone together, is one of the most important things you can do.
Andy: I did a retrospective today with this team I’m working with, and we’d had two pretty hard weeks as we tried to get a release out, get all the tests done, fix all the problems that we were finding, just, and do that again, and again, and again. And what was interesting, in this retrospective, the common thing, like multiple people put this down, is what went well was basically that we were all stuck in it together. And everyone was doing it and we were all working together. That was the main thing that they’re like, that went really well, we liked that.
Mon-Chaio: I love it All right, well, is there any, I don’t know if tactics are the right thing here, Andy, or sort of just last points?
Andy: I think I’m gonna leave the listeners with what Grint left us with. He ends the paper with a quote, and I like it. He says, Lawrence J. Peter had this quote: “Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them.
And to me, that’s a key part of a lot of this. Like, we talk about, yes, I think there should be a bit of that vision, but the key is to recognize that what you’re dealing with has so much to it that it takes all of your intelligence and all of your knowledge about the world, what’s going on, to be able to hold yourself undecided.
And that what this paper is full of is ways to hold yourself undecided.
Mon-Chaio: That makes a lot of sense. I like that summary. I think this is a great place to end, talking about Grint’s Wicked Problems paper. Thank you Samir for listening to our previous episode on wicked problems and sending a … interesting thought for us to talk about. We would love more of those. And so, if you have a thought about this episode, please reach out to us: hosts@thettlpodcast.com. That’s “hosts” with an “s”. Or anywhere we have social media presence. We’d also love it if you could rate us, recommend us to your friends on your favorite podcast platforms. And if you personally, or your organization, is facing difficulties like this and would like some help, Andy and I both do that. So also reach out to us, let us know how we can help you. Until next time be kind and stay curious.
Leave a Reply