You've just watched two meetings. The first one takes place about three weeks before the second one. This is a team that's working quite differently than most of the other scenarios that we've shown you. They are very effective and quite productive. Some of the things that they're doing that we want to highlight is that they have quite a bit of flexibility. They're thinking about issues in different ways. They're working together. You've noticed that, even though one of their members is remote, that they are incorporating him, including wanting him to be at the company picnic. So there's an aspect of inclusion. They're also thinking about how they can experiment, how they can test things out. So we're going to unpack that a little more for you. But first, we want to refer back to Alan's talking before about complex adaptive systems and the different kinds of issues that come up. And I think in both these meetings, you saw some simple problems that have recurred and that they're able to address pretty easily and readily. They have a formula or a format for doing that. You saw some complicated problems and you saw some complex ones. So, Rami, I'd like to ask you to start us off on unpacking it. Sure. First let me say that watching this team meeting was very energizing. Yes. A good team. Good team, listening to each other, open to each other's ideas. So one thing that struck me in what Alan spoke earlier and what you just mentioned about complex adaptive systems is the aspect of unpredictability. And we do see this in this scenario as well in terms of the client environment. So they are developing a CRM application, customer relationship management application, and they have a UAT coming up. They have deadlines and one software manager asserts that, "We have already done our due diligence. We don't have to do anything right now." But the other person identifies the unpredictability which is here, the client systems. They have no control on what kind of upgrades or what kind of changes that happen in the client system. Neither are they in control nor can they easily predict it without probably being in touch with them. So I think that part struck to me as you know how this entire situation unpacks where they identify this, and they're not shut down. The person who identifies this is not shut down or blamed. But there is a little safe space created, and we are going to talk about it more. Safe space is created for each one of them to come up with what they think their perspective is, and I think in general that enriched the conversation and helped them be more effective or productive. It's interesting that you brought up UAT and CRM. UAT, these are terms, user acceptance test and, what was that? Customer relationship management. You know, at all these levels look at how the conversations are unfolding. You cannot predict how these conversations are going to go and you know, Alan, it reminds me of the Mark Twain quote you have right at the entrance of the door, and I'm trying to recall that. "It's not what you don't know that gets you in trouble, it's what you know for sure that just ain't so." But you know, how definite you are that you don't know, or you know about what you don't know, that gets us in trouble. And if you look at those two conversations, and I'm keen to hear what both of you are thinking about how the teams were reacting and responding to it. Well, one thought is this team, which I agree is very productive, very effective, recognized that the customer system isn't static. It's changing. There's upgrades happening. And so rather than blaming the customers saying,"No, hey, that's not the specifications we were told." Right. They're adapting to that. They're resilient, they're flexible in the face of that. They're saying, "Ah, that's the world we live in. And yeah, some of this is a problem that maybe isn't simple; it's complicated." Software development is complicated. There's a lot of moving parts. So they're at least aware of that, saying we need more information. Someone needs to check what's the latest situation. We'll have to adapt and we want to do trial runs. These these are important things that demonstrate their ability to handle complicated problems. I think they're doing it very well. I would just reinforce that. I was very impressed that after meeting with the client they said there are lots of things that need to change. And so we need to adapt, as you said. And I thought it was a great illustration of them thinking systemically, something we've talked about throughout, but especially in module one, and that is that what happens in one part of the system impacts other parts of the system. It's not isolated or alone. And I thought they showed a good understanding of that, which many organizations or teams don't. They would like to say, "Well, we've worked, we stayed up all night for many nights and we figured it out. We don't want anyone to disturb it or change it." Of course, the next morning it always changes. It also speaks to some points that we touched on in module three, of diffusion. Your idea versus my idea, hoarding of knowledge. So it's very refreshing to see that this organization has invested in a very robust communication management system, a repository where they capture what they're doing in the past, what went well, what didn't go well. And that really comes of help when, you know, this team in particular, they had some great access to learn from their past mistakes, not come at the same mistakes again and again, but learn from their past mistakes and see what has been done about it in the past that we can apply now. So there is a past orientation. There's also a future orientation of how do we apply what we learned in the past. Oh absolutely. Everything about this meeting was very future-focused. And just by the function of being future focused, there are going to be variables we don't know. I love the fact that they talked about the knowledge management repository. Well, that's a perfect tool for a complicated situation. Somebody's been here before; we can learn. They have something to offer, expertise knowledge, confidence, and we need to access that. They do that. And OK, customers upgrade their systems and it's a moving target. But what exactly they did, even though we know they do that, that's an emergent problem. We have to go discover what their changes are because no two customers will be the same. So there is an emergent problem there. It's unknown. They have to go gather more information. This is the perfect design spiral of what's going on, here's what we think, let's test it out. By talking with them we realize there are some new things we need to adapt and reconsider that. It's anticipated that that's going to happen. It's not like it's a rework or, "Oh no. Now we've got to go back." No, it's part of the process, and they frame it that way, and they therefore aren't frustrated with it. They're making progress, and they know that. Another way that they were prepared for it is that they had a budget for doing the testing, right? So I think is a great example that there's lots of things you can't prepare for, but there are some things that you can, and that will facilitate your ability to cope with the changes. You know, it's interesting that you said that, Dana. And Alan and Rami, we were talking a few modules earlier and you may remember it just as well, is how we chose to have a conversation about having a conversation on teams, and we made you a part of that. And we knew that there are these learning objectives. We knew that there at the structure that we are following that we are moving from individual team and to organization. And our conversation has also been emergent in many ways. Your input, your reflections, are also emergent. You knew there was a structure; there is a fundamental way of learning. But look at the way our journey has so far evolved from module one to module two, three, and now we're on the fourth one. There are so many ways of applying and we promised you that we will apply what we are sitting and talking here. And this scenario, the de-brief, the way you are a part of this conversation, the way we're deconstructing, I'm sure you've made your notes, too. But Alan, you were onto a certain thought that you wanted to share something. Yeah, the last point, in terms of this being emergent self-organizing, is notice at the end of the second meeting, it's recommended that a technical expert be brought in. Adding somebody new, bringing in yet another voice to create additional difference brought into the container so that they can make sure that they are considering this from all perspectives. That would be a real roadblock to many teams that I have been part of, but the fact that all of a sudden they're receptive to, "Hey, there's maybe another point of view here we need to add." So, whether that's a good example of complicated or complex, I'll leave that up to you. But it's about being flexible and resilient, even as to who's on the team.
