Show Notes
Andy and Mon-Chaio explore Marvin Weisbord’s Six Box Model, a framework from the 1970s for diagnosing organizational issues. They explain each of the six parts of the model: purpose, structure, relationships, rewards, leadership, and helpful mechanisms, and then illustrate it being used to assess an example software development company. Listeners will learn how to guide investigation into a situation using the model and the advantages they get from it over just winging it.
References
- Organizational Diagnosis: Six Places To Look for Trouble With or Without a Theory – https://leeds-faculty.colorado.edu/Rosse/Courses/4003/Readings/Weisbord.pdf
- Analysing a team situation using BART – https://open.spotify.com/episode/0ccnbKOCrt1mpw8LRgbdJz?si=91df18bddf3b43c8
Transcript
Andy: And we’re here for another episode of the TTL podcast. Are you ready to go, Mon-Chaio? Are you ready to rumble?
Mon-Chaio: Yes
Andy: I don’t know why I decided to start with that. It just seemed appropriate. Yeah.
Mon-Chaio: Right you were thinking of boxing boxing day six box model and then What is that person’s name the are you ready to rumble person?
Andy: There’s some famous announcer. That’s the way he always did it.
Mon-Chaio: Yeah
Andy: So we’re going to be talking about the six box model. The six box model is a bit like the BART model in our very first episode, which is a system for kind of analyzing a situation or analyzing an organization, the six box model is from Marvin Weisbord.
Yes, Marvin Weisbord. In the 1970s. The article I’m looking at is from 1976.
Mon-Chaio: Mm hmm
Andy: If you’re an organizational designer, or in our case, if you’re trying to help an organization, you enter these places, and you kind of need to figure out what’s going on.
You need to understand the interplay, how things are happening. We talked about the BART model, we’ve talked about a few others. Martin Weisbord said, sometimes you just don’t have a theory.
Mon-Chaio: Mm hmm
Andy: have any theory to go in and say, I’m going to test this idea. And so he decided, maybe if he thought back over his engagements over the many years he’d been doing this, there’s a, atheoretical approach that he could use.
Normally we consider atheoretical pretty bad. It’s like, well, you don’t have any idea of what you’re doing. But in this case, it’s kind of go in without a preconceived notion. But how would you do that? You have to have some sort of structure. And so he came up with, and he proposed, this six box model. He said that this is basically what he’s found himself doing.
He’s going into these places. And applying this model as a way of asking what could be going on. And so, Mon-Chaio, I think what we’re going to try to do is take this and apply it to a situation. We’ll probably go through it first, just so everyone understands what we’ve got.
We haven’t actually gone over this yet. We pitched it and we said, Hey, let’s do this, but we haven’t talked about what it means. So, we’re gonna find out as you find out.
Mon-Chaio: Right. I think it’s an important idea to align on the foundation of what we’re talking about instead of just saying six box model, because we’re an audio podcast, right? A lot of people are listening to us at various, whether they’re out and about, or whether they’re on a commute, we don’t expect people to pull up their phone and look up six box model and all the intricacies of it.
Andy: Please don’t look up your, pull up your phone and look at the 6 box model while you’re driving.
Mon-Chaio: So I think we should start there by talking about the six box model. The name six box model is evocative of exactly what it is. There are six categories that he says are related towards well functioning organization or towards diagnosing what’s going on in an organization that may not be functioning that well.
Now, He doesn’t really talk about how they relate to each other. So he doesn’t say well purpose affects relationships and Rewards in such a way and there’s this inverse relationship X There’s none of that right which is a lot different than the models we’ve presented in the past I think he’s basically saying look into these six boxes and what comes out can help inform you in your diagnosis Without really any more structure than that.
Andy: Yeah. He talks about it as kind of like, you might find, flashing warning lights in these different areas. The fact that the flashing warning light exists on its own isn’t good or bad. It’s just a thing that exists. But what it does is it gives you, as an investigator, the chance to go and find all of those flashing lights and then start coming up with, how might these fit together?
Mon-Chaio: Mm hmm So let’s talk about those boxes. So we mentioned there are six of them. The first one is purpose and purpose is sort of like vision or mission. It’s where, what is this business doing? Where is it going? Why does it exist? That’s
Andy: Yeah. Yeah. What, what we want to do. And, and I think the interesting thing here is you can, you can say, well, maybe you go and take the espoused purpose on the company’s website. But then you start going and you talk to people and start getting a sense of what is they, what do they consider the purpose? So right there, you can kind of start seeing, like, why do people think they’re in this together?
Mon-Chaio: And I think for many businesses, it’s, they haven’t a spouse purpose that they put on their website, but as they execute the day to day drudge of executing the business, it shifts and it morphs. And sometimes you get into points where long timelines. Or where there’s a long period in your business, you’re not really moving towards your purpose.
And that could be an indication that something is wrong. Maybe your structure is wrong or maybe the way that you’re working, your relationships are wrong. So,
Andy: Yeah. Or, or you might have a purpose where you look around and you’re like, but your environment doesn’t want that purpose.
Mon-Chaio: Mm hmm.
Andy: So you’re not connected to your environment. And so it’s not just internally, but you’re also kind of thinking about it as your connection to the outside world.
Mon-Chaio: Yeah, absolutely. And he mentions Weisbord mentions outside environment. That’s not one of the six boxes. But he does say, look, you have to interact with the outside environment. Eh, sort of a cop out, right? He’s like, well, here’s six boxes, and there’s a lot of other stuff.
Andy: Well, so he does that because there’s a thing about him, he talks about setting the boundary. And the reason he needs to set a boundary is because he can only work with so much. So he kind of said, okay, here’s the boundary.
Everything inside that is the organization that I’m working with and everything outside of that is, I’m just going to call it the environment. And it has inputs and outputs and all of that, but you know what? I’m not going to concern myself with it too much.
Mon-Chaio: And you have to set boundaries because as a human you can only make so many connections and keep so much stuff in your head. Which is why I’m developing SixBoxGPT. So the external environment can come into play. We can have larger and larger boundaries. We don’t need boundaries. If you have LLMs, right,
Andy: Right. Just get a larger context.
Mon-Chaio: that’s right.
Okay. So purpose purpose is the first of the six boxes. The second box is structure. How are you organized? How do you relate to different groups? How do we divide up work? Who ends up owning what KPI, that sort of a thing.
Andy: Yeah, and, and this one it connects as well to, I think in the past we’ve talked about functional organizations versus divisional organizations. What is the structure? What are they all doing? How do they divide their work? Are they connected to each other?
Is there a matrix system going on between the functions and the products? So. Yeah, just get, look into how that all works together.
Mon-Chaio: The third one is relationships. So this is how do people and people work together? How do they resolve conflict? How do they coordinate amongst themselves? Yes.
Andy: Yes. And also their technology.
Mon-Chaio: Mm
Andy: So what is not only their relationships between people, but also their relationships with the technology.
Mon-Chaio: hmm.
Andy: So is everyone really happy with the tools they’re using? Are they all using similar tools? Are they using different tools? I imagine in the modern day, because this was 1976, in the modern day we could also take this as relationships between technology systems.
Mon-Chaio: Mm hmm.
Andy: So you could say, is, does what the finance team use, is that connected to what the IT team is using? Or are they completely separate systems that have no relationship with each other?
Mon-Chaio: Number four is rewards. I think this is pretty self explanatory. How do you reward people? What is the incentive structure? How do you get people to want to be in the organization to grow? I think that would be the rewards bucket.
Andy: Yeah. And in this one, he also thinks about kind of Maslow’s hierarchy of needs. So, rewards are more than just financial, they’re also esteem and belongingness and safety. Do people feel a belonging as a reward for being part of this group through their relationships
Mon-Chaio: makes sense. And I’m actually glad that it’s a lot bigger than just monetary rewards. Number five is leadership. So who is kind of looking out for the whole system? Who is thinking about how did all of the parts balance? And determining which box might be problematic.
I think he would fit that into the leadership bucket.
Andy: Yeah, and in the diagrams of this, he always has those other five around the outside with kind of arrows connecting them and then leadership sits in the center.
Mon-Chaio: Right, and yet it’s number five, not six, always.
Andy: There is one more, isn’t there?
Yeah,
Mon-Chaio: so I’m not sure why leadership is always number five, but it sits in the middle. Maybe he thought of six later. Number six is mechanisms, helpful mechanisms. So, those would be processes. Are you using scrum? How do you go about communicating on a day to day basis?
Do you send progress reports? That sort of a thing.
Andy: If you’re walking into a software organization, you might look at the daily stand up and the communication that’s happening on their Slack channels if they’re doing PRs, how they’re, how they’re handling that, because those are all helpful mechanisms.
What is the purpose that they’re serving? Does it fit the organization? Does it fit the goals? Does leadership seem to be involved in managing it or helping set it up?
These are all questions that you can be asking.
Mon-Chaio: And then of course we talked about the outside environment, which is sort of the everything else there, which may bring inputs into the system of the bound inside the boundary of the six boxes and the output of the six box boundary will go into the external environment and there’s some sort of relationship there that isn’t really well defined but like there is an outside environment, That may affect your organization as well so
Andy: And, I think there’s an actually an interesting thing. I would actually say it’s the six box and one circle model because I think the setting of that environment, Marvin Weisbord talks about it a bit as it’s a way to just make sure that his scope is contained and limited. But I think it’s also an interesting thing to figure out what different people think that environment boundary is. Because I’ve seen a lot of organizations where one of the things that starts going wrong is people don’t agree on what the boundary is.
Mon-Chaio: Right
Andy: in that disagreement, you start getting kind of defensive routines going back to action science stuff that we talked about last time. You start triggering defensive routines because people think that this boundary, this environment versus organization boundary is being violated. Where in the other person’s mind, it’s not really being violated because we’re supposed to be operating across this.
Mon-Chaio: and I think it’s much more clear when you think about a company Interacting with its external environment. It may be Less clear about how that comes into play but if you think about a large company with many organizations You can think about the external environment being the other organizations so if you’re an engineering org, perhaps the other organization is the finance org or the sales org, or it could possibly be like the platform engineering org is an outside environment. And so Andy, to your point if for example, it’s the platform organization, it’s the outside environment. Some people might say, no, that’s not, that’s part of the same boundary.
Andy: Yeah, and the reason I bring this up is because when we get to, well, probably right now taking it ourselves through this in thinking about a particular case, and I’ll describe the case a little bit, the environment distinction, where that boundary was, was a key part of some of the disconnect.
And you could say that that shows up in terms of relationship. You could say relationships also are part of defining the boundary. So, it’s a little fuzzy, but in my mind that’s kind of the purpose of the model, is to keep it a little fuzzy until you have more information.
Mon-Chaio: Right. And the model itself mainly is used as a way to steer and organize thought, it doesn’t give you any tactics to do. It simply says these are the areas where you might focus and find clarity.
Andy: Yeah. And in each one of these areas, I should say, if anyone reads the paper, he also calls out particular other models that can be used to do the thinking in that particular area.
Mon-Chaio: Good point. Alright, so we have these six boxes. Purpose, structure, relationships, rewards, leadership, helpful mechanisms, and then the outside environment. In the BART model, we took one of my situations. So I think now, Andy, I think we’re taking one of your situations. And let’s try to use the six box model to see what we can learn about how we diagnose that situation.
So, what is this situation?
Andy: right. There is a software development shop that runs and builds a web application with multiple mobile applications connected to it. The application itself connects out to a few third party systems, and it’s used in a fairly safety critical context.
What that means is that their client has lots of kind of due diligence requirements about what exactly is going to be built and how is it going to be built and all of that. There was a sense from their client that the quality of the software wasn’t up to what was needed.
Timelines on delivery were constantly slipping. And that’s kind of like the setting of the situation.
Mon-Chaio: And the quality issues that the client was seeing, were those also impacting their safety metrics or how safe the product was? Or was it affecting that due diligence part of it where we weren’t able to meet regulatory requirements? Or was it just general quality problems?
Andy: It was general quality problems. There had been no incidents because of quality issues.
Mon-Chaio: Okay.
Andy: So if we kind of go through the box model. I’m trying to think, does this fit into anything?
I suppose it’s, it’s a bit of relationship between the company and the client, which was, there was a conflict, and I think there was a conflict in seeing, well, what’s the implication of these quality issues?
Mon-Chaio: right. So we talked about the quality. And you also mentioned that they also timelines and delivering what they said they were going to deliver when they said they were going to deliver it.
Andy: Yes the, the timelines were often set by the client months, if not a year or more in advance for building software that hadn’t been defined yet. So. The timeline thing was this constant contention of, of, well, you’re late and you need to deliver this now, but you need to deliver it to the full quality and with everything that we’ve specified that’s in it.
A common thing would be the team kind of, rushing things out. And of course, cutting corners, cutting out testing and cutting out refactoring because. The timeline was considered ultimate.
Mon-Chaio: Okay, so you were brought in to fix these issues. I think the first thing you’re going to do is do some diagnosis and maybe the six box model is a great way to start your diagnosis. So where’s a great place to focus? Should we actually go through all of the six boxes and see
Andy: Yeah, I, I,
Mon-Chaio: maybe focus on a few of them?
Andy: I would say, I think this is the way that people should apply this, is you take it as a structured inquiry approach, where if you’re doing this as interviews with people, or if you’re doing it where you’re examining artifacts, documents, source code chat in a Slack channel, whatever.
That you go through and you focus your mind on each box one box at a time and kind of work your way through it. Because what you want to do is you want to make sure that you’re not missing something just because you found something that was like, Ooh, that was really interesting. And you go down that whole route and then you miss out that you never looked at relationships.
Mon-Chaio: Right, you get distracted by the shiny thing.
Andy: Yeah.
Mon-Chaio: Great.
Andy: Yeah. So let’s, let’s just go through them one box at a time and kind of see if we can dig out what’s going on. So purpose what business are we in? If I asked anyone what business they were in, I think I would have been told their business is to help people in these safety critical situations to perform the actions that they need to do.
And I think that that’s what they would have said their purpose is. Their kind of like sub purpose or their mechanism for doing that would be to be providing software as a service that helps people manage these situations.
Mon-Chaio: Manage these safety situations. The software helps them become more safe managing the processes or the mechanisms around what they should do in various cases.
Andy: Yeah.
Mon-Chaio: Okay.
Andy: And here’s the thing where I’m going to do it. I’m actually going to say that the boundary that I selected was not just the company. It was the company plus their client.
Mon-Chaio: I see.
Andy: The reason being is because I did not see the relationship as, as separable like they did. Because what I watched was a client who had that purpose. A supplier who determined they thought they had the same purpose. But the purpose that the client believed their supplier had was one of just supply software to our specification.
So this, the company was actually, their purpose was a software development shop. But they did have a secondary purpose of trying to provide these safety things but in the relationship, their purpose was mainly just, you’re a software development shop.
Mon-Chaio: So if I understand correctly, the client felt like the company was just a software development shop. The company felt like they were more than that.
Andy: And so what you had in thinking about this, we have purposes that are in conflict with each other. And we have misalignment or disagreement about what each component’s purpose is.
Mon-Chaio: Okay. I think that’s pretty clear that there’s something in that purpose bucket that’s, to your point, Andy, the flashing warning light.
Andy: Mm hmm.
Mon-Chaio: Should we move on to structure?
Andy: Yeah, yeah. So, the way the group is structured is, and I’ll take these as the company and their client. The company is structured, there’s a CEO, there was kind of a head of engineering. There was a head of product, and here you can start seeing a bit of the, like, purpose disconnect.
There was a head of product, there were several product managers, there was a designer, there was the development team, and the development team had a manager. The development team was split up into what they called cross functional teams. They were not they were not a matrix organization. They were very much a product organization.
They were structured around this product. They had a few other things and they were separate teams for that. The client also was structured a bit like a product organization. The client had a program manager. The client had a product manager.
The client had an architect. The client had testers.. And then those people were part of a much larger organization that had various constituent agencies that they interacted with who were the actual end users of the system that was created.
What I noticed was that the client had a product development structure filled in almost everything I’d expect to see in a company that set itself up to use a software development shop because they had their own product management. They had their own designers. They had their own architects.
They had this whole thing of how they would be working with this to get it to connect to the other systems that they build.
Mon-Chaio: So that sounds like maybe a strange warning. Warning light there under structure. This what would you call it? This duplication of structure across client and company.
Andy: So you had product manager in both. You had testers in both. You had testers at the client. You had testers in the, in the company.
Mon-Chaio: So that’s pretty strange and then what about if we just focus on the company itself like would we say that there were warning signs around the structure just in terms of how the company was structured?
Andy: I would say at a high level, not really. If I viewed them as a product company,
Mon-Chaio: Mm hmm.
Andy: their structure made a lot of sense. You’ve got the product owners, you’ve got the, engineering manager, you’ve got the engineers, you’ve got people doing the UI, UX.
You’ve got all of that. And that all seemed very reasonable. But it’s when I combined it with what was I seeing in the Client it’s like things stopped matching things stopped making sense
Mon-Chaio: Okay. So Then I think we can move on to relationships because you almost wanted to talk about relationships when you’re talking about structure and the way that you described the blinking lights of the duplicated structure must have meant that the relationships were fairly difficult between the two product managers on each side or The testers on each side.
Yes
Andy: Yeah, I would describe the relationship as strained.
And the relationship was one of withholding information as I think I’ll put it that way.
Mon-Chaio: Hmm.
Andy: So. I would often hear about information being withheld, but it was done to protect everyone, was the belief. Because, no, we are the ones who design this, we are the ones who run this, we’re the ones who build it. So, those aren’t things that they need to know.
Mon-Chaio: Interesting. So the company itself was saying we hold a bunch of information and the best way to interact with the client is to abstract this information so that we can give them the details that matter and they can help us as the client determine maybe some sort of prioritization or path forward.
But. Maybe technical implementation, like why would they need to know any of this? Why do they need to care about the architecture? They should just be telling us, hey, this is, these are the use cases we need to meet and we’ll go deliver them.
Andy: Yeah, we don’t need to tell them one particular case that I remember came up was we don’t need to tell them that fixing that is in the backend API server and it’s just a deploy of that. We’ll just tell them what we’re fixing it.
Mon-Chaio: That seems to make a lot of sense, but it sounds like that’s not what the client was expecting.
Andy: I don’t think it was what the client was expecting because what I got from the client side of the relationship was that they often felt that they were getting the wool pulled over their eyes. That I think dissemble is a good word in this case.
Andy: Now, relationship internally to the company was that it was a very hierarchical system. So, the engineering manager would take requirements and work with the product managers, who are basically business analysts would work with the product managers to break that down into smaller pieces.
And then, once they think that they broke those down to smaller pieces, they would take those to the people that they considered the kind of head of the lead engineers. And the lead engineers would take that and they’d estimate it, and then they’d break that down into tasks. And then the tasks would sit there, and then the product managers would assign tasks to individual developers.
Mon-Chaio: And this is within the company that we’re not talking about the interaction with the client
Andy: Yeah, this is all within this company.
So the Individual developers, because of that structure had almost no relationship to each other.
Mon-Chaio: Mm hmm.
Andy: In talking to one of them, he told me, I don’t know who’s on my team.
Mon-Chaio: Hmm. Okay.
Andy: Which was very interesting to hear, because they were also onto helpful mechanisms a little bit. They were in stand ups every day. But even through that, they got no relationship to each other. So, you had very few kind of like, horizontal relationships,
Mon-Chaio: hmm.
Andy: and almost entirely vertical relationships.
Mon-Chaio: Which is not rare for the type of work the type of processes we’re not, we haven’t gotten into processes yet. But the type of processes that you describe where you’re kind of breaking down work into smaller and smaller pieces such that they could be executed quote unquote efficiently in little silos, right?
You would just imagine that in that case, horizontal relationships. are less important than the vertical relationships.
Mon-Chaio: Okay, let’s move on to rewards. How were these folks incentivized? Was the incentive structure at odds with what the organization and the client needed accomplished?
Andy: The reward structure, I have to say I don’t know too much about the individual employee reward structure. If I took it from, in terms of monetary, if I took it from the standpoint of internals of the company wanting to do things, the reward structure was that the, safety critical situations that your software helps is something that most people feel a strong desire to help with
Mon-Chaio: So mission driven
Andy: very mission driven.
And so there was kind of like a big sense of going at the Maslow’s needs hierarchy belongingness or esteem feeling that what they’re doing matters.
Mon-Chaio: Okay,
Andy: and so I think there’s a reward in that.
Mon-Chaio: Okay. So number five is leadership. How did you evaluate leadership within the context of this situation?
Andy: So I basically determined that there was no leadership.
Mon-Chaio: On either side, the client or
Andy: Well, I would say there was no technical leadership. There was no person, there was no figure that I could see was. Setting up a bit of a vision and driving things forward and kind of coming up with this is how we get better and this is what we do and this is where we’re going.
That was basically absent. I think on the client side, I think that absolutely existed. I saw from the client that they had a constant ongoing vision of where they were taking this and what they wanted it to do and where it needed to go next. And they had several people probably.
That we’re all kind of engaged together in, on producing that,
Mon-Chaio: Mm hmm.
Andy: but internal to the company, there was some leadership from the executive team that reinforced this message of that we are here to provide the software to help in these safety critical set of scenarios, but no leadership on more tactical, This is what we’re doing today, or even strategic on this is how we’re going to do this in a way that helps us get even more people in these kinds of situations.
Mon-Chaio: What about specific tactical leadership just to run the organization? Let’s make sure things are being shipped on time.
Let’s focus on, you know, whether our estimations are correct.
Andy: so they had, um, they had a kind of project manager, but it was more of a reporting role than a leadership role. It wasn’t an active project manager in terms of, I’m going to take us through, make sure that we’re doing these things, when things aren’t going right, do the kind of like human side of investigation and understanding and how do we correct that.
I would say almost no one in the team of the client of the company that I was working with had the charisma or gravitas for leadership.
Mon-Chaio: is also not rare when we do tech due diligence is going in and looking at companies.
I think it’s more common than uncommon to find that
Andy: yeah. One of the things that then starts happening is that everything. Drifts, like drift becomes a major issue.
I think that’s probably why the, this drift of the difference between what it is that they’re, they’re kind of believed purpose is and what their espoused purpose is, or their espoused purpose and their actual purpose that they can execute on are so different.
It’s a drift in why the team essentially siloed itself off down to almost individuals. There was almost no leadership to pull it all back together and realign things and come up with an ongoing change to the organization.
Mon-Chaio: Okay, makes sense. And the last bucket is helpful mechanisms. So, I actually don’t like the name of this bucket. This is around processes, technologies or do we have the right tools in place to help us accomplish what we need to accomplish?
Andy: Yeah, so I think in terms of helpful mechanisms, this company had a lot of defined mechanisms.
In fact, my takeaway was that they were process heavy.
Mon-Chaio: Mm hmm.
Andy: But outcome shy.
Mon-Chaio: Mm hmm.
Andy: So I described one mechanism that they had about the, the, how, kind of like, a feature request turns into tickets to get done and then them actually doing it.
Other helpful mechanisms, you could say, fairly standard stuff. Feature branches, pull requests using a CI server. A very obvious to me missing helpful mechanism was automated tests. And now we start getting to, like, what could be the cause of these complaints about quality? There were very few automated tests.
Almost none. Most of them were questionable about whether or not they could even be relied on. There was a QA engineering group that was supposed to be writing browser based automated tests. But they very rarely ran them. And then they said because they’re hard to run and they’re unreliable. They did daily stand ups, but I don’t think it was helpful because the relationships were such that everyone was working on their own, there was no point in talking to anyone else about what you’re doing.
Mon-Chaio: Yeah. Right.
Andy: They had like twice a week check ins with their client about what was going on.
But once again, because of the withholding of information, very little information actually got communicated in those sessions. They had, like, all sorts of documentation processes for doing releases. So they would have steps that they needed to do. There’s go, no go decisions about doing a release to production.
There’s handovers to the client when it goes into a UAT environment. All of these are documented processes and everything. So, they were very keen on documenting processes, but, I think this comes down to the lack of leadership, most of those processes didn’t seem to bring much value. They were more cargo cult than helpful.
Mon-Chaio: So you would say the process has existed because this is how companies do it, or this is how we’ve always done it. Would you say there was also a case of, let’s just add another process and that’ll fix the thing?
Andy: Yes. Yeah. I think that’s how they got to some of these things. It’s like, oh, something went through, so we’re going to do this other thing. There was a thing early on when they said, well, we just released, we just merged a change that had a bug in it. And so one of their senior engineers recommended that the thing to do, the helpful mechanism to put in place, was that it doesn’t take one review get a PR in.
It takes two reviews. Two people now have to review it to get it in.
Mon-Chaio: mean, that’s always worked, like when you put more reviews in, things just get better.
Andy: Yeah, yeah, yeah, just, just, just review more. Just have more people read the code, and you’ll make sure that everything’s okay.
Yeah, so that’s, I think, going through all the boxes, that’s kind of the situation.
Mon-Chaio: Okay. So then what do we do? Right. You have come in, you’ve diagnosed via these boxes. There are a lot of flashing lights here. How would you say that the six box model has helped you then frame how you’re thinking about the problem and. What to do next.
Andy: So I think for me, it’s that focus on each individual area, and coming up with what do I believe in each one of those areas. Each one of those areas, I can now test some of the things that I’ve thought of, and check it with others. Either through observing, or through asking specific questions.
I think it also kind of highlights some of the stuff where there’s just obvious things going on. Like when I said, I couldn’t identify a leader. That’s like a, the big warning light. As we said, the leader kind of sits in the middle on this on all these diagrams and the kind of the way we think about that is that’s because that leader is the one who’s guiding and organizing everything around it.
Well, without that role being filled, everything’s just going to keep drifting off and doing other things and not going to have much coaching feedback, much mentoring feedback, much like, just feedback on what’s going on and it’s not that it has to be an individual it could be shared but usually for shared leadership people are pretty pretty well aligned with each other, but we were missing that in the purposes.
The purposes didn’t seem to align. There seemed to be some confusion in that. The structure was interesting maybe questionable But definitely not the problem.
Mon-Chaio: hmm.
Andy: And the relationships and the helpful mechanisms. The helpful mechanisms, in my estimation, came from those relationships and the lack of leadership.
Mon-Chaio: I see.
Andy: So the way I view this is to get this particular team working better. The lack of leadership and those relationships causing unhelpful, helpful mechanisms is where you start.
Mon-Chaio: Got it. Okay. I like it. So just like BART, this is another tool in our toolbox. You’ll be able to take a situation, make sense of it, and then as you were saying, Andy, in this particular case, you’re deciding to focus on two of the boxes, the model, or if you want to call it a model, I guess he does call it the six box model.
So we’ll just call it a model. The model doesn’t say, look, if you find a warning light in leadership and relationships, those are the places to focus first, right? But it does get you thinking about all of the different aspects buckets of problems that you might encounter and every situation will be different.
And, but it helps you kind of balance in your own head a way to think about situations that occur commonly within organizations.
Andy: absolutely. Yeah, so we hope that this exposition and walkthrough of the SixBox model has helped you all understand it, and that it now is something that you can take into your own organization and use it as a lens to look at things, to understand what’s going on around you, and to start getting a hint about where you might start.
I think another thing is also like what we just did, Mon-Chaio. The SixBox model provides a way of structuring and talking about what it is that you’re finding. Rather than just being all of these strange little hints and senses that you’re having and weird connections, you can now say, hey, look, I think if we look at relationships and leadership, that’s where we’re getting a lot of our problems, and we can see how, and you can go into how those interplay with other things, but you’re, you’re kind of working from a bit more structure, and structure always helps people get a grasp on stuff. So if you’ve enjoyed this, we’d love to hear. If you’d like Mon-Chaio and I to help you out on this we’re always available this is the kind of thing that we do, so if you are kind of getting the sense that something’s not quite right in your organization getting an outside view to go through the 6box model, or the BART model, or any of the other models that we’ve talked about can be a really helpful way to get some feedback about what’s going on, where do you need to start in diagnosing and treating these conditions in your organization. If you are interested in that, or if you’re interested in anything else and just want to get in touch, we’re at hosts at thettlpodcast. com. Hosts with an S, because it’s hard to say that final S.
Mon-Chaio: In the English language, right?
Andy: And we look forward to hearing from you. Until next time, Mon-Chaio, be kind, and stay curious.
Leave a Reply