S1E1 – Analysing a team situation using BART

Show Notes

In this inaugural episode of the Tactics for Technical Leadership (TTL) podcast, Mon-Chaio and Andy discuss the BART (Boundary, Authority, Role Task) framework for analysing group dynamics and apply it to a situation that Mon-Chaio encountered with two teams.

Referenced materials:

• The BART System of Group and Organisational Analysis: https://www.it.uu.se/edu/course/homepage/projektDV/ht09/BART_Green_Molenkamp.pdf

Transcript

NOTE: This transcript is from before we used Descript for editing. It is the direct generation of speach-to-text and has not been corrected or had the speakers labeled.

Hey, mania. What’s up? Hey, Andy. So we finally have a name for our podcast, I believe, or at least a tentative name. Yay. Yay. Exciting stuff. It is exciting. So I think what we should say is, welcome to the TTL podcast, right? The TTL podcast, the tactics for technical leadership, right? Because we want to talk about technical leadership.

Technical being, software development. Hey, we’re all in the tech business and tactics. Because we thought, well, actually what we need to do is we need to make sure that we’re giving specific advice. What can you do? How can you actually do leadership in a tech organization just a bit better? Yeah, absolutely.

And you know, I feel like we’re given our experience and whatnot, we’re and sort of maybe our unique point of view in a way. I think this will be interesting. So, you know, let us know if you like the name, if you hate the name if you like the initials ttl. But yeah, we’re open to comments.

Excellent. And you just, you tease them a little bit with our experience. You mentioned that I think in a later podcast we should talk about our experience. Why should anyone listen to us? Not quite yet. Keep listening. Eventually we’ll talk about that. Hopefully very soon, so that you’ll keep listening.

I think people should listen to us because they should, right? Totology? Oh, yeah, yeah, yeah, yeah, yeah. Just it’s a good idea to listen. There you go. All right. So today today I, I wanted to talk about moncho. Looking at situations in an organization, looking at the dynamics of teams and, and how they operate in the way that you want, or how they operate in ways that you thought that was not at all what you wanted to happen and why that might be.

Now, what I find useful when doing this is thinking about a particular model of analysis or behavior because that gives us a way of asking particular questions. A way of structuring our inquiry into what’s going on here and, and bringing to mind things that maybe you wouldn’t immediately think of.

So we’re gonna, we’re gonna try that out. Are you, you think we can do that, Montreal? Yeah. I mean, and honestly, I do think that this is a super interesting topic. I’m glad in fact that we’re covering it, sort of episode two, if you will because I just feel like some of the biggest problems in our space, You on our industry does have to do with group dynamics, right?

And people often don’t think of that. They eventually, they immediately go to processes or they go to personality fits or whatever, but or just the code is suck. You got this technical debt and that’s why we can’t do anything. It’s the technical debt. Absolutely. So I think absolutely this is a great thing to talk about.

So I think we both, in preparation for this, ended up reading about one type, particular type of model that we thought might be an interesting way to analyze it. Do you want to kind of talk through that a little bit? Yeah. So it is called the BART model now to, to throw some jargon at people. It’s a BART system of group and organizational analysis.

It’s created by something called the tavistock. If, if you have any background in the, the psychology disciplines or sociology disciplines, Tavistock is a name that will come up quite often. They’re well known ever since sixties or before. And what this is, is it’s the model that they use in their group dynamic seminars.

It’s the way that they analyze groups. The BART is not the, the train line in San Francisco. That would be kind of cool, but it, it has a different meaning here. It is boundary authority, role, and task. And the idea is that when you’re looking at the dynamics of a group, Internally, this is a fairly important thing internally.

People have their understanding of what the boundaries are, they’re working within, what their authority is and what other people’s authority is, what their role is in any given situation, and what the task is that they’re there to actually perform. And what you do in the analysis is you start asking a bunch of questions of nothing, all that structured, but questions about these ideas.

So for instance, you might ask what authority? Is being exercised by this individual or this team, or that this organization, and how did they get that authority? Mm-hmm. Is it formal? Did someone with other authority grant that authority to them, or is it just that we all assume they have that authority?

Authority? It’s kind of informal authority. We just all let it happen. Mm-hmm. Which isn’t bad. You just need to understand it’s there. Right. Absolutely. What’s the boundary? A boundary could be about time. Well, this thing happens. The, the, the, the task is operating within a particular time bound. It could be geographic.

We’re talking about just this office versus that office. Those are their boundaries. It could be something actually related to the authority. What’s the boundary of that authority? Where do they, where do they have authority and where do they not can also be part of bound role? Role is kind of like what is your job description?

What is your informal job description, those kinds of things. And then task is, What is it you’re trying to do? Quite often it’ll be something about well make the business money, but the task more immediately is often, well, what is it that this project is trying to achieve in order to make the business money?

And so that, that kind of very simple framework that just opens up a bunch of words for us to think about can be really useful for analyzing a situation. Yeah, I agree. I think, I think frameworks are a really great way at least for me, I like using frameworks. Maybe it’s just the way my, that my mind works and putting words that everyone agrees upon what those words mean to describe, you know, certain pieces of analysis, I think is super important.

Yeah. I’ll tell you, Andy, to be honest, like when I was reading this paper, it felt a little, what’s the word? I would call it, academic, dry, dry, academic. But academic and dry don’t necessarily have to go together. But I felt like there was a lot of jargon and I felt like there were a lot of words, but having finished it, I did like draw back to my own experience about something that had to happened.

And I think it would be interesting to explore maybe how the concepts that were presented in this paper may or may not be able to help us analyze what went well and what went wrong in this specific situation. I’m an optimist. I think they’ll help us. Okay. So, so let’s, let’s give that a shot. Let me try.

Sort of laying out the situation and then we can sort of talk through it. All right. Does that sound good? Yeah, I, I’m, I’m, I’m, I’m excited. I’m interested. Alright.

I’ll start off by saying that this situation happened at a company which very much values what they would call bottoms up leadership, bottoms up, innovation, bottoms up, participation. So what does that mean? That means, unlike some software companies I’ve worked at in the past, The quarterly planning or the half planning or the year planning isn’t just a bunch of stuff that comes down from project management PM org, and then the engineering org says, okay, well you’ve already rank ordered all of these things, so like, let me figure out how I can fit them into X, Y, and Z.

This company very much valued that that list actually come from individual engineers that were an individual PMs working with those engineers that talk to customers every day, that build stuff every day, which I think is. A very, very laudable goal. Mm-hmm. So I’ll, I’ll just set the stage there because again different types of organizations with different cultures will have a, a different sense of like how they should operate or what’s broken versus what’s not.

Right. Yeah. Yeah. And, and in this case it’s, they wanted that autonomy of decision. They, they wanted, yeah. You guys know what’s going on, so tell us what needs to happen. Right. And I think the other important thing to bring up is that because it was such a big part of their culture, they hired for that.

Mm-hmm. And. People that go into the companies end up expecting that and wanting that. The company itself also made it very easy for people to transition between organizations. And so what was, what’s interesting about that is if people did not find that they were autonomous or that they had bottoms up leadership or any of the other things which they might be unhappy about, they could very easily move.

Right. You know, without any sort of career costs to themselves. So, That’s sort of the context of the company. Now, why don’t we talk about the context of the specific situation within the company. So the company itself had a product that was a consumer product. That consumer product had been in the market for quite some time and was fairly successful.

Lots and lots and lots of different users. And as a product of that scale, that org was divided into various different supporting orgs, right? So there was like the UI layer for that product. And I should mention that this was a mobile. First slash basically emit mobile only product, right? And so there was like the UI layer, the app layer, there was like the iOS group, the Android group, and then there were various platform groups that supported it.

You know, without getting into too many details, there was like platform group A that handled one part of the platform to support that product platform, group B, that handled another part. And so that was a pretty autonomous organization that built that product. At one point in time, company leadership decided, well, you know what?

This consumer product. Or at least the bones of this consumer product would be super interesting if we were to apply it to the business context. So instead of a, you know, consumer product, we have a B2B product that we can then sell. And you, you said the leadership decided that, was that, was that from the top or was that something that was decided or suggested from the, the.

Bottom. No, that’s a good question. No, in this case it was from the very top. Right. Okay. And you might say, well, how does that jive with sort of bottoms up leadership? You know, as we all know, not everything going for gonna come bottoms up, right? Otherwise, what is your c e o supposed to do? Sit there and just wait for bottoms up ideas, right?

So no, this this directional setting which is exactly what I think engineering executives should be responsible for did come from the top. Right. I, I often see the, that kind of thing to, to a slight sidetrack is that you think about you want to incorporate the information across that whole structure, and so you want both information from the bottom, information from the top, information from the middle, and you need to kind of bring it back and forth across all of that as it kind of.

You try to figure out like, okay, how does this fit together? Does that take us in a direction that the company needs? Which is usually what the people at the top really should be understanding. And then is that taking us in a direction that we can do is really what the people at the bottom should be understanding?

And then you kind of have to put it together and say, yes, we can do it, and we need to go there. Excellent. Yeah, absolutely. Part of that side tangent is I think one of the most important skills for leadership that people talk very little about is being able to make sense. Of many disparate signals, vague signals.

Mm-hmm. Irrelevant signals and putting them together into something that makes sense and is quote unquote valid for the time and space that we are today. Right. Yeah. And then telling that story so that people can believe it’s valid. Oh, man. Telling that story is gonna be it’s whole separate series of podcasts.

I think. Don’t even get me started on telling stories. So, so important in every role. All right. But getting back, getting back to what we were talking about today, back to your story. Right back to my story. Okay. So, so the leadership decided that they wanted to use the bones of this consumer product in the business space.

And of course in the business space, think about like a company like, I don’t know, just any company, Microsoft or whatever. People aren’t using their mobile phones right at work all the time. They’re on their desktop machines. And so it was important that this product now be migrated or segmented off to desktop which had never been done before, right?

So in in service of this, obviously they created a different org, right? It was an org that was specifically focused on business use cases for this product. There wasn’t a deep tie into consumer at all. In fact, it was really thought, well, I don’t know that they’re really gonna share any of the same UIs, right?

One’s on desktop, one’s on mobile, different paradigms. But definitely the bones or the platform parts of the product would have to be shared. So we’d have to use some of the consumer parts of the platform. You know, we might copy some of the code, we might call into some of the APIs. And then of course there’s desktop specific stuff that have to be built on the business end.

And so that got kicked off. It’s a completely different organization, like I said, different reporting structures, right, different roadmaps. Totally made sense. So that came up. That started going for a little bit. And then leadership decided. And, and, and I just wanna clarify something really fast.

Mm-hmm. Sorry to interrupt. When you say that, that went off rolling, it sounds like, and I just wanna check this, it sounds like the, at the engineering level, you had these organizations. You had the, the, the people writing the UIs, the people writing the platform, and that they almost had this agreement of, we’re related but separate.

You’re gonna use part of the platform, but you know what, fork it. If you need it, if you need to make changes, we’re gonna be doing our thing. You’re gonna be doing your thing. Let’s just kind of keep an amicable, but separate relationship. Is that about right? The way that they were thinking about it?

Yes, absolutely. And I think there’s a slight nuance there, which again, will tie back to what we’re talking about in the BART model. That is how I, and I think many people would read the situation, but that was never really explicitly stated. Ah. Right. But that was in fact how those two groups were operating.

You know, we’ll help as much as we can. Right. But it’s clear that, oh no, from the consumer side, your business use case is so small. We have so many users. We’re focused on our users. And from the business side, at that point in time, well, you know, we’re not thinking about consumers at all. Right, right. So, It was never explicitly stated, but a lot of people assumed that their boundaries didn’t really overlap.

Correct. Their tasks were separate. It meant that they had separate boundaries. They didn’t have authority over each other. Correct. No one was like you, you need to do this because you answer to me. From the BART perspective, they were kind of separate universes. At least that’s the way they thought they were.

And cuz I think, I think you’re foreshadowing something here. Yeah, absolutely. Yes, I am foreshadowing something, but yes, absolutely. They were basically separate universes. And I like the fact that you used this idea of boundary and authority because I think those will come into play very strongly as we talk about what eventually happened here.

Okay. Yeah. So it was, you know, they went off rolling. Like you said, the rgs and the product org for the various groups you know, they kind of didn’t talk much to each other. You know, they’d reach out and be like, Hey, can I use your API here? Oh, it doesn’t quite do this. Can you make it do that?

Generally the answer would be, well, no. You know, our customer base is a lot larger than yours, so why don’t you come in? Or why don’t you fork it? Or, why don’t you X, Y, or Z? Right.

Interestingly. However, at some point as the business product was progressing, leadership again took a look at it and said, you know what? This would be very interesting in the consumer space as well. There’s no reason that this just has to be a business product. There are many times when consumers are not just on their mobile device.

Sometimes they’re on, you know, desktop devices, right? And so let’s, you know, let’s make this broader. And so the org that was building the business product ended up taking on the consumer aspect of this primarily because they had the expertise in writing desktop software and this was gonna be a desktop product.

Okay. Right. And for anybody that’s written mobile versus desktop, you will probably know it is quite different to develop across those platforms. Quite different. And so it became sort of a tech, you know, sort of tech center of excellence type of thing where like, okay, you have, you have knowledge here, right?

You guys were already writing a desktop. We want this for consumer now. So how about you take over writing the consumer desktop? Mm-hmm. And so, you know, then of course the. PMs on this previously business side of the organization now started to think about what are the unique consumer use cases on the desktop side.

And then they started prioritizing those. They still had to think about the business side of things. And so this product ended up being built up that way at some point, and this is, I think, Hopefully where we can start to do the analysis and ask questions around that at some point. Here’s where this product and this org ended up.

This product ended up almost a year late in shipping extremely buggy insofar as I would say, somewhere near 60% to 80% of all tasks coming in were bugs that were being reported and had to be fixed. Interesting. And there was a lot of attrition, mass attrition from this group previously. The business desktop application.

Right. I’ll just start calling it the desktop application for now. And the other one I’ll call the mobile. Right. Because now they’re not business consumer focused. They’ve sort of morphed. Right, right. So this desktop application group is now attriting like crazy. Right. And morale is low. And, and do, do you know the reasons why people are leaving?

Like what, what are people complaining about at that point? I don’t think there was any formal analysis done around why specific people were leaving. I think there were some conversations around it. And I mean, as you leave orgs, whether you go to other companies or whether you go to partner orgs, you always know not to burn bridges, right?

Yeah. And so you get these answers like, oh, you know, it doesn’t fit sort of my career aspirations, or I have a buddy working in this team, or things like that. There were some more honest answers that probably came out more in like one-on-ones and like, Which is normally where those will come from. The exit interview is eh, right?

Yet another topic on like whether exit interviews are ever reasonable to do or helpful, I should say. They’re always reasonable, maybe not helpful. So that’s the state, right? And so, you know, product late, many bugs and Massa atrition. Is, is there some sort of like dispute going on between, between requests?

Like I, I, I guess what kinds of bugs are these? Are these like poor engineering practice or are these like we don’t understand what we’re building? Mm, most of the bugs were actual bugs. They were things like, the product isn’t working as expected. Where as expected I think is, was very clear. Well, as expected was clear insofar as for a polished product, this would not expect to be the case.

So for example I clicked a button and I didn’t see a response from the UI for five seconds. I see. Right? Things like that. There definitely were some sorts of bugs, and again, foreshadowing here. Which were around, Hey when I do this on mobile, it works, but when I do this on desktop, it doesn’t.

Right? Or when I do this on mobile, this is the behavior. Or when I do this on desktop, the behavior is slightly different. And why was that? Why, why do you think that was happening? I mean, they’re different code bases, right? They didn’t share code. Right. Okay. One example would be like there was this database that stored the number of times something was seen, and that database didn’t exist at the platform layer on the, on the mobile product.

It existed in the, call it the app layer. And so then on the desktop product, it had to exist on the app layer as well. But the logic was different about how it stored those numbers or how it incremented those numbers. Right. So, so let me get to the, I think the crux of like, where you would, might, might say this is a problem that’s occurring.

And, and then I think once we’ve got that, then the analysis can start happening. I think, let me get this right. I think that you said it when you said that they don’t really share code. Mm-hmm. I’m guessing they don’t really share platform or infrastructure either. They’re not collaborating to create a Uni unified product.

They’re trying to like copy each other. Is that about right? Interestingly, yes and no. So that makes it even more interesting, right? So to talk about unstated expectations or agreements, and the reason, okay, so I’ve been going for this. I’ve been looking for, what’s that unstated agreement because. In the BART model, so much of it is about making these things clear and explicit, and I’ve been trying to dig for where is the uncertainty, where are they unclear?

For instance, on the boundary, one of the things the paper says is that the boundary has to be, it’s crucial that it’s clearly specified. Clear specification of time, task, and territory boundary should answer these questions. When, what, where? So you, you, they, they really need to know what is their boundary and it has to be agreed upon, all the parties involved.

Need to agree. Absolutely says, although a boundary may be clearly outlined, invested, parties need to come to some agreement about what the stated time task, or territory boundary is, or how they interpret it. I think that how they interpret it, very important. Right. And I think probably not, probably not surprising.

A lot of the paper talks about making things explicit. Right? Yeah. Similarly on the. Authority side, right? The, and we’ll get into this later, but clearly defined authority that’s taken up co accordingly and accompanied by tools to exercise it. So being very clear about what things are and whether you can, and have the materials in order to do it.

So these unstated sort of assumptions, you’re right, are very tricky. And yet I feel like every place I’ve ever worked, there’s probably been more unstated assumptions even around this idea of BART than clearly stated assumptions. Would you agree in your experience, Oh, I think so. Yeah. Yeah. The, the like yeah, generally just kind of take care of this thing, Andy, and I’m like, what does that mean?

Mm-hmm. What, what does it mean to take care of it? What’s my authority over it? Well, maybe, maybe towards the end we can start talking a little more abstractly about do we think that, why do we think that is and do, and do we think that’s a good idea? And how do we change that? But let’s stick to your example for now.

Okay. So, so thinking about boundary. Because we did talk about this a little bit, but before we started sitting down and doing this recording right just, just to break that fourth wall a little bit. Yes. We do talk about this beforehand. It is not completely off the cuff. Last time when we were talking about it, it became very clear that you almost had these two boundaries of the consumer system.

And the commercial system, the business system, which then, as you said, they kind of got combined, but when that com combination happened, there was never any clear discussion about, okay, what are the boundaries now? Are you completely combined? Are you really just the same group now? Mm-hmm. Are you just collaborating on this one little piece?

Mm-hmm. Is that your only overlap? Mm-hmm. And because those boundaries weren’t ever discussed, neither side neither of these original orgs that we now know. Don’t know what state they’re really in. Are they one org? Are they not? It’s unclear. Mm-hmm. Didn’t know if they, if they were sharing authority, if one had authority over the other, or vice versa.

Mm-hmm. And so if I recall correctly, a lot of these bugs were kind of coming from the team saying, no, look, that’s still not our priority. Go away and work on it yourself. Is that, is that right? Or am I misremembering? I don’t know if that’s, Exactly right. But other than what you just said around go away and work on it yourselves, that’s not our priority.

I agree with everything else. Let me sort of throw another wrench into the work, something we haven’t discussed. Yep. At one point, the consumer org was approached and said, look like we’re going to the consumer org. We’re going to the consumer world with this desktop application. Like, don’t you think that, you know, it fits into your world.

And the consumer org, or the mobile org basically said the mobile consumer focused org said, that’s interesting, but we don’t really care. You have no users. You have a lot of complexity. You know, building desktop apps requires building its own, you know, built system, for example requires its own debugging system with memory management and whatnot.

I mean, there’s just like, those use cases that you have are interesting, but like, we’re really busy with big numbers right now. Right. Basically that’s really cool, but we don’t wanna do it. Mm-hmm. However, that, what that org did care about was interoperability, right. So, If a feature shows up on the mobile app, it’s a very jarring experience for it to be completely missing on the desktop app.

Oh, interesting. Or if a bug is fixed on the mobile, on the mobile side you know, oh man, this button doesn’t turn red when it’s supposed to. It’s really supposed to turn red. It needs also needs to be fixed on the desktop side. To your point around boundaries, you are right. That the boundaries were, you know, the, the mobile side basically said, look, the boundaries are separate.

Right? We’re separate boundaries. I don’t care about your thing. But interestingly enough, when we get to the A, the authority, they certainly thought that they had some authority. That’s what I was thinking. Right. But if you then go to the t, the task mm-hmm. They’ve rejected the task. Mm-hmm. They, they have, it sounds like explicitly said, that’s not our task, but they want the authority.

Right. Or at least they want. This is super interesting. I think within the realm of Bar, I would absolutely, clearly call it they wanted authority. Authority as a word though often, you know, feels very authoritarian and so, you know. If I were to go back in time and I were to ask these folks, Hey, do you want authority?

Their answer would not be, N would not be, yes. Right? They would use in business speak couching, the language. We want influence. Yeah, we want negotiation, or the magical word. We just want to collaborate to do what’s best for users. So in the paper they say we define authority quite simply as the right to do work.

Mm-hmm. Now, the work that they wanted the right to do in this case was not the right to do the work of the desktop app. App development. Mm-hmm. They wanted the right to do the work of almost product management, but only portions of product management. They didn’t care about all of it, but they did care about certain aspects and they.

They believed that they had the authority or at least wanted to have the authority to Correct. Do that portion of the work, correct? Absolutely. Or to influence that portion. They didn’t wanna do it. Yeah. Yeah. But well, to influence it, to do, to do certain aspects of it, because it sounds like they, they wanted to say, I’m gonna, I’m gonna hold pretty firm on this.

I think it’s, they wanted to do a portion of the product management work, which was to define this feature needs to go in now this feature needs to go in now. Right. Okay. You’re right. That is fair. Yes, that’s true. And. At the same time, and this is where the whole thing starts getting a little wobbly.

Mm-hmm. They rejected the task that the desktop app was really a priority to do. Correct? Yes. Which then, now we’re sitting here like, okay, so they’re kind of unclear what their boundaries are. Mm-hmm. They don’t want the task. Mm-hmm. But they still want the authority. Mm-hmm. And they probably have no recognized role in how this is all supposed to play out.

Mm-hmm. Mm-hmm. So I think I can understand how this got very. Contentious and maybe why people decided to leave it was probably unclear most of the time what, who they should listen to and what they should be working on. Right. Absolutely. I would say if you dug into sort of the next level of details about what people left, you know, the informal conversations around it.

You heard a lot of, we’re not in control of our destiny. Oh, interestingly enough, in the BART paper I read about, they talk about the survivorship task. Is that what it’s called? Let me just, let’s do a quick little here. Search the survival task. Ah, so we can edit that uncertainty out if we want, or we can leave it in.

In the BART paper, they talk about the survival task, right? This concept that regardless of what the formal or informal tasks are, there’s always this unspoken task where a group wants to. Live. Yes, they want to continue existing, right? And I would say that they want to thrive would be the other part that I would add to that.

And I think really that was the crux of a lot of the attrition. When your boundaries are unclear and you don’t feel like your authority is clear, it’s very, and you know, and then your tasks are unclear. It’s very difficult, I think, for people to feel like their groups can survive and thrive. Now we can always ask the question.

Does that group deserve to survive or thrive or, you know, are group’s even important? And like, is survival of one group important versus survival of another group? And I do want to get into this a little bit later. This mythical just collaborate through it type of thing. Mm-hmm. But what Bart would say, and I tend to agree, I don’t know if you tend to agree, I tend to agree that regardless of what you say from the top, there’s this human instinctual nature of belonging and survival.

Mm-hmm. And so if you’re part of a group, you’re gonna want that group to survive. Yeah. And when you don’t feel like that group is surviving, You’re gonna jump ship to belong to a different group. Yeah. And, and they, the, the paper even goes into the dynamics that play between the survival task and other things, and they give names to two other tasks around the survival task.

They have the primary task. Mm-hmm. They say also if it referred to as the functional task or work task, which corresponds with the mission of an organization. Mm-hmm. In this case, the primary task would probably be somewhere along this line of like, creating this thing for desktop. Right. Right. Or creating this.

This thing for mobile and desktop, right? The survival task is, When a group works on a task, members of the group always, albeit mostly unconsciously, very important, it’s mostly unconscious. Have the survival of the group in mind. We call this the survival task of the group. The primary task and the survival task coexist at times.

The survival task is in surface of the primary task and complimentary, but mostly. It is in conflict with the Primr task. And so that survival task of the group, they want their group to continue, can come bring them in conflict with whatever it is they’ve been tasked to actually do. And I love the fact that the paper calls out that it’s almost always in conflict.

I think that is so important. Yep. And then their last form is the process. Task. And the purpose of the process task is to give attention to the survival task without necessarily acting it out. Mm-hmm. So it says it provides an opportunity for members of group to look at their own dynamics, including dependency, pairing, fight flight.

Ooh, I’ll get to that in a second. And oneness Behavior, issues of competition and authority. Interpersonal relationship, trying to understand the meaning of behavior of an individual for the group or group behavior as such. Basically what they’re saying is there is another task that goes on, which is, Almost like how this group operate.

And that’s, that’s actually, you could say that the way the group operates is what the group is and that that how they operate is in service of their survival task, not in service of their primary task. Right. But to do their primary task, they might have to do something completely different. Well, and I want to get to because I don’t think I’ve heard your thoughts around the fight flight and that sort of stuff, so I want to give space for that.

It’s interesting though, because when I read this, when I read about process, task, I immediately thought about retrospectives. Yep. And isn’t it funny that so many companies retrospectives deal with the primary task? Oh, you know, did we ship the product on time? What could we have done to have fewer bugs?

Versus really talking about group dynamics and their survival task, which is. What Bart would say, you know, your retrospective should maybe primarily be about, I think, I think this is an interesting one and maybe something we should talk about even more in another episode about the role mm-hmm. Of, of retrospectives and those process ceremonies.

Mm-hmm. And how they play out. My understanding is that they would say that the. Act of doing that is going to be, no matter how you do it, it’s a survival task. Oh, interesting. Because even though you might talk about that primary task mm-hmm. The act of doing it is about creating that group, about maintaining that group.

In fact, that’s often one of the reasons you do retrospectives is not actually to find those process improvements or what do we do next? It’s to create that sense of belonging. Hmm. I, I hadn’t thought about it that way before. I. I think that’s super valid. That’s a really interesting way to think about it.

I still do think that maybe one of my learnings is that maybe the retrospectives should focus a little bit, it’s more explicitly on survival tasks as well. Oh, I think so. So I know someone who often complains that retrospectives get cut short. And the person, I’ll just, it’s Steve Freeman. Okay.

Steve Freeman. Time Boundaries. Yeah. Steve Freeman would often complain to me. Yeah. About the time boundary, like a retrospective, it gets put in your calendar as this meeting that’ll be 30 minutes long. And what often happens, and you can watch this maybe if you’ve may even even noticed it. If the retrospective starts happening, people like write up their post-it notes or whatever it is you’re gonna be doing.

And at first they are talking about that primary task. They’re talking about, oh, this bug got through. How could we prevent that in this time? Or, I’m spending so much time on code reviews, I, I need to spend more time on understanding what we’re building. Mm-hmm. As you get to the end of the meeting, people then start opening up about how they’re feeling about the work, and then usually just a few minutes later it’s like, oh, time’s up.

So the most interesting parts that take a lot of time and trust, building a safe space or whatnot to get to ends up being the stuff that’s cut at the end. Yeah. Yeah. And it’s like, we’re just getting to the interesting stuff. No, just let it keep going. Mm-hmm. Because generally those things will actually even start answering why are you behaving this way on your primary task?

Right. But they’re uncomfortable cuz they do take that, that place of vulnerability. Well, and that’s why it takes time to get there, right? Yeah. Like you don’t all get into a room and just say, okay, let’s start talking about vulnerable stuff. Like we still have other meetings on our mind and Yeah, I mean, Bart even talks about that like meeting ceremony should naturally address.

Boundaries, right? Mm-hmm. There was a boundary of your last meeting, and to close that boundary, let’s give it closure by talking about it so that we can fully focus on this boundary.

You were talking about these, these groups and their, their kind of interactions with each other. Mm-hmm. And we got to this point where they kind of have these survival tasks that are starting to happen. Mm-hmm. Starting to take precedence in conflict with their primary task, which was to ship this software.

Right. Survival tasks are often according to this paper. The source of off-task behavior, right? So they say off-task behavior can be distinguished in four category dependency, pairing, fight, flight, or oneness. It says in group relations terms, these categories are called basic assumptions.

Dependency is when the group waits for one person to take leadership as if other members don’t have those skills. Mm-hmm. So that, that shows up when they start looking towards like their manager and saying like, you need to sort this out, man. Right. So if you ever, if you ever see that happening on your own teams start thinking why do we have this dependency behavior going on?

Well, and I can say in this particular case, that absolutely happened. Yeah. Hey, good. Hey, you know, we have these weird like mission conflicts like, You know, and, and part of it was, you know, the leadership on the desktop side volunteered to be the people to sort it out. Yeah, yeah. Right. They, they saw that as their primary mission, the most important thing.

But then that caused everybody else to kind of see that dependent behavior and be like, well, I can’t really move in any meaningful way. I mean, I could still do work. Right. I’m still working. Yeah, yeah. Well, since they, I have as if I was an engineer on those teams or someone, and I have now seated that authority.

To address any of these issues to the manager. Mm-hmm. I’ve created that dependency. Right. Well, I shouldn’t take it back. Mm-hmm. So I’m now waiting for them. I’m now stuck. Right. And then the next thing is, and I can imagine it happened in this group, you, you might not know or you maybe do know, is pairing.

Pairing is dependency of a similar, of a slightly different sort. It’s, it’s basically saying there’s a, a group of people or a pair. Who somehow have this magical insight where they can come up with the solution. Mm-hmm. And, and we become dependent on that pair to work it out for us. Mm-hmm. And the way they say it is pairing is when the group uses a pair to produce the solution in the form of a prophetic idea or person, oftentimes this happens in the form of a fight in which may eventually result in some solution.

Mm-hmm. So maybe it’s like, hey manager of the desktop app and manager of the mobile app you guys just get in a room, fight it out, come out with the Oracles saying on what we’re supposed to do here and how doesn’t that happen all the time in these collaboration? Yes. Right. And the other, the other example I see a lot of that is the e emmp impair.

They’re the prophetic. Oh, yeah, yeah, yeah. Problem solvers, right. Yeah, yeah, yeah. The engineering manager, project manager, product manager. Mm-hmm. Yeah. They often get paired up and be like, oh, you guys need to be the oracle for everyone. Right. And organizationally, we even set that up mm-hmm. To, to, to kind of fall victim as an entire group to this survival task.

Absolutely. And then continuing on with these things, we got the pairing, the fight or flight, which is fight is when the group starts to conflict about relatively inconsequential things. They probably had all sorts of little fights about things that just didn’t matter. Mm-hmm. Tabs versus spaces possibly.

And flight is when the group either literally or metaphorically distances itself from the task, for example, by members starting to take personal phone calls during a meeting or by entering into fantasy land and thinking about the next dream vacation. Or literally flight and just leave. Mm-hmm. Can imagine.

And oneness is when the group acts totally undifferentiated, as if there is no difference of opinion, let alone conflict within the group. Right. I, I would see that. I, I would expect to see that in a group that has a strong consensus culture, they, they would get so consumed about this oneness that we are a group, we are, we are in consensus that they would probably start finding it difficult on how do we deal with this conflict.

Well, I think there’s also the other part, and maybe this is that fight flight thing also, but I’ve definitely seen groups where you, you give up that higher level thinking and you only focus on sort of that lower level thinking. So you say, well, there’s all this conflict. We don’t know what to do. You know, the, the feature I was doing got canceled, or the feature I suggested was not prioritized for unknown reasons.

To me, I wasn’t well explained. I’m just gonna be heads down. I’m just gonna focus on my work. Yep. I’m not gonna think about this other thing. And I think that leads to oneness as well. Yeah. It could be oneness or it could be the, the a form of flight. Mm-hmm. You, you are kind of an avoidance behavior. Right.

I’m not going to deal with the fact that I have no clue why I’m working on this. I’m just gonna work on it. Yeah. I think and, and maybe this isn’t what the paper means, I. I feel though it does manifest itself a oneness a lot where it looks like the group is all in agreement because nobody is. Mm-hmm.

It’s not that nobody’s bringing it up, it’s nobody’s even thinking about it. They have avoided it so much that they only focus on things in which they can agree to. Yeah. As a survival, well, these are all survival tasks. Right. But as a survival mechanism. Yeah. Yeah. Yeah, I, I would say I don’t see any reason that these can’t be combined.

Right. That you can’t be doing several of these at once. Right. Especially within a group of multiple people. Mm-hmm. We’ve talked through the whole situation. Mm-hmm. So what’s the summary? Where, where have we gotten, has this, has this BART thing helped understand this a bit better? I think it has. For me, I think.

Way at the beginning we talked about having terms to put to use, right? And so I’ve discussed this situation with a number of people in, in various successes of understanding or misunderstanding. But I think part of that problem was having the right terms, right? And so I think, yeah, using terms like boundary authority, role and task, make it very clear what you’re talking about and to help diagnose the situation.

And I think that, It’s also helped understand why things might have gone so wrong. Right. I think it’s very clear, at least to me, that the boundaries were unclear. And let’s go back to something that you said in the paper, which I really, really liked. Around the explicitness of the boundaries. Were the boundaries clearly specified?

Were they agreed upon and were they adhered to? It’s very interesting. I would say that maybe, maybe the first two were actually true, but the third one was not. Mm-hmm. And so then I would say, well, were they really agreed upon or were they only agreed upon, you know, in spirit or by fiat or whatever, or, or whatever.

Yeah. Or clearly defined by Spirit or fiat or whatever. Yeah. Were, were they, were they agreed to simply to avoid conflict. Exactly. And so I think, you know, there were definitely boundary issues here. Clearly. I think those boundary issues led to authority issues. And then of course, the unclearness of the task, I think is prevalent throughout this example.

So I think that, actually, I don’t know if you agree, but I think that gives us maybe a framework for how to avoid these situations in the future or improve these situations in the future if it comes up. What do you think? Yeah, yeah. I, I think absolutely next time it comes up, just thinking about like, okay, what am I seeing happen here?

Can I explain it Through boundaries not being clear. And then if, if it’s happening at the time, we would actually have the advantage of being able to go and ask people, what do you think your boundary is? Mm-hmm. Whereas right now, I can only interrogate you. Right. But if it was happening in a group around me, I would be able to say, okay, what, what’s the boundary going on here?

Or What authority do you think that person has? And what do you think having asked those questions and gotten those answers in real time, then, then what? So then this goes to a thing that I believe about organizational setup and design. It’s about alignment. Mm-hmm. It’s, it’s not to say that I’m right and they’re all wrong.

Mm-hmm. But it’s to, to get to that agreement about, okay. What do we agree about the boundaries? What do we agree about the task? Actually, I’d probably start with the task. Mm-hmm. Because everything else is really gonna start flowing from that. Mm-hmm. Mm-hmm. What’s our primary task? All right. What are the boundaries that make sense to achieve that?

Mm-hmm. What are the as, what is the authority you need to achieve that within those boundaries? And those will play between each other. And then do you all have the right roles to actually do all of this? And then kind of like through that, build that alignment about how is this all set up? And probably, ideally even write it down.

Mm-hmm. Say this is what we’ve agreed. It may be wrong in the future when we’ve learned more about the situation, but at least we can go back and talk about it in the future, what we think we agreed. So I would say that it gives us that structure to identify, diagnose, and then correct. I, I think this was a really interesting discussion.

A, as these often are, but like, I think, you know, we love everybody else’s thoughts too. What do you think about Bart? Do you think that this could, now that you’ve heard about it, could help you analyze, diagnose, and fix problems in the future? All right, moncho. See you next time. We’ll have another interesting discussion.

Absolutely. Take it easy, Andy. Good talking to you as always.