Show Notes
Andy and Mon-Chaio contemplate how often team boundaries should change, what impacts changing boundaries has, and some tactics for making boundary changes easier.
References
- Forming, Storming, Norming, Performing – https://en.wikipedia.org/wiki/Tuckman’s_stages_of_group_development
- Amy Edmundson, Teaming – https://www.amazon.co.uk/Teaming-Organizations-Innovate-Compete-Knowledge-ebook/dp/B007MF3BRA
- Dunbar’s number – https://en.wikipedia.org/wiki/Dunbar’s_number
- Matrix management – https://www.liveabout.com/matrix-management-2276122
- XP central tenant – https://martinfowler.com/bliki/FrequencyReducesDifficulty.html
- Gore – https://www.fastcompany.com/51733/fabric-creativity
Transcript
Andy: that curiosity and empathy is needed from the leaders as well to understand what dynamics they have. Understand why that’s happening and have empathy for the choices people are making.
Hello and welcome to the Tactics for Technical Leadership Podcast. The podcast where we discuss, evaluate, and teach how to be a better technical leader in a technical organization. I’m Andy.
Mon-Chaio: And I’m Mon-Chaio. Thanks for joining us again. If you recall to listen to our last episode, we talked about boundaries and how we could use Model called bart in order to assess what’s going on within your organization around relationships. And bart, stands for boundary authority, role and task. And we can use those four pillars to think about things that are happening in our organization for good and for bad.
Did I just about cover it, Andy?
Andy: Yeah, I think that’s a pretty good overview of it. And today I believe we were gonna be talking about boundaries a bit more. Is that right?
Mon-Chaio: Yeah. Right. What we ended off last time was on, I felt like a very interesting question, which I posed to you. So, let me summarize again, kind of the end of our last episode. We basically ended by saying, Hey, it’s important to use Bart to assess situations. And if you could do that in real time while the situation is happening, you could even start to write down your agreements around, Hey, what are the boundaries?
What are, you know, the, what is the authority or what authority is given to specific parties within your organization? Which I thought was very, very interesting. And so I asked you, Andy, at that time, how long do you think these agreements that you write down should last? Is it okay if they are very transient, you know, they last for a day or two days?
Or do they really need to last longer, weeks, months, years in order to be useful?
Andy: So my take is that there’s no one answer and I think that’s a bit of a cop out in some ways, but it’s also the truth. It’s the, it’s the famous, it depends,
Mon-Chaio: Mm-hmm.
Andy: And my way of thinking about it is that you could say at the organizational level for an established organization, Their, their boundaries.
There’s their roles, their tasks, like the organizational task, if we’re talking about across all of them. But I think we’re gonna concentrate more on boundaries for this discussion,
Mon-Chaio: Mm-hmm.
Andy: Are kind of fixed, like you can even say that, like the boundary of the organization that’s pretty long lived. Who’s in that organization and who’s out in terms of a company?
Mon-Chaio: Right.
Andy: So, so some, some of these are gonna last a really long time, possibly the life of the whole company. And some will not last very long. So within that company, you might have a team for platform work and a team for platform work on a particular migration
Mon-Chaio: Mm-hmm.
Andy: they’ll have a, a boundary. And that boundary may last a few weeks or a few months.
Mon-Chaio: Mm-hmm.
Andy: So I, I would say they’ll vary quite a bit.
Mon-Chaio: Yeah. I I, I do think that makes a lot of sense. Bart is very large, right? It’s just one heuristic and you can use it to analyze sort of the interrelationship at a company level, right? All the way for a th 30 or 40,000 person company. Or you can say, look, I’m gonna use it as a heuristic to analyze the relationships and working dynamics between a three or four person team. And so, At those differences in scale, it absolutely makes sense to say it depends on how long those can live. But I’d be curious to think about and to discuss whether there’s some other sort of heuristic that we can use to say, look, you know, at an org of this size, or, you know, a team of this type of responsibility requires either a longer lived or shorter lived boundary.
And again, to remind listeners who may or may not have listened to the last episode boundaries are super important because oftentimes authority, role, and task flow from what those boundaries are.
Andy: To think about those heuristics , let’s start going through a few. So I would say one heuristic is how central to the mission is that boundary. And so, so in that you could say like, well, the boundary of belonging to the company or not is pretty central to that company operating in its mission.
Mon-Chaio: Okay.
Andy: So it, that one can’t change very often.
Mon-Chaio: Mm-hmm.
Andy: But whether or not I’m on the Avengers team or I’m on the silver surfer team thinking of one set of team names used by some teams that I worked with
Mon-Chaio: Interesting. Okay.
Andy: that boundary isn’t actually all that tied to the mission of the organization.
Mon-Chaio: Mm-hmm.
Andy: And so that one can change pretty often, pretty easily.
And so, so I would say there’s one axis there of like, how, how central to the mission is, is this boundary.
Mon-Chaio: Mm-hmm. Okay. That’s interesting. Let’s dive into that a little bit more, because I think there’s a lot to discuss there. It feels like what you just said, and do correct me if I’m wrong, is that team boundaries, who, you know, I as an individual developer, do I belong to Team X or Team Y? You feel like those can change frequently? Yes or no?
Andy: I do, I actually do believe that those can change quite, quite often. Your question makes me think that you believe that they can’t change quite often. Is that right?
Mon-Chaio: I don’t know if that’s true, but let’s say for the moment it is because I do tend to lean more towards stable teams in some, in some ways. And so let’s, let’s, I don’t want to use the word debate. Let’s discuss this a little bit.
Why, why do you feel like. Well, maybe, maybe I’ll start,
I have maybe what is an older school belief or, or what I, I don’t know how to state it, but so, so I’ll start. So I think teams need to be longer lived because I believe that there’s team dynamics in play that surface the longer you’re with people. We hear a lot about forming, storming, norming, performing in terms of saying, Hey, when a new team is built, you know, first they’re formed, right?
And then they storm. And that storm is really important and I think lasts a long time. And a big part of that is how do you work with all of these members of your team? What are the rituals that you are creating personalities and, and how do you mesh them? That sort of a thing.
Andy: and and I would say not only can it last a long time, but it can be exhausting. It can be personally a huge a drain on people as they find these things that they thought were just accepted and they discover that the people they’re working with don’t believe the same thing.
Mon-Chaio: And there’s a reason they call it storming, right? I, I I don’t remember, or I don’t know actually who came up with this term, but I really like that second one storming, cuz I think it captures it so well you’re trying to get something done, but it’s like a storm is brewing within in, in your midst and you feel unproductive at times, right?
You feel broken apart at times. And so that part I can see how also makes it feel very frustrating. So, The forming, storming, norming, performing thing. There’s been a lot of research done on sort of the neuroscience of trust and how do you decide who to trust and how important high trust organizations are. And a lot of these things lead me to believe based on what I read and what I’ve seen, that the longer an organization of a group of people are together, the better they could weather these things and, and strengthen the important connections and sort of ignore the unimportant connections.
And so that is my bias for longer living teams.
Andy: And I agree with everything you say, and I just, I think I diverge in what that ends up meaning. So I agree that there is, in the act of putting a team together, there are these, these stages that can be very draining.
Mon-Chaio: Mm-hmm.
Andy: But I don’t take that to mean that we should then hold our team boundaries very fixed for a reasonable, a long amount of time. I won’t say reasonable, cuz each one of us will debate about what reasonable means.
Mon-Chaio: Mm-hmm.
Andy: And the reason, and my thinking is if it hurts, do it more often. The old XP saying
Mon-Chaio: Yeah. Okay.
Andy: so, so if you’re, if, if, if pairing switching pairs is difficult, switch pairs more often.
If writing those tests is difficult, write those tests more. If running your tests is difficult, run them more often.
And in doing that, if you pay attention to what happens in doing that, then you can get better at doing it. I remember Mon-Chaio, when we used to work together as programmers we would get, we would do pair rotations.
I believe at one point we had on the whiteboard this whole matrix of you, me, and the other developers. And we’d make sure that we’d gone through and paired with everyone and then we’d count the number of times with each person and we were trying to even that out, make sure we were kind of moving around.
Mon-Chaio: Mm-hmm.
Andy: And one of the things that happened, if I recall this properly, I don’t know if you remember, remember it the same way, was that we came across a wider group to a norm about how we operate.
Mon-Chaio: Mm-hmm.
Andy: So here’s the way I think about it, is that the teams that people are a part of can be much larger than the teams that they often get put into.
the wider you can make that team boundary, the more options the business has to achieve that central objective, which can’t change very easily.
Mon-Chaio: Mm-hmm.
Andy: So,
so so we, we should aim to make those boundaries fairly wide and. Not, not like do this at people’s mental health, at the expense of people’s mental health.
That would, no, that would be terrible. That would be a way of burning out your, your, your teammates and your employees and like throwing them out of the bus constantly because you’re just churning through them. I do not want that.
Mon-Chaio: Right.
Andy: we should, we should kind of question that and say, okay, like in the forming, storming, norming, performing model,
Mon-Chaio: Mm-hmm.
Andy: What’s the storming coming from?
Mon-Chaio: Mm-hmm.
Andy: Some of it may be completely essential
Mon-Chaio: Mm-hmm.
Andy: In how something happens. I’m, I’m having a hard time thinking of something that would be essential for that at the moment. That can’t be trained for people to handle in a different manner.
Mon-Chaio: Right.
Andy: And, and to, in my mind, this comes to the central tenant of, of teaming.
Are you familiar with teaming from Amy
Mon-Chaio: Yes. Yes I am.
Andy: Okay, good. Because the central thing of teaming is, look, we constantly are being put in new teams, and we need to just get good at forming teams.
Mon-Chaio: Mm-hmm.
Andy: So, so that’s my, my thinking about this, which is why teams aren’t necessarily a long lived thing. Do, do you, do you believe me or, or sh do we need to go a bit more?
Mon-Chaio: I think as we talk through it there, there are the nuances there. I do. I like what you said, which is we should aim to be part of a larger team. I like that. And I think that is really important. And I, what I wanna do is I wanna put a pin in that because While I believe in that, I think that there are some boundaries that we should discuss around how large is that, right?
Because a lot of companies will say, well, I’m an 80,000 person company. Your team is the 80 person, 80,000 person team.
Andy: Yeah. Which, which on the surface you’re kinda like, really, really?
Mon-Chaio: and there’s, there’s things to talk through on that which I hope we’ll get into if we have time. This idea of and maybe we actually covered it on the last episode, I can’t remember a little bit. This idea that, you know, you should always do what’s best for the company, right? And so we talk
Andy: into that. But that is a very, and, and I think I, I think that does start creating a barrier for some of these things.
Mon-Chaio: Right? I think it’s very interesting in the context of survival tasks where when you say, Hey, but if your team is the size of the company, then your survival task is the survival of the company. So it doesn’t matter if you’re doing a survival task.
Right? But let’s get into sort of the sizes of that and how teams can reasonably be, and then whether we need to create boundaries there. I did wanna touch on two points that you said that I thought would be good to discuss. I do agree with the Central XP tenant. You might not be surprised because we both kind of grew up in that world, right?
So of if it’s more difficult, do it more. But I only agree with that insofar as the more you do it, you can actually make material improvement
Andy: Right. Don’t, don’t do, don’t, don’t set yourself up for failure to say like I’m trying to think of something. Don’t don’t put yourself into harmful psychological positions constantly. Just because you think that you should do it so that you get better at it, like you might get a bit better at it, but it’s also irresponsible for yourself to put yourself into those positions, or for your manager to put you into those positions.
Mon-Chaio: right. I think for yourself and your team. Right. And you mentioned the manager. Right. And I think maybe one part in which we differ, you mentioned that perhaps there’s some parts of the storming part of the forming, storming, norming, performing cycle, which are actually positive insofar as you discover that you may need to do it, or you discover you may optimize that out and have a different way of
doing it. I tend to think that a lot of that cycle is not that,
Andy: Okay.
Mon-Chaio: that it’s a lot of Stuff that you can’t happen, sorry, stuff that you can’t help but happen when any group of new people get together. And that the idea should be to optimize that cycle down to as little as possible. And I don’t know that doing it more helps you materially optimize that down
Andy: Okay.
Mon-Chaio: for your group.
Andy: Okay.
Mon-Chaio: And what’s very interesting is in my experience, I have seen people wrestle with this a little bit. They want to do a lot of these types of matrix organizations where, you know, you have a, a group of UI developers and they go work on something for two weeks or two months and then they switch and work on something else for two weeks and two months.
And they have found.
Andy: And just to, to clarify for listeners who don’t know what a matrix organization is.
Mon-Chaio: Good point. Good point.
Andy: A matrix organization is one where essentially, way, a way to think about it is you have two managers at all times. You have your, your kind of like your team manager, your discipline manager, so ui, ui, ux, and then you have your project manager.
Mon-Chaio: Mm-hmm.
Andy: the benefit of doing this structure is that you can always pull people onto your project. As long as there’s resource available, you don’t need to worry about these team boundaries. The downside of it is that the project manager and the team manager will sometimes work at odds with each other,
Mon-Chaio: Mm-hmm.
Andy: and so it can put people in a bind because they’re the one that gets the pull.
Mon-Chaio: And I would say that there’s a little bit. There’s more downsides as I’ve seen organizations grow larger and longer lived. So one downside, which we’ve kind of touched on already in this episode is around personality conflicts. So inevitably as your practice practices get larger, you have more UI developers, you realize that Jane doesn’t work so well with Joe.
Andy: Yeah.
And and I
Mon-Chaio: then you start,
Andy: I was gonna say, and I think that gets to what you were talking about earlier, which is like, at what size does this start falling apart?
Mon-Chaio: right.
Andy: and there’s those kinds of things, just humans, society things where we don’t get along with everyone. We can’t, we, we just can’t stand some people.
And so like saying your team is 80,000 people in, of your tech organization, in your 500,000 company, it’s a bit laughable that you should consider that whole thing. Your team
Mon-Chaio: It could be like, let, let’s discuss that more. But I think You know, the other part of matrix organizations that I’ve seen people find really challenging is around ownership, accountability, responsibility.
So if you have a UI engineer go and make three screens, and then they go off on another project, what happens when there’s bugs on those three screens?
What happens when a different UI engineer comes and fixes those bugs and who’s, you know, do you have a sense of ownership and accountability? Now we could debate whether that’s important or not but the fact that, yeah we could debate whether that’s important or not.
Andy: I, I think, I don’t think I think it is important that people feel that, and it, it is one of the limiting factors as well in the, like, what’s the size of this boundary and how fast can it
Mon-Chaio: Aha. I, I, and I tend to agree, I think we’re already sort of diving in that maybe one. Of the limiting factors or heuristics around what is the right size of this boundary is, can you feel ownership or do you feel accountability? And can you possibly feel ownership and accountability to 80,000 other people
Andy: a absolutely, in, in my mind, so I’ve, I’ve often latched onto the thing that’s called Dunbar’s Number,
Mon-Chaio: Mm-hmm.
Andy: which says basically humans can have social, strong social interactions or social connection to about a hundred people. I don’t remember the exact number. I think it’s 120 plus or minus some, some number, which would say, yeah, the, the 80,000, you’re not gonna be able to have a strong social connection to that, but you can have a strong social connection to much more than like a standard software team of say, 10 people.
Mon-Chaio: I mean, it seems like this conversation is moving on direction and it seems like we have momentum there, so let’s take it
Andy: Yeah.
Yeah.
Mon-Chaio: I like that you brought Dunbar’s number into this because I do think about that a lot as well. But I think it’d be very interesting to think about why, why is it that we can’t form connections with more than a hundred people?
Because I think if we sort of dive into that, that’ll sort of get us into the crux
Andy: Okay.
Mon-Chaio: of why do people think about teams and team boundaries?
Andy: So why, why, why do you think it is?
Mon-Chaio: I think it’s because it’s very difficult to keep in mind the social nuances that are important for building strong relationships with more than that many people. And I would say it’s probably even a lower number of people. So for you and I, right, I mean, we’re a little bit closer. We do a podcast every week. But as I look at your face, I can sometimes tell, oh, is he waiting to speak?
Is he unhappy? Is he not unhappy? You know, does he want to go down this, this topic and those nuances plus others, right? Like, do they like to celebrate their birthday? Do they like surprise parties? Are they vegetarian? Like, I think all of those are important in building human relationships. And I think what I would posit is that it is the human relationship part that makes a team.
You have to feel related
Andy: Yeah.
Yeah. you have to feel
that. You have I’ve heard a definition of teams as they are groups of people who share a problem
Mon-Chaio: mm-hmm.
Andy: And that’s kind of like part of the feeling related that you share, you share a problem and it, if you don’t feel related, you won’t feel like you share. You may actually, like, from the business perspective, share the problem, but if you don’t believe it, you’re not gonna feel like you’re on the same team.
Mon-Chaio: I think the nuances are interesting here, and maybe they’re not, and we’ll edit this out. So if I’m a CEO of, let’s not even call it an 80,000 person company, let’s just say we’re 500 people,
Andy: mm-hmm.
Mon-Chaio: right? If I’m a CEO of a 500 person company, I, or even a 70 person company, as we all work, we worked together at one where the CEO was very fond of saying, you know, you should all think about the company, right?
We’re solving such a big problem. You’re all members. And so why is it that we can’t all share that problem? Right? The problem being, hey, we’re trying to accomplish a business goal. You know, that’s a problem we all share at the company size.
Andy: To me, this brings us back to the storming and some of the tactics that you can use for shortening it.
Mon-Chaio: Mm-hmm.
Andy: And, and it basically for me comes down to transparency, curiosity, and empathy. So the transparency is, Is needed to make sure that, that the information about how everything is going or what’s what’s relevant is, is available.
Mon-Chaio: Mm-hmm.
Andy: The company you’re talking about, I think there was some transparency missing at times where it would be like, what are we talking about?
Mon-Chaio: Uhhuh
Andy: We don’t know.
Mon-Chaio: and why, and we’ll, we’ll get into the authority autonomy stuff later, but yeah.
Andy: And then the curiosity,
Mon-Chaio: Uhhuh.
Andy: the curiosity is necessary so that when those unexpected social interactions come up you’re able to sit there and think beyond your judgment to more of a curious state where you can say like, why are they doing that?
Mon-Chaio: Mm-hmm.
Andy: To maybe elicit more information that wasn’t considered relevant at the time, but now because of your curiosity has turned into, oh, it is relevant in information.
Mon-Chaio: Mm-hmm.
Andy: So it might be that. I’m used to a team lunch every, every week. And Mon-Chaio, you just never attend.
Mon-Chaio: Mm-hmm.
Andy: why not? Maybe I’ll ask you.
Why not? And you’ll tell me. I don’t eat lunch
Mon-Chaio: Mm-hmm.
Andy: and be like, oh, okay, well maybe we can do something else.
Mon-Chaio: Right. Right.
Andy: that kind of thing. And the empathy, the empathy is needed so that when I get that answer, rather than responding, you don’t eat lunch. What the hell’s wrong with you? I can say, oh, he’s made the choice.
He doesn’t eat lunch. Great. Well, what, what does he enjoy that we could maybe get together to do?
Mon-Chaio: Mm-hmm.
To bring us back, you, me, you mentioned this because you said, Hey, we can shorten the storming part
Andy: Yeah.
So,
Mon-Chaio: three,
Andy: yeah. So, and, and the reason, yeah. You can, you can shorten it because I think a lot of the storming is coming about because these distressful discoveries happen again and again, and then get dwelled upon rather than quickly resolved.
Mon-Chaio: And so I think this is where I disagree with you. I, I agree that if you use your You’re heuristic we can reduce storming because I do agree that your central tenant is a lot of these these distressing discoveries as you, as you mentioned. Where I disagree is that I don’t know that you can materially shorten them because I think a lot of what you talked about around things like empathy and curiosity, that starts with trust
Andy: Mm.
Mon-Chaio: this is a whole nother episode.
But there’s been a lot of study done on trust, right? And one, I’ll just bring in one thing cuz I think there’s two or three papers I like to talk about when I talk about trust. But I’ll just bring out one thing. They did a study and they showed that organizations who use chat perform better when social chat is intermixed with work chat.
Andy: I can believe that. Yeah.
Mon-Chaio: And so, you know, if you have a separate social channel that doesn’t, that doesn’t have any correlation, About how, how, how widely that channel is used with organization performance. But if it’s well interspersed, it does. There’s a lot of other different or conclusions to draw, but like to put the cart before the horse building deep trust is difficult.
And it requires, it requires a lot of work. It requires knowing people deeply. And so when you’re thrust into a situation in my mind where you have to spend two months with a specific person,
Andy: Yeah.
Mon-Chaio: like your timeline is not gonna allow you to build trust, you’re gonna be in that storming phase because you haven’t built trust.
Andy: Yeah, yeah, yeah.
Mon-Chaio: I don’t think there’s any way to eliminate that.
Andy: Can I, how do you define trust to you? What, what is trust
Mon-Chaio: Hmm.
Andy: to make sure that we’re discussing the same thing.
Mon-Chaio: Yeah, and I’m not prepared exactly to have this discussion. There is there is like two types of trust and I’m gonna butcher it cuz again, I don’t have all of the stuff in front of me. But there’s like this, this thing, I think I would call it like transient trust, which is just like the, the ability to trust someone from a task on a day to a day basis.
And then there’s this concept of like a longer lasting trust which is, you know, you may f up this task or whatever, but I still trust you can do the right thing. And I think what, what we, what we aim for, for higher performing orgs is building that longer term trust. Cuz the short term trust is easy to build, right?
I can put a matrix together for you. I can write down your accountabilities and I can say, Hey, you met these last week, you met these this week. I’m starting to trust that you can do that. Right?
Andy: Yeah. I mean, in some ways it’s like what a, what a, a CV is. You can, you can trust me that I can do your job because I’ve done similar jobs in the past, is what you’re, a thing you’re trying to get to in that is get that going a bit faster.
Mon-Chaio: Right. And so I think in the storming model, you can use that short term trust to build trust all you want. Right. And I think,
Andy: But the long-term trust will be missing. That kind
Mon-Chaio: and that will cause
Andy: it’s almost like one is almost like a, a task trust. I, I trust that you could do this task. And the other one’s more of, I, I might frame it as a judgment trust.
I, I trust your way of thinking,
Mon-Chaio: I, I think that’s a reasonable way to put it.
Andy: considering
this is the first time I’ve heard this, this this distinction. I’m, I’m trying to fit it into my way of thinking at the moment. So.
Mon-Chaio: yeah. Yeah. And I mean, I, I think it’s more You know, me and, and listeners will slowly know, I, I like to talk in grandiose. I, I like to think in terms of, you know organizations and concepts and stuff. But it is about, I I, I think about it as trust of yourself as a human being in everything you bring to the table,
Andy: Hmm. Yeah, and I think that’s really important. And getting back to the, the boundaries I think that, I think what we’re kind of getting around here is
Mon-Chaio: Mm-hmm.
Andy: the, the. The biggest limiting factor on how often you can change your boundaries is going to come down to these human factors.
Mon-Chaio: Mm-hmm.
Andy: It’s going to be the, the trust people have in each other, their ability to, to socialize and, and, and to build that trust and to know each other.
And we both think we have some tactics that could help that, but we are, it, it’s, it’s kind of the big unknown. And I think that is one of the things is that when a boundary gets changed, if we want to move along a little bit here,
Mon-Chaio: Mm-hmm.
Andy: when boundaries change, it can be a very distressing time.
Mon-Chaio: Yeah.
Andy: instance, like to talk about probably one of the most distressing boundary changes is a merger or acquisition of a company.
Mon-Chaio: Mm-hmm.
Andy: I went through this twice working at Tim Group
Mon-Chaio: Mm-hmm.
Andy: to, to name a place that I’ve worked where we got bought by a company, and then that company got bought by another company. And one of the things that happened was a complete quite a confusion about boundaries.
Mon-Chaio: Mm.
Andy: So, and this was an interesting one, it was actually very distressing for the people at Tim
because, We didn’t really know what they wanted from us.
We didn’t know where the boundary was anymore.
Mon-Chaio: Okay. Give me, gimme an example.
Andy: So the the software team in Tim had very much this Change our team boundaries all the time. Approach. Yeah. And so the way that the group decided how to change its, its team boundaries was based on what are the problems that are currently the focus for the organization?
Mon-Chaio: Mm-hmm.
Andy: And how do, how do we fit into that?
So as the development team, where do we fit? So like if, if the focus is going to be on account management and sales, the developers wouldn’t say like, okay, we’re gonna jump onto account management and sales. They’d say the, what could we do as developers to support the sales and account managers to do what they need to do?
Mon-Chaio: Mm-hmm. Sure.
Andy: And we might build a team around that. We might say, oh, there’s one lead developer needed to go and scout out some work and, and define what needs to happen next. Or actually what we need is a team of four or five with these skills. To build up this new feature to improve the workflows of account management.
So that was kind of the way that they worked. At a very high level, you do the merger or the acquisition. And now as I was saying before, that kind of like company boundary has been broken because you’ve been bought by another company that you’re gonna be part of in some
way. So the very first thing that the team started doing was going out and asking how can we, how can we use our specialties to assist this company?
Mon-Chaio: Okay.
Andy: And yet that company didn’t want that. They said, keep acting as though your boundaries are still intact.
Mon-Chaio: Mm-hmm. Okay.
Andy: Without using those words,
Mon-Chaio: Right, right.
Andy: they said, keep doing what you do actually. So, But with that was confusing because what they did was constantly redefined their boundaries to work on what’s the most important problem.
Mon-Chaio: Hmm.
Andy: And so that, that’s kind of like a story of, of boundaries and, and all of that. And one of the things that came out of that was some people, some people were quite willing to just say, okay, they don’t want us to do this. Others were a bit more upset. They’re like, but we can see that you need help in this area and that we could use your data to do this. Why don’t you want our help?
Mon-Chaio: And grounded a little bit. And Tim Group was how large and how large was the acquiring company?
Andy: ah, yes. So I’ll, I’ll stick to the size of the development teams since
the, the the larger companies are quite different in because they’re very different kinds of organizations. Tim was a team of about 15 developers.
Mon-Chaio: Okay.
Andy: And the other company was a group of about 80 developers.
Mon-Chaio: Mm-hmm. Okay.
Andy: So a, a, a size difference, but not insurmountable size difference.
Mon-Chaio: Yeah, I think you’re right. Mergers often are times when. I Think there are there’s a lot of churn, right? Not just in the forming stormy norm, you’re performing, but even if we go all the way back to Bart, your boundaries are changing. Your authorities, your granted authorities, and you know, are changing.
Your roles and tasks are changing and you know,
Andy: You’ve lost
tr you’ve lost control over your it, you don’t have authority over your IT anymore. Possibly.
Mon-Chaio: And often people are wary of sort of laying it out explicitly and feeling like too, there’s too much command and control and, and whatnot. But that’s probably what’s needed.
Andy: And I was gonna say, and I, I think I’ve always heard a rule of thumb that after a acquisition
you should expect about 30% of people will just decide to leave.
Mon-Chaio: Mm-hmm. Yep.
Andy: And I think one of the reasons, going back to the what we were talking about with the, the identity and the social issues and all of that around how fast can you move boundaries.
I think one of the reasons is because what happens during those acquisitions is that suddenly that boundary that has not changed for people felt like the most stable of all of the boundaries has changed on them.
Mon-Chaio: Mm-hmm.
Andy: they’re now at this point of asking themselves, do I want to go through that for this new boundary?
Mon-Chaio: Mm-hmm. That makes sense. So maybe maybe I can summarize a little bit about what we kind of agree to, maybe what we don’t and then what we want to discuss for this last part of this episode.
It feels like we’re aligning to a point where we’re saying there’s a lot of different types of boundaries.
We know this we talked about this last episode as well. And I feel like we’re aligning. We’re saying, Hey, boundaries can change all the time. Up until you hit that. Trust that long-term trust boundary, whatever that is.
Andy: yeah. I, I
think I
Mon-Chaio: once, once you get there, you don’t wanna change the long-term trust boundary all the time.
So whatever that is, whatever size, whatever heuristic you use. Right. Is that about, does, does that sound about right?
Andy: I think that sounds right to me and I, and putting it that way. I really like that. I like it because it gives it a name, what we’re talking about, but it also hints at that’s another boundary that no one has defined or talked about, and you could almost say, can’t be defined or even clearly talked about because it’s going to be so hard to figure out where it is.
Mon-Chaio: You are right. And so I would propose that we spend this last part of the podcast discussing and maybe giving listeners a. Some heuristics about how they might be able to figure out where that boundary is in their organization. I think we talked about one, or you talked about one being Dunbar’s number.
Andy: Mm-hmm.
Mon-Chaio: Right. And perhaps that’s the easiest sort of base level thing where you can say, look, if your org is above the Dunbar’s number, like that org should not be changing all the time. Like that boundary of that org or those people, let’s not even call it org. Those people should stay together as long as possible.
Andy: And I know what is it? Gore, the Gore Corporation as far as I understand, I could be wrong. They actually organize around that. They create their, departments, their, their groups based on that number. And if it, if that group starts growing too large, they’ll split to make two new ones because they believe that number so much.
Mon-Chaio: Interesting. And, and I don’t know what the Gore organization does.
Andy: Gore- Tech Goretex.
Mon-Chaio: Oh, go. Oh,
Andy: Yeah. That, that company.
Mon-Chaio: Okay. Not a technical organization, but still an organization. Nonetheless. And when we talk about these things around trust and boundaries, that that’s not confined to technical organizations, right?
These lessons can be learned throughout.
Andy: Yeah. So, so definitely Dunbar’s number. Do you have, do you have any other heuristics or ways of identifying where that boundary is that you can think of?
Mon-Chaio: I use one and I think it’s it’s probably a little more nuanced than Dunbar, but it’s still a little bit difficult and will be applied differently to different situations. So one thing I talk a lot about when I talk about org building is an organization and let’s. Not discuss right now exactly what it means by organization, but a group of people, an organization needs to be able to have what I call the triple A’s.
They need to be able to have authority over what they work on. They need to be able to have the autonomy to do the work the way that they want to, and they need to have accountability on what they produce.
Andy: Okay.
Mon-Chaio: And I think a lot of that really is around trust, right? So for an organization to have aaa, people within the organization need to have deep trust within each other to say, look like we can work together to create our own autonomy, right? We can work together to define how we’re gonna work, what we’re gonna work on, how we’re gonna achieve our goals.
Andy: Right. So your assumption in AAA is that there’s close collaboration to enable that within that group.
Mon-Chaio: Yes, absolutely. Absolutely. Within AAA group, people need to have close collaboration in order for that group to function in a triple A manner.
Andy: Right. Okay.
Mon-Chaio: And in order to have strong collaborations, you need to have that long-term trust between members. And so that’s often how I think about it. I think AAA organization, whatever that is, needs to be long lived. Below that you can shift as much as you want. But people already know where they’re being shifted into, right? Like, let’s say it’s a hundred person organization and let’s say those a hundred people already have deep trust within each other.
That’s what makes them a AAA organization. Then you could say, well, Jane and UI work with Joe from platform. That storming part
is
Andy: basically is done already. They, they already know how they work.
Mon-Chaio: Absolutely. And so then from a business context, I often think that you take AAA organization, whatever size that is or whatever, and it can be different sizes, right?
Some AAA organizations are 20 people because of the type of work and their, their expertise and the type of personalities. And some could be 50 people or whatever, but you have these AAA organizations. And then I think in order for them to truly have AAA and be autonomous and have accountability, and have authority, they need to have a KPI or some sort of O K R that they are responsible for, and then have the freedom to execute how they need to execute,
Andy: Mm-hmm.
Mon-Chaio: And so then I start to think about, because those orgs have to be longer lived, The KPIs also need to be longer lived. And so we start to arrive at this way of building organizations where you say, what are, what is my company’s longer lived KPIs? I might change my tactics. Right? And maybe this is more difficult for a startup, which is according to some people, if you do it right, can change your product every day based on customer feedback but for most companies, beyond the initial stages, you kind of know what your central tenants are. You’re selling something, right? So you have a, you know, you have a team that has to do sales or e-commerce. You’re shipping something you have to ship, right? And so I think then you start to, I would say my guidance would be you start to think about your long lived KPIs, those ones that don’t change regularly, and then you attach them to long lived teams that have aaa. Does that make sense or,
Andy: I think so. I don’t think it quite got to the, how do you identify that long live trust boundary, or maybe it does, it, it’s, it’s more of like, how do you design, I think you were going more along the lines of how do you design where that trust boundary will appear.
Mon-Chaio: right?
Andy: And what I was thinking was how do you identify where it is?
Mon-Chaio: Mm.
Andy: Because once you’ve designed where it will appear, where you want it to appear, it may not necessarily appear there. It may be that within that AAA group, they found a way of working as two separate trust boundaries.
Mon-Chaio: Yeah.
Andy: And so, and what I was thinking, the way I was thinking about it, I, I love your idea though. I think that gives great guidance on like, okay, this is, this is how you can think about structuring a group.
Mon-Chaio: Mm-hmm.
Andy: What I was thinking was that if you wanted to diagnose, where has your trust boundary appeared
Mon-Chaio: mm-hmm.
Andy: You alluded to it earlier when you mentioned the social interactions, the social chat, social chat being interleaved with work chat.
Mon-Chaio: Mm-hmm.
Andy: I think it’s you, you map out social interactions. Basically, you pay attention to who, who spends time with whom,
Mon-Chaio: Mm-hmm.
Andy: and that will start giving you the clusters.
You can think of this a bit like a data science problem and it’s a clustering problem.
Mon-Chaio: Right.
Andy: how do you cluster. People together based on the data of that they trust each other. Well, the, the one of the biggest indications that they trust each other is that they’ll willingly interact with each other.
Mon-Chaio: Mm-hmm.
Andy: So you kind of have to make a little bit of a distinction between willing interaction and task desired or task needed interaction.
Mon-Chaio: Absolutely.
Right.
Andy: yeah, I may have to work with you, Mon-Chaio,
Mon-Chaio: Mm-hmm.
Andy: but outside of that, I don’t want to have anything to do with you.
Mon-Chaio: Right.
Andy: And, and so it’s, it’s paying attention to that. And this is one of the things where, I mean, you could go entirely data science on it. You could go like, okay, we’re gonna track down who, dms whom, and, and all of
Mon-Chaio: Mm-hmm. Mm-hmm.
Andy: or who, who ats each other who, who reviews, whose code who comments on it? What kind of flavor of comment is it?
That kind of thing. You could go into all of that and. You may need to do it a bit to that level especially for a remote organization, but I don’t think you have to, I think you can do it based on as a manager, what you hear on one-on-ones, what you observe in terms of how they interact with each other.
You kind of, you’ve probably had this before, you get a sense of who goes together and who doesn’t.
Mon-Chaio: Sure. Absolutely.
Andy: And that I think that you can write it down. You can start kind of like putting it out and then testing your hypothesis, cuz that’s kind of what you you’d start doing is you’d be writing this down. You’d saying like, my hypothesis is I’ve got two groups
and now you can start testing it.
You can act, you can just straight out ask people or you can look more specifically. Are there interactions that I’m missing that actually tie these groups together?
Mon-Chaio: Yeah, it’s interesting. I think I’m not like, you could definitely do it the data science way. I think the challenge is going back to it’s, it’s around the social context, not the work context. And can you, Can you use scripts or technology to figure out how much social connection versus work connection there is between people?
Whether I review your code or not? Could be both. It could be because I have to. It could be because it’s my turn or it’s could be because I like learning from you or there’s a lot of reasons, right?
Andy: Whi, which gets into, you have to take into account what are the norms of the team, because the norms of the team will also influence, influence this. So, as you said, I get, if the norm is that they constantly rotate duties like that, well then yeah, it wouldn’t be a reliable signal for trust.
Mon-Chaio: I still do think, and maybe you disagree that I still do think the first step is the hypothesis organization, if you will. You construct an org which you think should have high trust boundary
Andy: then look for disconfirming evidence.
Mon-Chaio: Right, right. Because you give it time, right? When you build, like let’s say you’re building a new company from scratch, you hire 50 people.
I don’t think what you do is like, you put those 50 people out there and then you start gathering data and saying, oh,
now that we know, right? You basically tell these 50 people, or you divide ’em into two groups of 20 or whatever, and you say, look, you are now a triple A team. Go forth and do your thing.
Right? And then you measure
Andy: yeah. And then you see is this working? And so I think there’s always those two sides. There’s that like, this is the way I think it should work. And then you check, it’s like you were doing with the KPIs. It’s actually the same pattern. You say, this is what I expect to be happening and this is how we’re gonna measure whether or not that’s actually working.
Mon-Chaio: Mm-hmm.
Andy: And this is a similar thing. This is how I think we should be working and interacting. And now let’s go and find out is that actually what’s happening? And, and you take corrective action.
Mon-Chaio: So I love this insight, at least it’s insight to me because I never thought about the corrective action part of this before. I’d be curious to discuss what we think are, like, how do we see this working in practice? Right? We’ve given a lot of, well, managers can do it on one-on-ones and like, you know, we could possibly use the data science, but is there some sort of actionable thing that we could suggest to listeners or actually even to myself and me taking it into my next organization?
Like, what would this look like? Would this look like a monthly manager meeting every month? Where, you know, we talk about this stuff. Is this at sort of an org-wide level? What do you think?
Andy: Mm, that’s a good question. I think it’ll vary depending on the organization, but I think it should be, it should be an ongoing discussion. So for instance, the, the, the Tim group that I was talking about was, it was self-organized and for that to happen, that kind of discussion was all going on pretty much all the time. So it wasn’t something that we necessarily designed, but it was something that I had to, as, as the engineering manager of that group, I had to promote.
Cuz without it, the organization doesn’t happen in a group of, in a group of engineering managers. Now, now I’m kind of rambling as I think through my past and what I’ve tried to do in the
Mon-Chaio: Oh, of course. I mean,
yeah.
Andy: In a group of engineering managers at that acquired acquiring organization I, I got us to talk to each other.
Not specifically for this purpose, but this would’ve been a great topic to bring up which was, what are the social groups that we see forming within our teams? Do they match up with the, the teams that we think we need for the objectives that we have right now?
Mon-Chaio: Mm-hmm.
Andy: But it did kind of happen. So I think if we had made it more a deliberate kind of deliberate and regular discussion, so you could say for like a management meeting, you have this as a regular discussion.
What are our, what are our current team social dynamics? What are the, what are the groups? Does this align with where we need to go? That would be an interesting discussion.
Mon-Chaio: I agree. I think, you know, I think first of all, you have to set that set that accountability on your ENG managers or group leaders that this is something that they’re regularly required to look out for.
Andy: Yeah.
Mon-Chaio: I think we’ll get into learning in some other way, but you have to give them the skills to be able to look out for that and train them.
Cuz not everyone is gonna know how to tease out the important social interactions within their group.
Right. And the worst you can do is say, well, these people have lunch together. And that’s my heuristic for social interactions within my org.
Andy: And you also have to be careful because it won’t always show up in the same way. And what I don’t want anyone to do from this discussion is go out and say, oh, these people aren’t having lunch together. They’re bad. Like, no, no, no, no. This, this should not cause you to go and just start saying, I need to reorg based on, on this.
It’s, it’s a point of question and a point of curiosity, going back to that curiosity and empathy, that curiosity and empathy is needed from the leaders as well to understand what dynamics they have. Understand why that’s happening and have empathy for the choices people are making.
Mon-Chaio: Right. I mean, let’s not forget that the, the whole social thing is a is a proxy for trust.
Andy: yeah. Yeah.
Mon-Chaio: Or let’s, let’s call it long-term trust. So two people not having lunch with each other does not mean that they don’t have long-term trust.
And so to your point, the empathy and curiosity is important there.
So this has been a super interesting discussion. I think there’s a lot more to discuss here and we’ve kind of teased that. But that’s how it always is in these discussions, right? It tangents out into other things that then we wanna bring in.
But I think I think at least I have found that there’s been some pretty good insight from the discussion we’ve had so far. And this idea of measuring long-term trust boundaries is something I’m gonna think more about and how to action that in my in my future organizations.
Andy: And, and I’m gonna think about long-term trust boundaries. I, I had not thought of that until this discussion. I really like the idea and so I’m gonna do quite a bit more thinking on it. See where it takes me.
Mon-Chaio: Fantastic. We would love to know, for all of you folks listening to the podcast, what your thoughts are. Does what we’ve discussed make sense? Or do you have a different way of thinking about how to build orgs and how to build org boundaries? And maybe the boundaries aren’t built around trust long-term versus short-term.
So let us know.
Andy: Thanks Mancho.
Mon-Chaio: Yeah. Thanks Andy. Till next time,
Andy: See ya.
Mon-Chaio: see you.
Leave a Reply