Show Notes
In this episode, we explore the ideas from the book Teaming about how to organise to learn. Organising to learn takes framing to learn, psychological safety, learning from failure, and crossing boundaries.
The opening quote is from chapter one of the book “Teaming” by Amy Edmonson.
References:
- Google 20% time – https://builtin.com/software-engineering-perspectives/20-percent-time
- Praiseworthy/blameworthty chart – https://hbr.org/2011/04/strategies-for-learning-from-failure
- Teaming – https://www.wiley.com/en-gb/Teaming%3A+How+Organizations+Learn%2C+Innovate%2C+and+Compete+in+the+Knowledge+Economy-p-9780787970932
Transcript
Andy: In some respects, organizing to learn is not all that different from organizing to execute. There’s the same discipline, respect for systems and attention to detail. Look more closely, however, and it’s a radically different organization mindset that focuses less on ensuring a process is followed than on helping it evolve.
Mon-Chaio: Thank you for joining us. In this episode, we are going to cover a book called Teaming by Amy Edmondson. This book is 300 pages, so we’re definitely not gonna be able to cover everything.
Andy And I thought that would be really interesting to talk about building learning organizations and what it really means to build a learning organization.
Andy: Absolutely Mon-Chaio. So to give a short overview of the book, because I think if we start diving in on just these four concepts, they’ll be without context. I’ll give a quick overview of what the whole book is, how this relates to it, and then we’ll dive in on this. So the entire book is about what Amy Edmondson calls teaming.
So in the book, there’s a lot of different definitions of teaming. We found at least two they’re not incompatible with each other, but they did make it a little bit harder for us to get our head around the concept. Mon Chao, however, found one that I think we both agree on we think is useful.
So, Mon-Chaio what was the definition you found in the book?
Mon-Chaio: Right, so the definition I found is teaming is a way of working that brings people together to generate new ideas, find answers, and solve problems.
Andy: All right, so, so teaming is about working together, solving problems, finding answers, easy, simple to work with. I think we can go from there. Now the book is based around three separate ideas. You’ve got teaming, built on top of teaming organizing to learn, and then built on top of organizing to learn execution as learning.
Mon-Chaio: Mm-hmm.
Andy: one of these builds up kind of like an organizational capability. The way I was thinking about it, and I’ll see if you think about it, the same way Mancha was teaming is at kind of like an individual level teaming was how do people and small groups maybe interact to work together.
The next level up organizing to learn is a bit more like a group or, or team level where, okay, how are you going to put those people together now and move them in a direction where you’re not just executing, but you’re learning. So your measure isn’t so much did you get 20 widgets out or did you write 500 lines of code today?
It’s, what did you learn today? Is that about right? Mon-Chaio so far.
Mon-Chaio: Yeah, I would say that that’s absolutely what I took away from it.
Andy: Okay. And then the last one, The execution as learning is to say, yeah, you still want that 500 lines of code. Execution is important, but you’re not optimizing everything just to get that execution as high as humanly possible because you want to put some of your effort into learning. So execution as learning says, how can you approach work as an organization?
How can you approach work so that you not only do it, but you learn from it and change your processes, change your practices, and get better as you go, or change what you’re doing because you learned it’s not the right thing to do. All of those are possibilities in the learning.
Mon-Chaio: I think the other part of executing to learn is this concept that you don’t take space to do learning. Learning comes as part of the stuff that you do day to day in a fast moving environment.
Andy: Yes, it is the way you operate rather than an add-on.
Mon-Chaio: Mm-hmm.
Andy: And I’ve encountered that before, where a place I worked, we used to do the famous Google 20% time or 10% time. We did it every other week. And eventually we dropped it because it created the wrong learning environment.
It meant that learning was this thing off on the side rather than just the way we operated. And so we changed that, we dropped that practice, and we said, how do we incorporate this into what we do? It created a very different approach to experimentation and learning. So this time, we’re gonna focus on organizing to learn and organizing to learn.
In the book, she breaks it down into four behaviors or four areas that are important.
Mon-Chaio: Let’s step back just briefly. I think maybe we should talk about why it’s important to organize, to learn. The analog to organizing to learn is organizing for execution. And , in the book, she talks about the differences between the two and in various groups, in the companies having different stages. Some groups and stages require a framework of organizing to execute, to get things done when steps are well known, when the result is unassailable.
And the only important thing to do is get that result versus organizing to learn, which is when you really don’t know the best way forward. And you need to have a lot of innovation, asking questions and curiosity in order to get to the optimal result.
Andy: Yeah.
Mon-Chaio: And I think the reason. At least to me that organizing to learn is such an interesting topic to talk about is I would say that most software organizations should be by default, organized this way, even though I think perhaps people view themselves as execution based organizations.
Andy: some, sometimes I hear people talk about this as they’re stuck in the software factory.
Mon-Chaio: Mm-hmm.
Andy: In fact you even have what is it? The s e i the software Engineering Institute they have a process called the Software Factory. It doesn’t have in it the bad connotation that I think most of us get from that.
But the idea is that software development should be repeatable and definable. And one of these routine tasks and. I think before we move on, actually, I’d be interested in, let’s do a short discussion on do those routine tasks exist in software development? Are there places where organizing to execute actually is the right thing?
Mon-Chaio: Absolutely. I mean, software encompasses so much these days, and for you and I, and I think a lot of folks that maybe work at, I don’t know what you would call it, the innovative software world, you, you may say, oh, well there’s nothing like that. But you know, I’ve seen, for example, contract organizations where they just have to replicate one widget to another customer, to another customer, to another customer, right.
To me, that’s very execution focused.
Andy: think it is execution focused, but I would say, this is the framing. I’ve actually tried to give teams that I’ve worked with. I would say that if on something like that, you find yourself saying, well, I just need to run the checklist. I just need to do it. You should actually still go at it with a framing mindset or a, a learning mindset.
Because we’re software developers, we automate things. If it is just the same thing again and again and again, that should probably be somewhere in our automation. So if we’re replicating that same widget to another customer well the things that are rote, it should be part of our product and automated the things that are not rote well, we’re now back in the learning frame, and it’s like talking to the customer and understanding their needs and figuring out how to get it to work for them and how to integrate it into their systems.
So, I would say in a lot of cases in software, if it is. A routine operation, we’re probably doing it wrong. What is your thought on that?
Mon-Chaio: I don’t know if I would say wrong. I would say different,
and I’ll use a different example from my from my experience and to sort of paint why I think it’s different and try to draw it back towards the routine situation. I think often when people talk about organizing for execution, they also mean this concept of, Hey, we’ve already agreed on what we’re gonna deliver.
Please don’t ask about it anymore.
Andy: Right. So kind of like a, a fixed known contract. You’re like, they’ve written the requirements document. They know that that’s what it needs to do. Don’t go back to them and ask anymore. This is, it’s been figured out.
Mon-Chaio: right. I was in actually a company where The right thing to do was something really innovative. We didn’t know the path
Andy: Mm-hmm.
Mon-Chaio: And what happened was these two senior engineers over time, they did a ton of really, really important work, ended up with a model about what they thought we should build in order to solve the problem that we had. There was another less senior engineer that did not agree with them and kept poking holes in their solution. What about this? This should actually be done this way. This isn’t actually modeled to the real world behaviors. And I would argue that after a few weeks of talking to this other engineer, the two senior engineers would’ve said if they had the vocabulary for it, look, we’re in execution mode.
Stop asking questions about this. Let’s just build it. And I think to the point connecting it back to these rote type of things, I would say a lot of the delivery managers or whatever would say, look, It’s great. You might be able to get 2%, 5%, 10% more effectiveness and build 10% better product, but that’s not what I care about.
I just care about as many widgets being pushed out as possible.
Andy: I would actually say that there is an important thing in that though. Which is that the very senior engineers believed very strongly that they knew what, what needed to happen. The product management around them, it sounds like, believed that they knew that this is all we need.
Mon-Chaio: Mm-hmm.
Andy: The thing that to me still puts it in, they’re probably actually still not fully organizing to execute, but they’re organizing to learn, or they need to,
Mon-Chaio: Mm-hmm.
Andy: is none of them have done it.
Mon-Chaio: Mm-hmm.
Andy: If they had done it before, that other senior engineer probably wouldn’t be asking those questions, wouldn’t be having those concerns.
That is one of the key criteria for me of when you’re executing versus learning. If you’ve done it before, you could be in the executing phase. But if you’ve never done it before, you’re learning, you have to be.
Mon-Chaio: Agreed. And you know, honestly I would agree in the example that I gave that was a learning environment. Those two felt it was an execution environment in no small part because they felt like we simply had to get a product out and that we may be able to iterate on that product.
Andy: They wanted to learn in a different fashion from the other engineer and I, and I think there’s the conversation they probably needed to have around like, no, no, we are learning, but we need to learn from feedback in a different place. You don’t have enough information for that feedback.
Mon-Chaio: Correct. I think one of the bigger challenges was also the system that they were proposing was large and a big radical shift. So the iterative development kind of locks you in a certain paradigm. And they were pretty certain that that was the right paradigm to build on top of.
And the other engineer did not think so. Right. So it’s a tough conversation to have at that point.
Andy: it is.
Mon-Chaio: But that’s why we’re having these conversations about, well, maybe we can figure out what they should have done and, and think about things like framing or think about things like failure and whatnot,
Andy: yeah. So that’s a bit of like the, there’s this organizing for execution, and there’s the Organizing for learning. So let’s get a bit into what is Organizing for Learning. We’ve said a bit of what it’s not, which is like, it’s not things that you’ve done before.
If you know exactly what you need to do, you probably shouldn’t do this. Just go and get it done. So the Organizing for Learning Amy Edmondson breaks down into four different aspects kind of what you need to do and how you can promote that as the organization. So one is framing for learning.
Another one is psychological safety. The third is learning to learn from failure. And the other one is crossing boundaries. And I think Mon-Chaio, this is a lot to go over. I’m, I’m, I’m kind of daunted already. There’s a lot here. And we were probably going to skim over psychological safety, not because it’s not important, but it’s so important that it kind of deserves its own discussion. There’s a lot to it. And it’s very central to how most of this will work.
Mon-Chaio: Right. And not just teaming, I would say even non teaming teams it’s so important.
Andy: Yeah. In fact, on that, on that team that you were just talking about with the two principal engineers, I’m, I’m gonna call them principal and the other one
senior,
There was, you can get a sense that there was some psychological safety on that team with the senior engineer raising these concerns.
Mon-Chaio: Right, right.
Andy: So that, that’s kind of why psychological safety is important for organizing to learn because it’s how you’ll gather new information to the whole group that only individuals hold.
Mon-Chaio: And I tend to think, you know, she presents it as these four things of which psychological safety is one of the four. I tend personally to think that psychological safety underpins everything. That if you don’t have that, none of the other three really work in any meaningful way.
Andy: Yes. Yeah. Because without, without psychological safety, the leadership’s framing of the situation won’t be questioned because people won’t think that they can ask questions about it.
Mon-Chaio: We have the three remaining pillars that we wanted to talk about, right?
Andy: So let’s just start and go through them and see where we get to. So start with framing to learn.
She had some key points about what leaders need to do to frame, to learn. Which is that to establish a learning frame
Oh, I should say, what is a frame, what is a framing? This is maybe jargon. I don’t know anymore. I’ve read too many of these things to know what’s jargon and what’s not.
So you can say that the framing of a situation is what we’re going to take is axiomatic.
Mon-Chaio: It’s the truth that we’re gonna all assume. Whether it’s objective truth or not, is I think less important.
Andy: Yeah. So the framing for Lear a learning frame, it’s that our axiomatic truth is that learning is important here. You might even say learning is paramount, but I don’t think she takes it that far. So the aspects of it is that the leader needs to set up the example that learning is part of their frame.
Mon-Chaio: Mm-hmm.
Andy: they need to set themselves up as not the expert. They are not the authority on the situation. So,
Mon-Chaio: Mm-hmm.
Andy: They need to make it clear that in order to succeed the group is interdependent. They all depend upon each other that everyone’s input is valued and needed to reach their goal.
Mon-Chaio: Mm-hmm.
Andy: And that their situation is challenging full of unknowns and an opportunity to try out new concepts.
And that they have a tacit goal no matter what their actual goal is, that their framing says that they have this tacit goal to learn as much as possible to figure out what to do next.
Mon-Chaio: Right.
Andy: And, and back to your example of the engineers who said, well, this is what we need to do. You could almost say that they both agreed that they needed to learn.
Both the principal engineers and that senior engineer, they both agreed that they were in a learning frame.
Mon-Chaio: Mm-hmm.
Andy: But they didn’t agree on what their next steps were yet.
Mon-Chaio: I actually think that she mentions for a learning frame there’s framing the leader’s role. There’s framing the team’s role and then framing the project’s role. And you mentioned specifically about what you have to do to frame the leader’s role,
right?
That
they’re not the expert. That they’re dependent on their team members for help and they will learn things from other people. You mentioned framing the team’s role around everyone is important for this project. You are not just executors, but you are collaborators with me. And of course, the project’s purpose, which I think you said really well in the example I gave, I think the leaders of that, those two, what you’re calling principle engineers versus the senior
engineer, right? Those two principle engineers absolutely set themselves up as we are the thought leaders.
Andy: Yeah.
Mon-Chaio: And so already we can see how their framing didn’t frame them for a learning mindset.
Andy: Yeah. And what they got was friction.
Mon-Chaio: Mm-hmm.
Andy: I would think that if they had gone into it and said, look, this is what we know so far.
Mon-Chaio: Mm-hmm.
Andy: These are the actions I think we need to take to get to the next bit of information we need.
Mon-Chaio: Mm-hmm.
Andy: The other engineer probably would’ve happily gone along with it.
Mon-Chaio: I think possibly, I mean, I think the senior engineer, the worry was that they were going through a one-way door with the implementation that they wanted to go
Andy: Mm. There’s no backing out.
Mon-Chaio: I think, and it’s, you know, with software, it’s very rarely no backing out, but we definitely know that once you establish sort of a data model, especially in a world where there’s a lot of manual work that has to be done to put data into this data model, right.
People aren’t gonna want to be like, oh, I just learned something new. So, you know, here’s another 300 hours of migrating data to a new
Andy: Yeah. Oh, you know how we said we don’t need the, the country code? Turns out we do. So can you just get that now?
Mon-Chaio: right.
Mon-Chaio: I mean, in this example, it’s more, it was more akin to we’re dividing up countries in this way, let’s say by states. And then all of a sudden it’s like, no, we’re dividing up countries by biomes. It’s like, okay, well I’ve divided my entire country by states it took so long.
Now you want me to like do ’em by biomes?
Andy: well that gets to an interesting thing about another aspect of the framing to learn, which was that. One of the things is that you want to actually set up your work as a trial.
Mon-Chaio: Mm-hmm.
Andy: And so it’s not to say that you want to ignore the cost of getting the new data, but you, you want to make sure that you understand if your trial’s wrong, what might you do?
Mon-Chaio: And it’s interesting, this example, the principal engineers, like I said, they did some great work. It was years of work talking to customers, thinking about the problem set, convincing people changing their architecture and whatnot, you know? Right. The senior engineer had not spent that long on it.
They hadn’t been there that long. And so I think for the principal engineers, they would say, look, we already learned the model we think is as correct as it’s gonna be. And so the learning now happens at a different stage. Right. We have to build the model to learn the rest of
it.
Andy: It now needs to, it needs contact with the enemy needs, contact with the, the market to, to find out
Mon-Chaio: And yeah, it’s a one-way door and yeah, it takes a long time to build, but like we gotta go through these steps before we can do this next level of learning.
Andy: Yeah. I would say from my experience, the question then to ask is, it takes a long time to build, which means if we’re wrong it will take a long time to try again. What can we do to reduce that?
Mon-Chaio: Mm-hmm.
Andy: And it, it could be that we say, well, this is what we’d have to do. Then you have to ask the answer the question, is it worth it?
Mon-Chaio: Absolutely.
Andy: And you might just say, you know what? It’s not worth it. If we have to do it, we have to do it, but at the moment, it doesn’t look like it’s gonna be worth it, so let’s, let’s not, and those engineers had probably gone through that calculation in their head. The other engineer just had, hadn’t experienced it and so didn’t believe it, and so needed to be brought along.
Mon-Chaio: And it’s interesting, you’ve experienced this with customers too, right? You get some engineers talking to a customer and they, they get to. Know the ins and outs and the customer tells ’em stuff and they come up with an implementation. Somebody completely fresh goes to the same customers.
Like, look, let’s think about it in a 180 degree way. The customer’s like, Ooh, that sounds good too.
Andy: yeah.
Mon-Chaio: So you know now what, right.
Andy: Now, now do both that are completely different.
Mon-Chaio: That’s right. That’s right. Oh, I don’t have a preference, but this thing seems slightly better. But we’ve already like spent a year talking about that other thing and like, that seems good. So one thing I want to touch on though is in the framing section of the book, she talked about the ideal employee.
Andy: was, yeah. I was just looking at that section in my screen.
Mon-Chaio: And I want to go down to the portion where she mentions that they’re suggesting provocatively, they say, That managers who want to build a learning organization must frame the ideal employee in their own minds and get ready to celebrate the disruptive questioner who simply won’t leave well enough alone.
What happens if you’re on a team of all disruptive questioners who won’t leave well enough alone? And what happens if you’re on a team of people who really just want to leave well enough alone, man.
Andy: I would say, One that would take us far out of the realm of the Organizing for Learning, which is a great place to go, but just not right now. And, but a teaser for it is two that what you do, at least in my experience, what you do is you train people on this. Most of us are brought up in a realm and most of our work experience is in a realm where the thinking is don’t ask questions, just execute as fast as you can get it done.
Your, your measure of success is how much output you have.
Mon-Chaio: Mm-hmm.
Andy: Now, that varies a bit. It’s not like a hundred percent true. What ends up happening in my experience is you put someone then into this environment where suddenly they’re being asked please speak up. Tell us about the problems you see,
Mon-Chaio: Mm-hmm.
Andy: they’re being told that person that you used to look to as the authority and that you deferred to them, don’t do that.
They don’t know. When you put someone into that situation, they’ll have one of those two reactions you just said. Either they’ll constantly ask or they’ll freeze and not ever ask. Now, some people will fall in the middle somewhere, which is really what you want but a lot of people won’t, and so then it turns into a thing she doesn’t get into, which is that a leader’s role, in my opinion, in this kind of an organization is a lot of coaching on communication and thinking.
Mon-Chaio: I mean, I think she does get into that.
Andy: She does, actually, I was, I was looking at the little bit that she does give on it, which is
Mon-Chaio: She talks about like reframing individual mindsets or whatnot, right? And coaching folks,
Andy: for individual reframing.
Mon-Chaio: right?
Andy: is to tell yourself that the project is different from anything you’ve done before. Yep.
And presents an exciting opportunity to try out new approaches and learn from them. Cool. So that’s to open yourself up so you don’t just shut down and never ask. It’s also to stop you from going into a depressive spiral, which can happen on these things because there’s no certainty.
Mon-Chaio: Well, you know, I, and I do think we’re getting a little off track, but an interesting part that I don’t think people talk enough about is, this idea of curiosity and questioning authority tends to be a very western concept at times.
Andy: Yes.
Mon-Chaio: so if you’ve grown up in a culture where it tends to be more communal, it tends to be more authoritatively driven I think you have challenges around the length and degree at which you can coach folks like that. I into being as. I don’t know what the word would call it. It’s not open-minded. It’s, it’s inquisitive. Maybe it’s challenging, disruptive maybe is the right word. As the authors would suggest that you need
Andy: Yeah, I would say that one of the framings to use is that it’s not disruptive, it’s actually desirable.
Mon-Chaio: mm-hmm.
Andy: Which is what she was getting at, is that there is this new desirable behavior, which even the western people are not actually that accustomed to,
to doing it productively.
Mon-Chaio: that’s right. Yes. What you see is you want disagreement up until the time that they’re tired of disagreement.
Right?
Andy: Yeah. Yeah. Disagree with me, but. Don’t cause me to have something that will have to change my mind.
What we’ve talked about are the things that if you think about this in terms of like forces, so one way that in the social sciences, you’d think about models of the way people behave or the way they think is you think about the things that happen.
The positive or negative effect that they’ll have on other stuff. So for instance, we were just saying that the leader frames things as that we are interdependent partners in an unknown challenge and we need to discover what to do next, that that is a positive influence on framing for learning.
Mon-Chaio: Mm-hmm.
Andy: Now, on the negative side, what are the things that are a negative influence on the framing for learning? We kind of touched on them, but I, I wanted to bring this back just to make it clear that there are these, these forces in play,
Mon-Chaio: Good point.
Andy: Which is the negative influence ends up being that there’s an expert who’s in charge.
That everyone is a subordinate of them, and we know what to do. They just need to do it. That reduces the framing for learning.
Let’s talk about how to learn from failure.
Mon-Chaio: It’s funny, I think these days as opposed to maybe 15 or 20 years ago, I don’t think anyone bats an eye from saying, oh, let’s learn from failure. Let’s fail fast.
Andy: I think it’s been normalized
Mon-Chaio: Exactly. I still do think that there’s interesting nuances around how you do that and maybe why it doesn’t happen as well as it should.
Andy: I think it’s one of those things. It’s really easy to stop it without intending to.
Mon-Chaio: Mm-hmm.
Andy: So for this, I think as an example, let’s start thinking about outages
software as a service. We’ll probably be talking about you’ve got teams with the kind of, you build it, you run it mandate and they have service outages.
They’re probably part of some big interconnected group of services that other teams run
Mon-Chaio: Mm-hmm.
Andy: and something will go wrong,
Mon-Chaio: Mm-hmm.
Andy: something will always go wrong.
It’s inevitable. But actually that thinking is part of how you promote learning from failure.
Mon-Chaio: right?
Andy: One of the ways you stop learning from failure is if you say failure is not an option, your service can’t go down.
That was terrible. If it went down, there’s a mistake Somewhere,
Mon-Chaio: Right. So.
Andy: someone is at fault. In fact, bringing that back to the book a little bit one of the things she says is that a problem with learning from failure is that quite often we end up putting failure and fault as inseparable. That to have a failure, there had to have been a fault.
Mon-Chaio: Mm-hmm.
Andy: And also to have a fault means that there has to have been a failure somewhere.
Mon-Chaio: It’s interesting that mentioned that, if you think about fault as just an event, like a cause and effect event, yes, every failure has a cause. And so you can call that a fault. One of the highest value things I got out of these 300 pages was a half page chart in this section.
Andy: Is this going to be the praiseworthy and blame worthy chart?
Mon-Chaio: Absolutely.
Andy: I love that chart. I use it so much when I do incident investigations that idea of praiseworthy and blameworthy.
Mon-Chaio: Unfortunately we are on an audio podcast, so maybe we’ll paste it in the show notes, I think might be a good thing. Cuz I don’t wanna read through the whole chart. There’s a lot of words on it. But there’s a spectrum between praiseworthy and blameworthy. And I actually don’t like her use of the word praiseworthy.
Right. To me I kind of like the word that you used before because I think using it makes it less blameworthy, and I call it fault, I would call it a spectrum of fault. And so at the top of what you might call fixable or poorer faults are things like deviance, right? An individual chooses to violate a prescribed process. Okay. That’s not great.
Andy: Key word in that is They choose.
Mon-Chaio: They
chose right. Or inattention. This idea that, oh, I wasn’t paying attention and something failed because of that. And in the middle there’s stuff like process complexity. Ooh, interesting. All of a sudden a process is so complex that we can’t help but have outages and that can cause faults and then all the way to the bottom of like exploratory testing, right?
You can have failures because you were exploring something and it didn’t go the way you wanted it to.
Andy: So, I’m actually gonna defend her terminology
Andy: because I think it’s important for what she wants to do,
Mon-Chaio: Okay.
Andy: Blameworthy things are things that actually you should call it out as bad behavior but the blame worthy is very few. In fact, she says later on where you’d switch from praiseworthy blame worthy is very blurry.
But most people would say there’s very few actually blame worthy failures. Cuz these are failures, not faults.
Mon-Chaio: Right.
Andy: And this is how you get the separation of failure and fault. So deviance of a prescribed process where someone chooses to deviate from a known process. So let’s talk about an outage. Someone chooses to deviate from how you should release your software.
Say you have a ci cd pipeline part of your steps is deployment out and someone says, you know what? I’m just going to log into AWS console. I’m gonna change this reference to have my lambda load from this other location, the S3 bucket, it all fine. I’m just trying this thing out.
And then it all blows up.
Mon-Chaio: Mm-hmm.
Andy: That’s deviance from your procedures. That is a blame worthy thing. Now, this is also where it gets complex. Perhaps they were doing that for hypothesis testing.
Mon-Chaio: Right.
Andy: So now from the standpoint of trying to learn from failure, they were trying to do something very good. They were trying to actively test and get a failed hypothesis to learn from it.
And that’s praiseworthy. You want that kind of behavior. So now in your incident, in your outage, you’ve got both a blame worthy behavior and a praiseworthy behavior.
Mon-Chaio: Yes. Here’s another part of that that I often ran into. Let me give you an example. Are in an outage discussion, right? Doing a retrospective on why the outage happened.
Andy: Okay?
Mon-Chaio: And initial thought from leaders watching the outage was I’m gonna use one of her terms, lack of ability.
So that’s number three from the top of Blameworthy.
And I think most people would say lack of ability is blameworthy in some way,
right? So is this concept of, oh, well you didn’t code review, or like the code you wrote was insufficient. Now that we know what we know, it seems like a very clearly insufficient thing where you should have just done X,
Andy: Yep. That I, I will point out that is a hindsight bias.
Mon-Chaio: mm-hmm
Andy: that’s like 2020 hindsight. You can point that out.
Mon-Chaio: mm-hmm.
Andy: Yep.
Mon-Chaio: Exactly. Like some of the most complicated things that you would never known have, like the simplest solutions,
right? Like,
Andy: Yeah.
Mon-Chaio: just switch a one to a zero, and
people are like,
Andy: After the fact, once you see the impact, you’re like, oh, of course that’s what you had to do. Oh.
Mon-Chaio: So what happened here these retrospectives were intended to be blameworthy. And so of, you know, blaming and saying, Hey, it was a lack of ability, it was other words being used, right? Well, it seems like a pretty simple change. Can we just change the code review process to catch it, et cetera, et cetera.
And what it caused is this entire tax, I would say it caused maybe 25 hours of work of cycling. And so what happened was people were like, okay, well that’s not exactly how it was. The leader’s like, well, why don’t you write up sort of a, you know, your explanation of how it went. And so they went, wrote it up, and the leaders were like, okay, but still sounds like we need, like a code review process would’ve caught this.
And it’s like, oh, well, you know, there were these nuances here. And, well what were the nuances? And in the end, after 25 hours, there was this 11 page document. Of like, oh, I talked to this person on this date, and then they said this, which made me think this. And then I went over here to explore this person.
I can’t remember exactly what they said. I asked them, but they couldn’t remember either.
Andy: Basically what’s
happening is the, manager is saying defend thyself.
Mon-Chaio: Right? They’re like, I want to, I want to be on the praiseworthy side, but I can’t, my head doesn’t let me get
there.
Andy: Yeah. And I would say, so going back to the kind of like forces of what increases learning from failure and what decreases learning from failure, she made a point that I thought was really good. And it’s a term I’ve used and learned, which is advocacy and inquiry.
Now, I learned it as you want to balance advocacy and inquiry. But she points out that to promote learning from failure, you wanna promote inquiry to demote, learning from failure, you wanna promote advocacy. And what was happening in that was basically that manager, it sounds like was advocating, this is the issue, this is what went wrong, and I’m going to advocate for that.
Mon-Chaio: Mm-hmm.
Andy: And the reaction is that they’re not learning from the failure because they can’t feel like they’re doing a true inquiry into what happened. Does that, does that
Mon-Chaio: It, it fits in a little bit because I think from the outside you can ascribe that behavior to the manager knowing that manager from, or that leader, let’s call it a little leader, right. Knowing that leader, from what I’ve seen of them before, they wanted to understand.
Andy: Quite often that person might want to understand, but they go about it in a way that creates defenses that degrade that. And I think that’s actually a really key thing in a lot of these behaviors
Mon-Chaio: Mm-hmm.
Andy: is that you may use the behavior, but that’s not your intention.
Mon-Chaio: I’d be curious in your point of view, Andy, then, what should that leader have done? Right? So, assume you’re that leader and you are in the trust, but verify mode, right?
So you’re saying, look, Y’all have what you think, but my job as a leader is to ask the right questions, push you, right? So that if there’s something you weren’t thinking about, I’m here to push you and to obviously put my own thoughts and ideas around it, around my own experience.
Andy: Mm-hmm.
Mon-Chaio: so as you listen, the explanations don’t jive in your own mind, right?
So you ask, well, okay, that could make sense, but I still don’t get it. And then, you know, you get to explain, I still don’t get it. Should that leader have just said, look, okay, I trust you all in your explanation. Or should they have continued to push?
Andy: It’s difficult to say cuz I don’t know the context and I’ll say context matters. And I’ll actually bring it back to the book really fast about why context matters, because learning from failure is different depending on the kind of activity that was happening. She makes a distinction between routine, complex and innovative activities In a routine activity.
It’s very much about the kind of like deviation you should have set. Procedures and deviation is the thing you’re looking for
Mon-Chaio: Yep.
Andy: in a complex activity. An innovative activity are gonna be fairly similar. It’s going to be about what was their approach and their thinking and how they navigated that.
So one of the things in this case would be, are we dealing with a routine activity or a complex activity or an innovative activity? Most likely it’s some sort of complex activity that’s what most software development is. It’s not the kind of thing where we can say, this is exactly what we need.
This is, we’ve done it 20,000 times before.
Mon-Chaio: right.
Andy: Now the thing that that person needed to do and they might have been trying to do this, was to pay attention to, is their advocacy increasing or decreasing the inquiry of the others? So as the leader, they wanna set up that model of how to go about this.
Mon-Chaio: Right?
Andy: And people need to see that that leader is doing hypothesis testing
Mon-Chaio: That’s right.
Andy: and talking about it in that fashion.
It could be this, what would tell us that that’s incorrect? Because you can’t tell us what tells us that it’s correct. If you know a bit about scientific thinking, it’s what tells us that this hypothesis is wrong,
and how can we find that? Well, then that becomes a question of how do you know or how would that not be true?
Mon-Chaio: Mm-hmm.
Andy: So it will sound like almost entirely inquiry. But it has to be interspersed with a bit of advocacy for. The other hypotheses to check.
Mon-Chaio: Mm-hmm.
Andy: It is difficult having done a whole bunch of these kind of incident analyses because you do sometimes get caught on like, well, this is what happened.
That’s just what was wrong. This person was just wrong. They pushed out untested code and that’s just irresponsible. Okay, but why did they push out on tested code? These guys don’t normally do that. So what happened in this case? How did that happen? I have a case where we pushed out on tested code and it happened because they had copy and pasted after testing,
Mon-Chaio: Ooh.
Andy: than copying the file, they copied the code
Mon-Chaio: Oh
Andy: and they had missed a line
Mon-Chaio: Mm-hmm.
Andy: and they pasted that code into the other terminal to run it.
Mon-Chaio: Mm-hmm.
Andy: And it was missing a line. So, is that praiseworthy? Is that blame worthy? Where do we go with this? And basically the thing was is they didn’t have a good mechanism for rolling that one script change out. And so they were relying on well copy and
Mon-Chaio: Copy paste, right. Process complexity, I would say
Andy: Yeah. Yeah. So in that case, my manager was very much on the advocacy side of these guys are irresponsible.
Mon-Chaio: Mm.
Andy: And I had to push back and be like, you may be right. But that’s not helping us learn and not helping them learn. They’re just feeling really bad about this. So let’s back off. Let’s go to the inquiry. Let’s ask for accountability of the actions.
Mon-Chaio: Mm-hmm.
Andy: And that’s the uncomfortable thing in a lot of these cases is asking for that account of what exactly happened, which it sounds like they eventually had to do, but they weren’t happy with doing it.
That is actually the really valuable activity. But they didn’t believe it was valuable because they probably felt that they were being forced into this rather than being like, let’s actually explain this to ourselves.
Mon-Chaio: Well, I think they knew it implicitly, right? When you go through an experience. You tend to feel like you know what happened. Could be wrong. A lot of times you’re wrong. In this case, they happened to be right.
Andy: Yeah. And that’s the leader’s job though, is to pull out, tease out. Not that they believe that they’re right or wrong, but that everyone else can see how it played out.
Mon-Chaio: Absolutely.
Andy: I think we should move on from failure. We still have to do crossing boundaries.
Mon-Chaio: Exactly.
Oh my
Andy: Oh my God.
Mon-Chaio: I told you it too big, man.
Andy: Oh, what have we done? What have I done? So, yeah, you should cross boundaries. It’s good.
Mon-Chaio: Yeah, it’s super easy, right? Knowledge stores, getting people there in person and you know, regular kickoff meetings. So I think that’s crossing boundaries right there,
Andy: shareable artifacts explicit invitation to cross the boundaries and find water cooler opportunities. There we go. That’s crossing boundaries.
Mon-Chaio: We apologize. We talked about that this might be too much. We knew it was gonna be slightly long and yet we decided to proceed down this route anyway.
Andy: Yep, we have learned from failure. Or maybe this isn’t failure. Maybe this hypothesis will test. And we’ll find support that people want us to ramble for an hour.
Mon-Chaio: well, Andy, it’s certainly blame worthy behavior. I am. I’m all the way up on the blame charts .
Since this is so long, let’s do a quick refresher on
Andy: What, what are we talking about?
Mon-Chaio: Right, this concept of boundaries, right? So again we’re talking about creating a learning framework we’ve talked about how to change your mental framework. We’ve talked about how important it is to learn to fail and how failure’s a key part of that. And then I think the last thing around boundaries is how to cross boundaries. Because boundaries inhibit learning, I think is what Edmundson would say, right?
Andy: Yeah. And boundaries inhibit learning because they, they compartmentalize knowledge.
Mon-Chaio: Mm-hmm.
Andy: And so a very important thing is to pay attention to where the knowledge of your organization can get to.
Mon-Chaio: Mm-hmm.
Andy: So she has multiple examples of water cooler conversations where just talking around the water cooler, someone says, oh yeah, I have that chemical you need.
And then suddenly an entire project can go forward. Cuz they couldn’t source the chemical before.
Mon-Chaio: Right. And she, and she breaks it down into three types of boundaries. I think. I don’t know that I necessarily agree with her, especially coming when we discuss Bart, there’s all sorts of boundaries. Right. But
Andy: there’s all sorts. I, I took it as her saying, these are the three boundaries that she’s seen show up again and again and again as important for organizing to learn.
Mon-Chaio: And what do you think, do we want to touch on those three? Are there one specific one we want to deep dive into more? Or do we kind of want to just talk about crossing boundaries in general?
Andy: Well, I think at least going through what the three are is important. So her three boundaries are, Physical distance status. So this is like someone has a management authority over a group or,
or a PhD versus people who don’t. So something that you look up to and you say, that person has more authority than I do.
Mon-Chaio: absolutely.
Andy: And knowledge boundaries and knowledge boundaries are your different disciplines, your different companies, your different departments within the company your different offices
Mon-Chaio: Right. And she, mostly has worked with hospital teams and so for her, I think knowledge boundary is very much around like nurses versus radiologists
Andy: Yeah. Yeah. In software. We see this a lot with software developers versus UX researchers versus infrastructure engineers. I am not gonna call them DevOps security engineers. Like we have multiple knowledge boundaries.
Mon-Chaio: Right.
Andy: and so I would say well, of course you need to cross these boundaries to learn.
Just thinking about it in terms of an outage let’s go back to that outage situation and outage. And you’ve got the developers who are looking at their code. We know this happens all the time. You’ve got the developer looking at their code, the error logs that are coming in from their code, and they’re like, everything works just fine.
But the site is down and the infrastructure engineer is looking at the system logs and they’re looking at the CPU and memory usage stats and all of that, and they’re like, everything is just fine. Then they talk to each other and they realize, oh, actually this service isn’t able to communicate with this service.
Mon-Chaio: Mm-hmm.
Andy: That’s what this failure has to be, and it can’t communicate because there’s a firewall rule. And that got put in place at one time, and then the service never retried because of a bug in the code. Now suddenly that’s what’s going on. So that kind of like crossing the boundaries is important in creating a learning organization or organizing to learn.
Mon-Chaio: Right
Andy: and going back to the forces, what promotes it and what inhibits it one of the forces was if you actually make those boundaries so strong that people can’t cross them,
Mon-Chaio: right.
Andy: So like your, team identity is so strong that you’re like, we won’t talk to them because they’re the, they’re the others don’t
Mon-Chaio: Mm-hmm. They’re the front end UI engineers. What do I need to talk to them
Andy: Yeah. I don’t even understand a word. They say
Mon-Chaio: That’s right. React
And
Andy: And what, what, what are they like, just, just tell me about Java libraries. And another one, and actually I think this one is quite interesting. She kind of brought it up was chatter. I don’t think she said it in so many words, but one of the things I lifted from what she was saying, and maybe disagree with me, Mon-Chaio was just general chatter is
needed.
People just sending information around not transactionally, but radiating information out was needed.
So,
Mon-Chaio: Yeah. Obviously I don’t disagree with you on this. We’ve talked you know, not on podcasts, but just quite a bit in conversation around how that’s missing in our current working lives these days.
Andy: I thought neither of us were working right now.
Mon-Chaio: Okay. In our, in our current slash not so current working lives, You know, a year ago.
Andy: Yes.
Mon-Chaio: but yeah, what I call serendipitous interaction
Andy: yeah. What Alistair Coburn called information radiation? The serendipitous stuff where you’re just, you’re, you’re overhearing the person in the next desk talking about something. And
Mon-Chaio: Absolutely.
Andy: And we haven’t found a good way of getting that, as far as I know in remote work.
Mon-Chaio: I can certainly say I’ve tried a number of things and Edmondson will talk about some things that probably you and I and a lot of other people have all tried in order to promote that. And I don’t disagree with her about things like, oh, well, you know, you wanna fly teams to be together.
You want to gather teams for kickoff meetings. You want to have a funny story shared at the end of every meeting about some person personally. But I think while better than nothing, the benefits are so sparse. You can’t, you can’t put a percentage on this, right?
But , just throwing a number in there, I don’t even think they reach 2% of what it’s like when you overhear conversations next to people. So that’s for another discussion. For sure. There’s a big, long discussion about that. But
Andy: Yeah. And I think it’s a big question. I don’t want to say that the remote working doesn’t work, and I don’t wanna say that in person is the only way to go. But there are struggles. The struggle is real.
Mon-Chaio: Well, and I think the, the important thing is not to say it doesn’t work, right. I think the way that I think about it’s all about trade-offs.
What I worry about is people are putting blinders to some of the trade-offs instead of explicitly acknowledging them.
Andy: I would say to one of the things of organizing to learn, if you can’t acknowledge that, that’s one of your challenges, you’re, you’re not gonna be able to learn to overcome them.
Mon-Chaio: Mm-hmm.
Andy: And so I think acknowledging it, stating it makes it something that now you as a group can work and learn to get better at.
Mon-Chaio: Right. Makes sense.
Andy: So I think that was a very quick crossing boundaries, but I think that’s covered
it.
Mon-Chaio: I had a,
I
had
Andy: have something?
Mon-Chaio: thing. Yeah. Which really came to my mind was she talks a lot about these things like gathering people together, knowledge stores, right? Water cooler conversations, chatter. I’m gonna bring back what I brought up, during the the failures thing, which is that’s a lot of work.
Andy: yes.
Mon-Chaio: And so again, it’s explicitly a trade off, right? In my opinion, the more you can make crossing boundaries not have to happen in order to get optimal results, the more you should. You can’t make it a hundred percent. Absolutely not. You can’t even make it 90%. But that tax is not zero
and you need to acknowledge that tax and you need to acknowledge that perhaps by making stronger boundaries in some senses and containing work within a boundary, say, oh, the London team is responsible for the sales website and everything to do with sales versus like backend inventories done in New York or whatever. I think you should strongly consider that because the tax is non-zero.
Andy: I think you should absolutely consider it. And so I’m gonna do a yes and yes, you should absolutely consider it. And you should also consider what can you do to still invest in that cross boundary
stuff.
Mon-Chaio: yes.
Andy: So yes, set those strong boundaries where you’re like, the primary task that everyone has can be done without having to constantly cross boundaries.
Mon-Chaio: Right?
Andy: Although I think Amy Edmondson, just to be clear, would say that they are gonna be crossing boundaries all the time for knowledge.
Mon-Chaio: Mm-hmm.
Andy: Because they’re gonna be cross-functional teams and that is a crossing boundary. And they are gonna be crossing boundaries for status cuz you do want that, where they’re questioning their leads and, and all of that.
So you do want that, but I think you’re talking about one kind of organizational structure interrupting another organizational structure to try to figure that out. And you do wanna minimize those interruptions, but you don’t want to get rid of them. You’re gonna try to minimize them, but you want to still promote that they’re happening.
Mon-Chaio: Yep. And that’s exactly it, right? It’s not gonna be 0%. don’t want it to be. 60% of the time, but whatever percent of the time, because it has so much tax, you gotta get better and better at it. so you need to train yourself and develop the skills so that when you do cross the boundaries, it is smooth.
Andy: All right. I have no idea how long the episode is gonna be by the time we’re done editing this. I hope that it was good for everyone listening. I hope that it made sense. I actually learned a lot from this, and I, I really enjoyed talking to you about this, Mon-Chaio.
I think going into it, I believe that you and I were on completely different pages about this stuff, but I think we once again agree on more than I thought.
Mon-Chaio: Yeah. I actually thought that this might be an episode where he had a little more back and forth and disagreement. Unfortunately it wasn’t this, we’ll have to try to make it some other episode. But let us know how you all felt about it. This was the first one where we did something much larger than, you know, a two or three page paper.
It’s difficult. There’s a lot of topics, right? We tried to constrain it down. It ran a little long. Was it too much? Were the concepts too muddled because they were only parts of a bigger hole? Let us know what you think.
Okay, Andy, let’s cut it here. Good chatting with you. I don’t know what our next episode’s gonna be, but I’m sure it’ll be fun. Nonetheless. So see you in about a week, I guess.
Andy: see you in about a week.
Leave a Reply