S2E3 – Cracking the Code on Collaboration

Show Notes

“Just collaborate”: the favorite guidance of many a leader to solve any challenging group dynamic problem. And often when collaboration doesn’t work well, the blame is placed upon the individuals and teams involved in the collaboration. Can we as leaders do better? Join Andy and Mon-Chaio as they explore the research around collaboration, dive into what good collaboration really looks like, and build a model for enabling effective collaboration from the very top on down.

References

•  ⁠Etymology of “collaborate”⁠
• ⁠Reconciling perspectives: A grounded theory of how people manage the process of software development⁠
• ⁠Enhancing Shared Mental Models: A Systematic Review and Meta-Analysis of Randomised Controlled Trials⁠
• ⁠Factors of collaborative working: A framework for a collaboration model

Transcript

Mon-Chaio: Thank you everyone for taking time out of your day again to join us here on The TTL Podcast. Today we’ll be talking about collaboration, which is a buzzword these days, especially in the post COVID era. We’re going to be focusing on how collaboration happens, when it happens, what triggers collaboration. As well as, when is collaboration good versus when is it bad? We all know that you can under collaborate, but is there such thing as over collaboration? Just a sneak peek into some of the aspects which we’ll touch on today. Does that sound about right, Andy?

Andy: That sounds right to me. And that was really good collaboration right there, Mon-Chaio. We’re gonna work together on this.

Mon-Chaio: We needed to reconcile our perspective about whether these were the types of things that we wanted to talk about today.

Andy: Ooh, foreshadowing. Foreshadowing there. Reconciling perspectives. So Mon-Chaio, one of the things I started with, cause I’m a bit of a word geek, I love etymology, where does collaboration come from, like the word itself? Do you know? Did you read our notes?

Mon-Chaio: I did read our notes, but I’m going to pretend like I don’t know to make this more interesting.

Andy: So collaboration is from Latin, like all interesting English words, and it’s from the word “laborare”, which is “to labor”, and “com” which is “with”, so to labor together is really what that ends up meaning. And I just learned an interesting fact about Latin, which is that the M will change to an L if there’s an L after it, which is why it’s not “comlaboration”, but it’s “collaboration.” I just thought that was interesting. And I was expecting a little bit more interesting of a meaning of the word, the origin of the word, rather than just meaning “work together”, which is what we would say in English, if we weren’t going to say collaborate.

Mon-Chaio: So “work together”. That sounds fantastic, Andy. We should always work together, right? I mean, I am fond of saying, when people ask me about leadership style, I say I am a fan of obsessive collaboration. And when I define that, I define it as I think there’s two types of people. There’s people who collaborate by need, which is work on my thing until I’m stuck, poke my head up like a meerkat, look for somebody who can get me unstuck, and then as soon as they get me unstuck, I burrow back in and work by myself again. That’s what I call collaborate by need. And then there’s something I call collaborate by nature, which I define as this concept that you’re always thinking two heads are better than one, three heads are better than two, four heads are better than three. And your whole style is to try to figure out, at all times, whether another voice would help make the thing you’re doing better.

It sounds like, especially with the definition of collaboration, “work together”, it’s always good. So we should just be doing it all the time.

Andy: Yeah, just do it all the time. And that’s all it takes. It’s just say you’re going to do it all the time and you’ll be fine. Right Mon-Chaio? I’m guessing you’re posing of this question is that there are times when collaboration is maybe not the best approach. What, where, when is that?

Mon-Chaio: Well, I think, like everything else, it’s nuanced. And so there is foreshadowing here. But I think in order to really dive into when is the right time to do collaboration, perhaps we should start with, what does the research say about when people collaborate, or what triggers collaboration, or why people would collaborate in the first place?

Andy: Ah, right. So with this I’m going to take it to a paper that I read many years ago. As soon as I read it, I thought, this is amazing, this is a great way of thinking about it. So the paper is called ” Reconciling perspectives: A grounded theory of how people manage the process of software development”.

Which, first of all, it’s excellent! We’re a podcast about software development, and I think finally we have a paper about software development. That is a good first step here. Now, this paper is by Steve Adolph, Philippe Kruchten, and Wendy Hall, and I happen to know a little bit more about this because I’ve talked to Steve Adolph many times. And what this is, is it’s the outcome of his PhD research.

The overall paper came from what’s called grounded theory study. So he did a grounded theory to create a theory. I’m not going to get into the details of that, although one of these days, Mon-Chaio, one of these days we’re going to do something on research methods. But the basic idea is he came up with this theory to describe what he saw happening in some development organizations. And the theory, to summarize it, says that at the core of what’s driving a lot of stuff going on is what he labeled, reconciling perspectives. And what that is, is that you’ve got different people, and they have different views of what they’re doing, what’s happening, and that they’re going to go through different phases, where at times, their perspectives are coming together, or their perspectives are maybe going to somehow start drifting apart.

Now, during the coming together, that’s the reconciling phase. And that starts to happen when someone first reaches out. Mon-Chaio, this is in your thing about the reconciling perspectives, when the person who’s, what is it, the not so often collaborator? Or what did you call them?

Mon-Chaio: Collaborate by need.

Andy: Collaborate by need. This is when you would notice that kind of a person doing what they called reaching out. They reach out and they say, oh, I need some help. I need some help. And what they then flip into is some sort of negotiation process. And they need someone else to negotiate with them, to find a consensus, find a new perspective that they can use to understand what’s happening, understand what they should do, and that kind of stuff.

And once they’ve done that, now they have a new perspective, and now you need to move into what the paper calls validating. And in validating, you probably, very first thing you do, is you move into what they call bunkering. This is now where that little meerkat thing, they poke their head up, and then they bunker. They go back down, and they squirrel away, meerkat away, at working on this. And at some point they move into accepting. You could almost see this as a bit of a TDD cycle. You come up with, I think this is what’s happening, go away and you try it out, and then you repeat again and again.

Now, a central part of this is that you need to reconcile those perspectives. You need to bring people together in order to first notice that the perspectives are wrong, and then second, bring those perspectives closer together. And so that gets to, to me, that kind of central thing of what is collaboration.

It’s bringing those ideas that you have in your head to another person, so that other person can bring their ideas in their head to you, and you can start working out, okay, is this what we’re doing? Now, that sounds all very mental, but usually when we’re talking about collaboration, it’s much more physical. It’s much more like, oh, you write this, I’ll write that, right, Mon-Chaio?

Mon-Chaio: I’m not sure about the mental or physical part yet, because I’m not really thinking along those lines. Here are my perspectives as I was reading the paper, and we should spend some time reconciling them. I think the first thing that I noticed was his theory on reconciling perspectives in this software organization was very focused, I don’t believe really within the software team necessarily, but between what he called the giver and doer of the task. I don’t have the terminology in front of me here …

Andy: Yes, there was the acquirer and supplier of tasks.

Mon-Chaio: Right. And so for him, what he was postulating was this method of collaboration is really about the acquirer not being on the same page as the supplier. And you can see that terminology also when he talks about acceptance, right? During the acceptance phase, it’s the acquirer showing the supplier some work product, he calls it. To show them, yes, we have reconciled our perspectives, and not only have we reconciled our perspectives, I show you that we now have the same perspective by showing you this work product that I’ve produced. Which proves that we’re on the same page. So I think that’s one thing. It’s interesting to then translate that into engineer-to-engineer collaboration where it’s not a supplier-acquirer relationship necessarily. Where it’s not one person asking for something and one person delivering something. And I think I want to circle back to that in a little bit.

The next part I want to touch on is this concept that the acquirer in this case has a need. They are the only ones that own what the supplier has given them. There is nobody else to help them out, they have autonomy over this thing that they have. And so for them it’s important to reconcile a perspective with one or more people. But the bunkering part is they themselves executing this in a bunker.

Mon-Chaio: Now we could read the paper in such a way, and I think sometimes in the paper he alludes to this, this concept of, well the engineering team bunkers, so maybe it’s a team that’s the acquirer and not an individual. If it’s the team, it’s the entire team bunkering. He doesn’t say what happens within the team that’s bunkering, other than it doesn’t interact with its supplier anymore. If it’s an individual, then certainly it’s an individual bunkering, not interacting with its supplier.

Andy: The model does allow, it does describe that as well, and the way that works out is that, for instance, you could talk about it as a team has gotten from their supplier, from the team’s supplier, a perspective, and now they’ve bunkered. Now within that team, the team as a whole is the supplier. Sorry, is the acquirer. And an individual developer is the supplier. And you can see that if a team works in a fashion where it’s very clear where they say, these are the tasks. And now, Joe, you do task A, Jane, you do task B. Those people probably are going to go off and bunker.

And now you can start seeing where standard Agile methods start to show up. The daily standup ends up being a place to raise perspective mismatches so that the acquirer, the whole team, and the supplier, the individual, can check that those mismatches haven’t become too great. And sometimes you see this happen within a team when the acquirer as the team says, hey, Joe, you’re taking a long time. What’s going on? Do you need any help? Do we need to help you? Do we need to check in on something here? Cause a part of that perspective is how long will this take? Maybe not just what it is, but how long might this take?

So, yeah it does work on those multiple levels, which is actually one of the things I love about the model. It can work on a lot of those levels, but you’re right. One of the things that was very strongly in his mind was this thing of, from outside members to the team, how does that collaboration work? Or from team to team? He works as an agile coach. And so he was quite often working with product managers or companies who are not used to effectively operating software teams, and so this came from his insights in working with those groups, which is that a lot of the problems came from perspectives that didn’t fit together and would never get reconciled.

Mon-Chaio: I like that. I think that reconciling perspectives is a great way to think about what I would call one major portion of collaboration. And it may be the one portion of collaboration that most people think about. To your point, you immediately connected it to my collaborate by need meerkat model, I think it fits well into there.

But I’m curious how you would think about it fitting into my collaboration by nature model. And the reason that I ask that is because in my mind, in that model, there is no acquirer or supplier. There is no I’m collaborating because I need to reconcile perspectives because I think I might be wrong. It is more of an exploratory or information gathering of I am constantly … maybe you could call it reconciling perspectives, I don’t know. So, instead of rambling on about this, maybe i’ll just turn this over to you, like, what are your thoughts on that?

Andy: It’s an interesting problem because I would say that my way of working is very similar, which is probably why we do this podcast Mon-Chaio. I seek that collaboration. In fact, I get very uncomfortable if it goes too far before I have that check in to make sure that I still know what I’m working on.

And I think that the model also provides a very useful way of thinking about that. Because the model, as we just talked about, the model isn’t necessarily about individuals or teams. It can deal with any of those levels, any of those size of group that we’re talking about. And one of the things that’s easy to think about with collaboration is that you should do that mismatch check.

But it’s harder, especially for those of us who think that collaboration is what we should be doing all the time, to think about there are times when you don’t want to do the mismatch check. There are times when you don’t want to reach out, and the model I think is very useful because it calls out that there’s this phase that we talked about, we’ve mentioned it, called bunkering.

And that is when you are explicitly not trying to find a mismatch, and that it’s really valuable. And … they … I’ll just read a little bit from this because it might help:

“This ‘quiet time’ is built into software methods like Scrum, which most teams participating in this study claimed they were using; however, it also seems to be part of the culture, regardless of the software method used. Once a Consensual Perspective is reached, construction of a Work Product should proceed relatively undisturbed until it is done. The desired, quiet, undisturbed environment created during the Bunkering stage contributes to productively creating Work Products.”

So there is a phase that you want to stop some of that collaboration to get something done. Now, the question becomes, when do you break bunkering? When do you break out of that phase to reach out and get that collaboration again?

Mon-Chaio: I think the question is even larger than that in my mind. You’re right that there is a question about when do we break out. And if you think about traditional teams, let’s call them non-agile, non-pair programming teams, there definitely is this question of I am typing on my editor and now I’ve produced v1 or I’ve committed some code, is now the time to submit it for code review or do I keep working? When do I show it to the product manager? So I think absolutely there’s that question.

To me, an equally interesting question is, is bunkering always required? I’ll seed that by going back into our pair programming example, and it helps because we’re both pair programming aficionados, or supporters, if you will.

The bunkering argument might say, why are we doing pair programming? There is no bunkering in pair programming. Certainly when we did it at CarDomain, there was no bunkering. And when I’ve run it in other groups, there’s been very, very limited bunkering. I would say the bunkering is probably 10%, 5% of the org.

Were we doing it wrong? Or what would we say about that?

Andy: I would say that the pair is bunkering.

Mon-Chaio: Aha! So this gets back into boundaries, right?

Andy: Yes. Yes. The pair … oh, that’s a very good way of framing it. Yeah, Mon-Chaio. The pair has created a boundary and it is now the entity that is going through the reconciling perspectives loop. They have that idea and now they’re gonna bunker to work on that for a while.

And at some point they’re going to say, you know what? We’re done. Let’s show the work product. Or they’re going to say, we’re not done, but we’ve hit information that tells us that we may not understand this properly. And they’re going to unbunker and they’re going to go and show the work product that they have so far or something, to get that perspective work done. And then they’ll go back to the bunkering.

Mon-Chaio: And that leads to the next interesting question in my mind, which is, if we are saying that there are these boundaries that we can draw around, within this boundary, we are the entity which is bunkering. Outside of this boundary, we are not the entity. This paper doesn’t really give us any models in order to decide what those boundaries look like.

And I think the … I wouldn’t even say naive interpretation of the paper, I would say the easiest interpretation, if you gave this paper to a software organization, a random software organization out in the world today, they would read it and they would say, yup, Joe, that individual engineer is bunkering, and Mary, that individual engineer is bunkering, and they’ll come back, see? We understand collaboration now, and we’re doing it exactly as this paper would say we should do it. But I don’t think that’s what we would espouse.

Andy: No. And I would also say that would be a misuse of the paper. To say that, oh, we’re doing what this says. No, what this is, the paper is really just saying, this is the cycle that’s happening. Just like we’ve talked about with team topologies and with BART, now that you have that lens that you can look at things through, you can start asking your question in your team, what stops bunkering? Do they not bunker enough? Are they constantly trying to reconcile perspectives rather than kind of build up enough information about a mismatch to have that meaningful discussion? You can start using it as once again, a diagnostic tool.

But I think it does tell us that our investigation of collaboration has maybe moved a little bit beyond the Reconciling Perspectives model, and we can start asking a little bit more about what does it really look like? So Reconciling Perspectives tells us, all right, it’s going to be this interplay between mismatches and bunkering and checking, and you’re gonna move around between those. But is that all it takes? Do we need anything else? Or is it really just that? And I think we would probably say no, right Mon-Chaio? There’s probably a bit more to it.

Mon-Chaio: Yeah, I think there’s probably a bit more to it. I think maybe we need to talk a little bit about terminology too, because I’d be curious, within the boundary, let’s say of the pair, we agree that there’s a boundary of that pair that they’re bunkering as a pair. But how would we describe their interaction with each other?

Would we describe the two of them as collaborating? And would we describe them as reconciling perspectives between them two?

Andy: See, I would say that they’re collaborating. We can go by the dictionary definition. They are working together, very obvious. So it would be hard to say no and still be consistent with the language that we’re using.

But I think even within them, because … as a human being, the way I can communicate with someone is I could use hand gestures. I could do all sorts of things, but generally it’s going to be spoken or typed, written communication. And a lot of the time when I’m pairing, I may not be saying anything. I might be watching, or I might be typing code and through that, my mental model can start diverging. I’m going to introduce a new term here, the shared mental model.

Mon-Chaio: Mhm.

Andy: My mental model is going to start diverging from my pair.

Mon-Chaio: Mhm.

Andy: And at some point I might say, wait a second, and this could happen even while I’m talking. That we’re talking about one topic, but we’re not talking about this other topic. And through going through something else, it suddenly appears to me, wait a second, this thing that I thought we understood the same, we don’t understand the same. And that’s now impinging on our ability to do this work.

Mon-Chaio: Yeah, I think that makes a lot of sense in my mind, too. I think the tricky thing is, initially, when I hear the term bunkering, it feels to me, I go back again to that traditional team, and then that definition of how it applies there, it feels like a length of time. I sit there and I do a length of time of work. It feels, on the order of maybe hours.

Andy: Mmm.

Mon-Chaio: But I think that if you apply it to something like pair programming and start to think, two things. One, that bunkering can be on the order of seconds or a few or tens of seconds. You can see a pair in a pair programming model as doing small portions of bunkering and then going into the reconciling perspectives mode quickly in a very constant loop.

Andy: In fact, I find that to be a very productive form of pairing. Very unproductive form of pairing is where both sides are constantly talking. Neither can just sit and get some of the code out.

Mon-Chaio: Mmm hmm.

Andy: So you do want those quiet periods. Which means, managers, if you’re walking around and your team is pairing, it may be really quiet. They may not actually be talking a lot of the time, as one person is examining what’s happening, is writing down their thoughts about what needs to come next and periodically glancing up at the code that their pair is writing. They’re realizing that they don’t need to reconcile their perspectives. But then, immediately, as soon as they notice the mismatch becoming meaningful, they can unbunker, negotiate, reach out, negotiate, come up with a new perspective, and start again.

Mon-Chaio: The next question that brings to mind, and you brought up SMMs, right? Shared Mental Models. I think we can all agree that if it were possible through technology or through some act of biology, if we could snap our fingers and everyone would be on the shared mental model, we would all be very happy. And then we can essentially bunker all the time because the shared mental model updates magically somehow.

Andy: it’s just in the background. It doesn’t take us a phase of unbunkering to figure it out. It’s just, you’re sitting there and thinking and then suddenly you realize, oh no, that’s not what we need to do. And you turn to your pair and they are thinking the exact same thing.

Mon-Chaio: Or even your CEO comes up with a new idea and he changes his strategy right there and immediately the entire organization knows it somehow magically and you all shift your work because your mental model is different. Assuming that is a good thing, and then if we go back into our pair programming example, we would say, look, we have these very short periods of reconciling perspectives and shared mental models because it allows us to continue to be on the shared mental model much quicker, right? It doesn’t take us an hour or a day. It takes us a few seconds or a few minutes.

Why wouldn’t we do that consistently and constantly across the entire organization? Are there things about shared mental models, what it takes to develop shared mental models, constraints around that, I think you were mentioning, that prevent us from simply doing that across the whole organization all the time?

Andy: That’s a very good question. And I have a feeling you have a thought on this, so I’m going to lob the question back at you.

Mon-Chaio: I often talk about collaboration tax, but we’ve never really defined it, right? We’ve talked about, oh, it takes mental load or whatnot to collaborate. It takes time. It reduces autonomy. And so part of it, I think, is that, but if we’re using the language that we’re talking about in these papers, to build a shared mental model requires you to have the same context.

Andy: Yes.

Mon-Chaio: If you have wildly different contexts, you cannot build the same mental model.

Andy: I would say a shared mental model is the shared context. And so what you’re saying is that to build that shared mental model, all of this stuff where we might say, you have to build a shared context, what we’re saying is, yeah, all of that information, you need to communicate it across to another person, and even then you’re not gonna guarantee that other person puts it back together in their head in the same way.

Mon-Chaio: Right. And for me, I think about being able to hold things in your mind as a cache. Going back to Team Topologies, they will talk about, I cannot remember their exact terminology around this, but there is this concept about how much can you hold in your head at once …

Andy: Cognitive load.

Mon-Chaio: … cognitive load. And once you get past that cognitive load, team topologies would argue that’s when you should split teams and create a boundary. I tend to think that’s probably true.

But if you think about cognitive load and shared mental models, in order to create a shared mental model, your cache has to keep the same stuff in it. And if you can’t – and honestly, for most companies, no one person can keep the level of detail required for the entire business process and product in their head all at once – it means things drop out of cache. And so as soon as you align to one shared model with one group, in order to align with a different group, you forget about that shared mental model. It drops out, or the fidelity becomes much less, at which case it becomes much more difficult to reconcile perspectives.

I would posit, Andy, and tell me how you think about this, whether you think I’m crazy or not, I would say that in a boundary where you all have the same fidelity of context regularly, that is a place where you should be collaborating constantly, continually refining your shared mental model. Your bunkering periods are much smaller, your reconciling perspective periods are much larger. And as soon as you cross that boundary, to a place where your context and fidelity of context is differing, necessarily differing, that’s where your bunkering period should be larger, and your reconciling perspective periods should be smaller. What do you think about that proposal?

Andy: I like the idea. My initial thought is I think you’ve connected it to the wrong ideas of reconciling perspectives, but I like where you’re going with it. I wouldn’t connect it to the bunkering and the reaching out necessarily.

I would connect it to the bunkering, yes. It’s like the cache analogy we’re using. If most of the stuff from the other mental model I have to kick out of my cache, most of the time because it’s not used often enough, like a least recently used cache, I don’t use it very often, and most of it needs to just get kicked out, it’s not that I should spend necessarily less time on the reconciling, on the … reaching out is their term for saying I need to negotiate to get that perspective fixed up. I would say you have to create a higher tolerance for a mismatch

Mon-Chaio: Aha.

Andy: That you are more willing to know that your perspective probably doesn’t match with what the other one is, so you need a much higher bar to start that what they called reaching out process.

Whereas the things that are closer to you that are part of that recently used cache of shared mental model in your head, those you should have a much lower bar for reaching out to start reconciling perspectives.

Mon-Chaio: Interesting, I like that. Might, another way to restate what you’re saying, be something like, you have to create your business processes and models to be able to handle a larger discrepancy in between boundaries? Another way, in the technology term we might say, if you have APIs close together, they’re tightly linked, and what they accept and what they give have to collaborate.

But if you’re on other parts of the world, or you’re using AWS, where you don’t have control over them, you have to be able to take their API, and if their API is spewing out garbage, you have to be able to deal with it gracefully and continue to run your system, and make sure your system doesn’t shut down.

Andy: Yeah. Yeah, I think so. And taking this to more of the management of software organizations, the thing that software organizations sometimes do is this kind of dreaded meeting where all of the different teams, all of the different products get together maybe once a week or once a month or something, and everyone has to give their status update. Now, you go into that meeting and you’re calibrated for that kind of level of mismatch of how much mismatch are you gonna be willing to tolerate before you start reaching out and saying let’s negotiate a perspective here because this doesn’t make sense to me.

You’ll either do that, or you’ll start calibrating your mismatch mode. And if we go with the idea that people kind of set their level, and they have a difficult time changing it quickly, if they go into that with this idea that I’m not going to try to reconcile any perspectives. Now what you’ve done is there’s a mixture of people in that room giving updates about what’s going on.

Some of them are probably highly connected to what you’re up to. Some of them are probably not at all connected to what you’re up to. And now it’s very difficult to figure out which of those people do you need to reconcile perspectives with. Which of those people, when you notice a mismatch, should you reach out to? And which of those people does it not matter at all? And the reaching out probably wants to happen in that meeting, because if you point out a perspective mismatch, if you’re in a well collaborating group, like a group that’s cohesive, others are probably going to be interested in it.

So those big meetings make it really difficult. And we’ve probably all had this experience. You’re sitting in that meeting and then someone else starts questioning something and you’re like, oh my god, Pete, just leave it alone. It doesn’t matter. But to him, maybe it does matter. It’s just, we’re all sitting there thinking, this is not a perspective that I need to reconcile, why am I here?

Mon-Chaio: Right. Perhaps it’s important, in fact, not to reconcile that perspective now to enable that bunkering behavior because we’re trying to produce work product. But maybe the organizational design, or Pete’s understanding of it, is an error where, let’s say Pete’s understanding of it isn’t correct, the organizational design requires him to be able to reconcile that perspective more fully and at greater frequencies and fidelities. And so that mismatch will cause challenges in collaboration.

Andy: Yeah. Yeah, absolutely.

Mon-Chaio: And we talked at the beginning about why shouldn’t we just collaborate all the time. Now, that’s also not entirely true, right? I think the honest answer is we should collaborate all the time because, if we talk about this act of collaboration, this concept of bunkering is still collaboration.

Andy: Yes.

Mon-Chaio: And bunkering can go on, probably shouldn’t, maybe it should, for years, if you want it to. I can say, look, I’m collaborating with the US government. They’ve given me a contract. And I’ve told them it’s going to take five years to build this airplane and they don’t really care to know how I’m doing within those five years. I don’t care, I’m bunkering for five years. That’s still technically collaboration. Sometimes we’d view that as not.

Andy: That’s a really good point, because collaboration is this whole process. It’s not one individual point in time.

Mon-Chaio: And I would say for a lot of people when they think about collaboration, certainly me before I read these papers, I thought about that the same way. My definition of collaboration really was around that reconciling perspectives path. And perhaps the giver receiver and the accepting work path, that sort of stuff.

Andy: Right.

Mon-Chaio: But we’re starting to explore this concept that it’s very difficult to say you want to reconcile perspectives all the time and constantly because of that context. I’ll bring up another paper called “Factors of collaborative working: A framework for a collaboration model.” This is a really long, really dense paper. It’s almost a meta study of what every different paper says about collaboration. They have these giant tables which list out all the factors that impact collaboration, both positively and negatively. We’ll link it in the notes, of course. But it’s … you have to pick your way through it.

One thing I found interesting was they had a trust section, and I’ll just read a quick quote from that section. They say: “Good collaborative relationships are built on mutual trust and respect and these should be established early on in a new project or team. People are more likely to trust those who are similar to them ([for example] in age, status, cultural, professional and educational background). Trust is both personal/informal, and impersonal/institutionalized; a climate of trust enables people to engage in business with each other, and is of high value to an organization or an economy.”

If you recall in our trust episode, though, there are many different levels and types of trust. And so when you think about collaborating across boundaries, you would likely feel that collaboration is much more difficult with people that you haven’t talked to in six months or a year or two years than people that you work with daily. And so if we’re saying then that a business is built on the requirement of deep collaboration with groups that you don’t talk to every six months, and that the collaboration has to happen instantaneously, this … and I’ve seen this in groups, right?

I have an experience with this where my group was responsible for our particular thing and we depended on another group, but over time we found that it didn’t make sense for those to be two groups. It should be one group. And so we thought we’re already spending time doing half of their work. So why don’t we subsume a lot of that and figure out the boundaries necessary to make sure both groups are doing the right work in the right boundaries. And of course the magical term that leadership comes up with is no, I don’t want to change boundaries, why don’t you just collaborate? Spend three weeks collaborating and come to us with a model that doesn’t change boundaries, but allows you to perform effectively the way that you should.

Now, this is a group we’ve barely never talked to. They sat in a different place. They worked on a different charter. We occasionally consumed some stuff. And leadership expected us to basically be able to collaborate deeply on a very challenging task within three weeks or three months to get through this. Now, what I just read about trust shows why that’s very difficult to achieve in that timeframe.

Andy: There’s another quote from that as well, which I think happens in those kind of disparate groups that are then somehow brought to you need to work together. And they say: “‘Adversarial collaboration’ involves people with different or conflicting goals working together to achieve some common purpose. However, there is a tendency not to share all available information with others or to partially reveal information as necessary. Organizational, social, and contextual factors can impact on whether team members focus on working together to maximize team outcomes or to maximize their individual outcomes.”

And it’s that kind of thing is that the structure sets up a bit of how they’re going to end up working together. And a key part of that is if their goals are not aligned, the collaboration won’t work well. And in fact, going back to the Reconciling Perspectives paper, what would be said there is that perspective mismatches don’t get reconciled in a timely or efficient manner.

And that’s one thing about collaboration, is it’s not just this magical thing that you can say, hey, everyone, it doesn’t matter what’s going on. Just collaborate. No, it takes a lot of intervention to set up the situation where that collaboration will be really effective.

So you don’t want adversarial collaboration.

Mon-Chaio: And that’s leadership’s job, right? To set up, again, the structures and the boundaries that enable collaboration versus simply to say, the structures or boundaries don’t matter. Collaborate through it, or just be better at collaboration. One thing that I’ll mention is the first paper around reconciling perspectives makes it very clear that there’s this bunkering section that is what happens before work product is produced.

And if you spend all of your time in reconciling perspectives, because you can’t get out of it, or you reconcile perspectives but then you come away with the wrong perspectives, you’re never going to be able to bunker and produce acceptable work product. And so then your collaboration model, by and large, isn’t really working the way that you need it to.

So this is all well and good, Andy. I’ve actually had a lot of fun discussing. But what can we take away from this, or what can our listeners take away from this around how should they do collaboration better?

Andy: I think the very first thing to go back to is you don’t want to get adversarial collaboration. So one of the first things is if you’re asking people to collaborate, check and make sure they have shared goals. If it’s two teams, if you’re going to ask them to collaborate, make sure that their goals are aligned.

The next thing, is work on things that will help them get shared mental models. So are they communicating what those goals are? Are they communicating about the challenges that they see? Those kinds of things.

And then the next one, and I think this is very much a sensing approach. Use the Reconciling Perspectives framework as a way of observing how your interactions are happening. Start looking at those team meetings that you have and think about, are we reconciling perspectives on things that matter across this group?

And don’t do it from your perspective as being like the big person who needs to know all of it. Think about it from their perspective and their goals. Think about it from, does their mental model need to be shared with this other person? Or is that just icing that really, if it happens, it’s great. If it doesn’t happen, it’s no big deal. And then think about, we didn’t get into this one, but think about how quickly your organization can get through a full Reconciling Perspectives loop.

And in some ways, the faster, the better, but only in places where that shared goal exists.

Mon-Chaio: I think you’ve stated it pretty well, Andy. I don’t think there’s much I would add to it, if anything. I think I might just stress that shared goals, the areas in which people need shared mental models versus do not need shared mental models, the areas where speed of reconciling perspectives is important versus areas where, as you mentioned, Andy, they can diverge for a bit before we have to reconcile them, those are all leadership responsibilities. Those are not your IC’s responsibilities. They definitely are your middle manager’s responsibilities, but they increase more and more as they flow up.

So when you see through your sensing models that your organization is not collaborating correctly or ideally, you are the person in the mirror that needs to fix it first by thinking about things like boundaries and things like shared team goals. And only from there, once you set up the right structure, can you expect that your organization will then be able to collaborate effectively.

Andy: Yeah. Going to them and saying, I notice you’re not collaborating. You should collaborate more. Probably, most of the time, not the first thing to do. If you are going to go to talk to someone individually, the very first thing is to ask them, I would have expected more collaboration. Can you tell me why you’re not? Help me understand what’s going on.

Mon-Chaio: Very good point, Andy.

All right. That’s a wrap for our collaboration episode. If you’ve enjoyed it, or if you haven’t enjoyed it, if you think we’re right, or if you think we’re wrong, we definitely want to hear from you, write to us at hosts@thettlpodcast.com. Also, subscribe and rate us on your favorite podcatching platform. Until next time, be kind and stay curious.

​