Ep. 106: When Collaboration Breaks Down

Peter: 0:05

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello and welcome to another exciting episode of Definitely, Maybe Agile with your hosts, Peter Maddison and David Sharrock. How are you today, Dave?

‍Dave: 0:21

Excellent. I was just going to say I'm looking at the video and all of us just getting going on this. I don't think I've seen both of us smiling and glowing, as it were, from the recent breaks that we've had a bit of time. R&r is well deserved and it certainly served its purpose, I think.

Peter: 0:38

Yeah, a bit of vacation. You need something Just a time away. Turn off all of those distractions and notifications and just relax with friends and family.

Dave: 0:46

Exactly, exactly. So what are we talking about today?

Peter: 0:50

There's an interesting article that I came across. It's a couple years old, but it's about, from 2021, and about when collaboration breaks down, and what was interesting about it was that it took an ONA organizational network analysis type approach and it talked about it both from a sort of how these sort of problems come about, but also some of the models that we talk about a lot and how those sort of interact with this as well. So I thought it was an interesting article to discuss, and there was sort of dysfunctions that they have and we're not necessarily going to walk through all of them, but I thought it'd be a good conversation for us today.

Dave: 1:29

And I think we talk about collaboration all the time. I really liked the article. I think it was very, very familiar to a lot of the challenges that we've talked about and getting change in an organization and I think it highlights and it puts a lot of terminology to some of those things and suggests one or two of the solutions that come through which I think are completely in line with many of the conversations we've had. Maybe, if I just kick things off, because there's the one that we're all familiar with, and this is collaboration breaking down basically because of you can call it command and control, hub and spoke. But the idea that there's one individual somewhere who is calling all the shots, whether it's micromanaging a team, whether it's, for whatever reason, good or bad, stuck in a place where every decision has to go through that individual and clearly, as a starting point, that's not very collaborative. It's accidental in many situations. I think it's a home base that people fall into, but it's certainly a place or it may be just the structure of the organization is such that I mean I've worked with organizations where investments over a very small amount have to go through committee of some sort, which means you're effectively in a hub and spoke model and unable to collaborate and move and have autonomy. That's necessary.

Peter: 2:40

I was thinking, as you were saying that, about that. This also happens just within organizations, especially within technical organizations, where there's a single expert and nothing can be done without that expert, and they're saying so in if you look at something like DevOps and the Phoenix project, that had Brent right, but the nothing could be done without that person, and so it was the everything has to go through them because they're the only person who has the sufficient knowledge of the technical details of the system to be able to make changes without everybody else, and sort of everyone else is too scared to do so. So they you end up with this hub and spoke network around that as well.

Dave: 3:19

And in the article itself there's a great introduction where it's explaining just kind of a nod to the fact that organizations are more and more moving towards highly collaborative. You know, fewer layers of management, much more sort of whether it's, you know, an agile type of approach that we've often discussed, but it's something which is much more collaborative, much less functionally siloed and in some ways the hub and spoke is the we're still thinking in the old functionally siloed world and yet we're trying to be collaborative but we've not really been able to put the structures in place so that collaboration is really happening. So you end up with these individuals, let's say, at the boundaries, where where decisions have to be made, where collaboration could be happening and it isn't happening.

Peter: 4:02

Yeah, exactly, and so being able to and that's a great example is the distribution of that accountability and the million, so it doesn't have to come through that one person. And it's happens like, how do we spread out that knowledge, how do we spread out the and impact able to be able to make the decisions as they're closer to the problem and so they can make the decision faster because they have more information and they can see it more clearly than we can from a centralized point of view.

Dave: 4:29

Well, I feel that there's a really like fundamental point to be made there, which is in the sort of the old world that we keep referring to this previous place, where organizations optimized around functional capabilities whatever those functional capabilities marketing, development, testing, whatever it might be the effort or the role of management, if you like, is actually managing those boundaries. And so this is where you end up with that Hub and Smoke spoke model, because one simple way of managing the boundary is, when something crosses the boundary, make sure you come and talk to me first. And so now we've got that boundary piece like almost like a border role between two different countries right. There's that role there and we spend a lot of time getting that role defined. What's interesting from a collaborative approach is we need to dissolve that role. We need to dissolve that boundary. The boundary has to be something that, if you and I are either sides of that boundary, we can reach agreement as to how things can go backwards and forwards across the boundary without involving layers and layers of authority and hierarchy in that conversation. And that's a fundamental shift. It means and it comes out really nicely in the article it means a clarity around roles and, specifically, decision rights, because you and I, trying to cross that boundary, have a conversation across that boundary. We have to feel confident to be able to make decisions where both sides of this would go. Yep, this is the right thing to do right now for where we are today.

Peter: 6:01

And I think actually one of the other model or the other dysfunctions that came across is also related to that where you have that conversation across those boundaries and everybody agrees, nods their heads, leaves the room and goes and does something else completely different, which leads you to the misalignment which, in turn, creates distrust and as people are like, hey, well, I'm going to go my way and you're going to go your way. And so once you start to have all these notes run off on their own and start to act more independently, you still need to have the common understanding of where are we all going. What are we trying to achieve together as an organization? We've talked about this somewhat, but, like we talk about things in terms of autonomous units, but it's not truly completely autonomous, because there has to be some kind of common understanding of what is our direction.

Dave: 6:53

Yeah, it's like the true North we all have to agree what the end goal is, and it's not maybe as simple as a true North, because that can be some sort of big, hairy, audacious thing that we're aiming for, but it's more a case of the activities that we're doing now. What is the end goal? And those end goals have to span those different units which are collaborating. So this is we talk about this all the time in terms of alignment around priorities, alignment around incentives and transparency into what's going on. All of those is about facilitating collaboration, because now, when you and I discuss and collaborate over something, we're sharing priorities, we're sharing incentives and we're sharing information transparently so that we can have an open, useful conversation. Yeah, exactly.

Peter: 7:37

I think that. I think, then, some of the some of the other sort of dysfunctions they were talking about included, where nodes end up getting overwhelmed, where there's too much gets created and because of collaboration right, there isn't, because there isn't sufficient collaboration going on. Nodes get overwhelmed because they feel like they have to take everything onto themselves, and or they end up backing away from collaborating with others because they don't want to be the person who gets burdened with doing yet another piece of work, because they've already got too much work on their plate as it is. And so you end up in these situations where collaboration breaks down as a consequence of this.

Dave: 8:17

Yeah, I was just going, as you're describing that, peter, I'm thinking work transparency. Right, that's a capacity management problem and one of the big differences in a siloed, sort of functionally siloed organization, that that's that old world that I keep referring to. Capacity is driven by functions. So I don't need to think about, you know, effectively I'm going to have cues between the different functions. That's the way we handle capacity and we do the work I have to hear build a cue into the next one. If they have the capacity, they'll take it on, if they don't, they don't. But we get. You know, we don't need to worry too much about that. That goes away when speed time to market is a dominant driver, because now those cues and those, those capacity constraints really begin exposing themselves. So in that collaborative piece, work transparency, capacity management becomes a whole organization challenge, not an individual function challenge, which is obviously much more complex, much harder to do, and you actually end up in that to start looking at the goal and we start looking at constraints and you know theory of constraints and how to look at where the blockages are and recognize the impact my group has on your group, which is not a conversation you normally would be worried so much about.

Peter: 9:31

Systems thinking, thinking of the system as a whole and looking at it end to end. It's the DevOps is the the colloquial term. Now, of course, we get into the conversation about how far do you take DevOps conversation, I think it was.

Dave: 9:48

So it's so interesting because this article sort of touched on all of these little things about these core principles that we talk about, so we've sort of broken out sort of three of them just coming through. What I really also enjoyed about the article is there's the kind of traditional consulting approach of we're going to redesign how your organization works together. Well, collaboration doesn't come about just from redesigning how teams are structured we're going to look at roles, responsibilities. We look at decision making rights important but not sufficient to drive collaboration and I think what's interesting as I look through that article and what it's talking about is it's that bringing together of you. You need to understand both the sort of structure, organizational kind of environment that's been worked on roles, responsibilities, decision making rights and autonomy, how to empower teams and so on, how to structure things. But you also have to look at the people side of things and understand behavioral aspects to it incentives, overload, disenfranchised, and engagement as a result of disenfranchised, if they're kind of left to one side or out of the communication loop or whatever it might be.

Peter: 10:55

Yeah, and this piece there of here's a set of models to look for. If you start to see these things, this might be what's happening. I quite like that sort of the reverse view of this, that it's giving you a set of ideas of where I'm seeing these problems. These things are happening. Do I have areas of my organization that are disenfranchised? Do I have areas of my organization that are simply not aligned? Do I have a prioritization problem? Do I need to address that? I think it's one of the things I quite liked about the way that the article lays it out, because you can see it from those different points. And then they provide suggestions, the kind of suggestions we often provide. But I thought it was quite a nice way of tying all of those different pieces together into a cohesive whole.

Dave: 11:38

No, I really liked it and I think that I guess we often talk about agile transformation requiring coaching or that people side of things, but it does also require the thought around structures and you know how meetings are run or how decisions are being made, and there's sort of mechanics of how things work. But I think you need both and we've always argued this and I think that's one of the. I think we've just been coming out of a period where it's been dominated by coaching in terms of, and now we're hopefully coming into a more mature, organized sort of landscape where both working together, both sort of mindsets working together, becomes the norm perhaps. Yeah, which?

Peter: 12:16

is all for the better. I think there was somebody in one of the communities and in just this week or last week talking about how he's trying to explain to the senior leadership within the company he's working with that, how it's not just the focus on people to that point, and that you need to have an understanding of the system to be able to improve the system and that the if you just focus entirely on like well, as long as we have the right people or the right things, will happen. That's not entirely true on its own. You also need to have systems that will support and help encourage the right behavior and the other behaviors you're looking for, so that you end up with the activities occurring the way that you want them to and encouraging things like collaboration, for example.

Dave: 13:02

Yeah, so maybe, just as we're kind of pulling a few things together, is there anything that you look at in given the article on what it's talking about, this concept of collaboration and where it fails, any any things maybe that they've missed or that you'd like to bring to the top in that conversation?

Peter: 13:17

I think one of the things that made it quite powerful to me is they would they talk both from. So often when you see in the agile space they talk about things as, like, all command and control sucks, so don't do that. But they don't also talk about the the fact that if you do agile in the wrong way or you trade an entire separate agile company that goes off and does things completely differently but you don't create the capability to tie that back into the rest of your organization, that's also going to fail. That's also going to create a bunch of problems. So that piece is, I think, nice that it looks at it from those points of view. So I think that's a very powerful message to be able to see both of those side by side, that you can see that it's not just about one or the other. It's about how do we do this effectively across the organization and identify when there are problems, how we can go about addressing them.

Dave: 14:09

Yeah, I think that's a great observation there.

Peter: 14:13

What would you take away from this article?

Dave: 14:15

I think that I kind of mentioned earlier on that whole idea of the managing across the boundaries and recognizing that that is a huge as a leader, because the article really talks about this. You know teams that are being built up and the boundaries between those teams and what happens when whether those teams, those boundaries, are permeable or not permeable with information, communication and so on, and it touches on some of the consequences of it. And I think one of the key things as a leader is recognizing, when we step into a highly collaborative environment, we need to look at those boundaries and understand what needs to change in order for those boundaries to be permeable to the right types of information so the right decisions can be made on where they shouldn't be permeable for whatever reason, and that you know has to do with things like priority, overload or overwhelmed nodes and work transparency and thing that we just talked about in the article. So it's not simply a case of dissolving those boundaries Again, from an agile mindset. We talk about cross functional teams all the time and say get rid of all the boundaries. Well, some boundaries need to be there and they need to be there, but operating in a different way to the perhaps what we used to.

Peter: 15:18

Yes, yeah, I think that's a good point too. So with that, I think we can. We can sum this up, wrap it up for today and thank all of our listeners for the wonderful feedback they give us, and if you wish to give us some feedback, you can at feedback@ definitely maybe agile. com. And don't forget to hit subscribe, because we always like new subscribers. Thank you.

Dave: 15:41

Thanks, Peter. It's great to catch up after a bit of an hour, hour and hour and some relaxation that we've both been able to find over the summer.

Peter: 15:49

Yeah, this will get back into the swing of this. You've been listening to definitely maybe agile the podcast where your hosts, Peter Maddison and David Sharrock, focus on the art and science of digital agile and DevOps at scale.

‍