Employing Differences

Employing Differences: Episode 66: How is this my problem?

August 17, 2021 Karen Gimnig & Paul Tevis
Employing Differences
Employing Differences: Episode 66: How is this my problem?
Show Notes Transcript

"We have been very successful by decomposing things and ignoring the ways that they are interconnected and interdependent. As we are starting to tackle more and more challenging problems, more organizations and groups are realizing they aren't really separable."

Listen on the website and read the transcript

Watch this episode on YouTube

Karen:

Welcome to Employing Differences, a conversation about exploring the collaborative space between individuals.

Paul:

I'm Paul Tevis.

Karen:

And I'm Karen Gimnig.

Paul:

each episode we start with a question and we see where it takes us. This week's question is, "How is this my problem?"

Karen:

I think this is such a common thing that we see in organizations of all types. That somebody comes to a meeting or shows up in some way and says, we need to do this thing, we need to solve this thing, we need to create a policy, we need to whatever the thing is, and somebody else is doing anything."How is this my problem? How is this up to me?" Because we think about those things in our mainstream culture where we have words like accountability, we have systems in place that are designed to define whose responsibility the thing is - and very often which one person has responsibility for that, sometimes with another layer of a manager who has responsibility to make sure the one person does the thing but essentially, we really segregate our problems into each problem belongs to one person because it's their responsibility. And this seems all very virtuous and effective somehow, when we lay it out that way in terms of accountability, and personal responsibility, and all these big words. But what we're pointing to here is that there's a way in which that doesn't actually serve us, this defining which problem belongs to who, whose problem it is. And there's another perspective that happens when we look at a problem and figure "If it's a problem for anyone, it's a problem for everyone." If we're all working on the same project, if we're all working towards the same goal, if we're all working in the same company, if we're all working in the same community, a problem related to that project/goal/community is a problem for everyone. And thinking about it that way changes absolutely everything.

Paul:

It's one of the things that I talk a lot about when I'm working with agile teams, and the whole idea is we talk about impediments. Impediments are things that are slowing us down. One of the things we just really underline is that individuals on the team don't have impediments. The team has the impediments, if any one of them has it, they all have it. Because they're collectively committing to this goal, they're moving these things together. This is what makes them a team. They have a shared goal, they have a shared purpose. They're they're making collective commitments to each other and to the larger organization. And so as you know, as the old aphorism says, when the boat is leaking, you don't say, "Well, the hole's on your side." We're all in the boat. Part of this is about how do we take collective ownership of these things that really do affect all of us. I want to back up slightly and talk about why we have gotten to the individual ownership of problems and why that doesn't work. Classically, we look at a big problem and we go, okay, we need to break it down into its constituent components, because it's too big to handle all at once. Since they're pieces we need to decompose it. And so this is where you get specialization. People do different pieces of problems, because they develop skills at them when they can focus on just a sort of a little bit of it. What happens when we do that decomposition and we often cascade that down an organization. If the organization is hierarchical, then we have goals and sub-goals and the sub-goals here, and those are supposed to all roll back up. And when you add the pieces all back together, you get the original. What that tends to lose sight of is the interconnections between those pieces, how they influence each other. About how when we're trying to solve this particular piece of this problem over here, it influences things in other parts of the group and other parts of the organization. And so well we go, "Well, that's not my problem. My problem is this." And the thing is, they're actually not different problems. They're the same. They've been cascaded down in such a way that makes it look like they're separate problems. But because we have gotten so used to thinking that way that we have, for a long time, been very, very successful by decomposing things and ignoring the ways that they are interconnected and interdependent. Therefore we believe that they are independent, and it's not my problem. And as we are starting to tackle more and more challenging problems and more organizations and groups are realizing that these things aren't really separable, or that they might appear separable and then when we discover that they're not they are linked, that there are interdependencies between them we need to use our skills to say, oh, okay, cool, we need to own more than just our own individual problems. And so that's kind of where this comes from: The belief that we can break things down and their independent. And what you and I see all the time is that there are so many things like that that aren't. That that they're actually interdependent. And so this idea that it's my problem and not my problem gets in the way of solving those those challenges.

Karen:

I want to put in a little caveat here. We've had other episodes where we talked about how important it is to delegate, and that is also true. And so I'm going to say that in this episode, we're really talking about not any any old problem. If I've had a task delegated to me, and I come up with a problem and I see a solution and I can do the solution, and I take care of it, that probably was my problem. It was delegated to me, I was able to solve it, I took care of it. That's all great. But if a problem is being named in some other context, if a problem is being brought to a team, if a problem is being brought even to a manager, if the problem is being brought out of the individual workspace, I'm going to assume that there's a very good chance that that is a problem that does belong to everyone, or at least to a broader set than the one person. Because in an organization, your workers are all good workers, and they are not trying to hand off problems. If they can solve it, they solve it, and they'll work through it. If it's coming up more broadly, I'm going to assume that it is a problem that needs more ownership than the one person who's naming it.

Paul:

Yeah. So here is the, you know, $60 million question. How do we help people to break out of that belief that, "well, this is my problem and that is not my problem," when in fact they're interdependent? When in fact, what is going to be useful is to bring things up to the more collective level to actually engage more than one brain because that's one of the things about when when we take a problem and say, "This is my problem," we only get to apply our brain to it. There are way more brains in the group that can do way more good work. And when we need that, when we have these interdependencies, we need more perspectives. We need more smarts on it. But that only happens when we're actually willing to say, "That is also my problem. How do we figure this out?" And that's a challenge I think that both of you and I've seen a lot. What are some ways that we have found that actually help people to make that shift, to moving to that more, "it doesn't matter where what side of the boat the hole is in" sort of perspective?

Karen:

So I think one of the really essential elements for that is that there has to be capacity. That if everybody is working to their absolute capacity in their own set of problems in their own delegated tasks, the idea that I'm going to now also be responsible, or in part responsible for some other problem that doesn't seem to me immediately like it's in my realm, that's just overwhelming. And so I think the first step is to make sure that we've organized our workflows and our hierarchies and all of that in ways so that everybody's job description leaves them with space whether it's mental or time or emotional capacity, whatever that is, but that we really have structured our organizations such that everyone has space to pay attention to the collaborative, to the collective, to the whole organizational or at least team level, depending on what's appropriate for that. That everybody has space to entertain the question of how might I help with that other problem that appeared somewhere outside my realm, but actually is interdependent with me?

Paul:

Yeah, that I think that that response to overwhelm is one of the places that the"Well, that's not my problem," is really rooted in. We're already underwater. And so we are defending ourselves against more water being dumped on us, in a lot of ways. And that's entirely understandable. It's a stress response. And so, I think certainly making sure that we actually have capacity to do that kind of thing is certainly part of it. Another thing that I've seen a lot and that actually works pretty well is one, making sure that whatever group collective you're sort of dealing with actually has a well articulated collective purpose and framing... One of the things we would do in in teams would be to articulate not "This is my job," because I think the job description thing is one of the things that locks us in. We go,"Well, this is my job, that's not my job." It's the same flavor of "that's not my problem." We would articulate that we actually all had the same job. So when I was working in a software company, "We all have the job of delivering valuable software to our customers." That's all of ours job. Now, we each bring individual skills and expertise. So we would talk about these are the skills that I bring that help us to do our job. But even there, we're shifting it from"this is my job, this is what I do," to "this is what I am part of, this is what we're all collectively trying to do." And so when obstacles came up that collective purpose, it helped each of us see that even if addressing it seemed to be outside of our area of expertise, or our skill, we still owned a piece of it. We still had some accountability for it, even if we didn't know necessarily what to do about it.

Karen:

Yeah, so that culture of shared responsibility and shared investment, I think, is hugely important. Another piece of culture, culture and skill kind of combined, actually, is that the person who sees the problem needs to speak the problem. And ideally needs to speak the problem in an invitational way. So two things that go astray with that. One is that, well, I'm not going to say I have a problem, because I will look weak, or I will be blamed, or it will look like I'm incompetent or whatever that thing is. So for all of the reasons that people do this, "I see a problem, but I'm not saying anything about it, hide the problem, hide the problem, I've got it, I'll take care of it, I'll figure it out, even when that's not realistic at all." The other way it goes wrong is,"Okay, I'm going to name the problem, but I'm going to make sure that it doesn't look like it's my fault." So I'm going to bring the problem to the group and say, "We've got this problem, because Paul didn't do the thing that Paul was supposed to do," or whatever. Bringing it with blame or with displacement, where I'm landing the problem in somebody else. Like, "I need this thing, you have to solve it." For me that kind of energy about it, that makes collaboration pretty tough from the get-go. And so if instead we can get really skilled at and have a culture of acceptance of showing up and saying, "I'm seeing the thing, I think it's not a good thing, and I don't know how to fix it. It's outside my wheelhouse to be able to solve it. I think contribute in these ways, or it seems like maybe it could be helped over there. But hey, group, there's this problem." And in a really Invitational collaborative kind of framework, bringing it forth and handing it off to the group, which is the last piece of that request, which is, it's not a"Okay, I need you to do this and you to do this and you to do this, while I still control it." That's not going to probably be that collaborative thing that we're looking for. It's, "I've got a problem, this is what I have figured out about it. This is what I still have no idea about it. And here it is to the group, and I'm letting go. And if if I need to pick up a piece again, I will somebody else wants to take it and run with it. That's all good." But that really letting the team hold it.

Paul:

Inviting people into the collaborative problem solving space is really key piece. Two things that I find really useful around that are modeling that behavior people actually doing it, particularly people who have more perceived or actual authority in the group doing it and talking about it. If you actually have formal authority in the group, to say, "Hey, I actually want to make sure that we're bringing problems to the collective and that we're actually surfacing these things up, and we're and we're letting the group own them." Which is the opposite side of "Bring me up solutions, not problems." So modeling that and doing it yourself, right, and being like,"Hey, I'm having this problem, how can I do this?" The more that people see that and the more they see how effective it can be, the more likely they are to do it. And then the other piece around it is is the encouraging feedback. When people do that, when people bring problems to the group because they recognize, "I could go solve this but it's totally interdependent with this other thing and that's going to cause problems over there, and I don't know how to deal with that." Because that's the other part is that like you might recognize, I have a problem, and I could just steamroller my way through it, but it's going to cause problems for other folks, and recognizing that I don't want to do that, and I don't know how to necessarily solve that on my own. If you can bring that to the group and say, "Hey, we need to work through this. "No matter who you are in the group, when you see that happening, pointing it out and saying, "That seems really effective. Thank you for doing that. Encouraging that behavior. "I'm really glad that you brought that so that we can address it as a group." That's something that you can do or say, regardless of what seat you're sitting in in a group. When you see that collaborative behavior, to acknowledge it and encourage it makes it more likely that one, that person's going to do it again, and that other people in the group who haven't done it will go, "Oh, is that a thing we do here?" Because you're starting to shape the cultural norms about how you deal with problems.

Karen:

So I think to kind of wrap up where we've been, we started with, "How is this my problem?" And I think what we're trying to demonstrate is that very often, it is really useful to answer the question, "How can I contribute? How can I engage? How can I participate in this problem?" And what we need is to build a couple of things. One is capacity in the group. We need to make sure that as we set up our organizations that they are set up in such a way that every individual has capacity left over to work collaboratively as a team. And then we want to set up a culture where people feel comfortable and willing and are able to bring in a productive invitational way, "This is a problem I'm seeing, I don't know what to do with it, or I maybe you know, part of what to do with it, but I need help with the rest," or "What I see to do about it will cause a problem for somebody else. How do we address that?" But bring it in an invitational way, so that people can engage, and we really set up that collaborative space. And that the ways to build this culture are to model it to actually do the thing and to appreciate it. So both to model showing up with a problem and saying there's a team effort going on needed here. And when it happens to be saying out loud, "I see that happen. That seemed to work really well for us. I appreciate it," that kind of thing. And we think that if we do that, then when the interdependent problems show up, they'll actually get solved in ways that meet all the needs and get the whole thing taken care of. And also leave people feeling really good.

Paul:

Yeah, that's what it's really all about: Solving problems in ways that people feel good about actually solving them. Well, I think that's gonna do it for us for today. Until next time, I'm Paul Tevis.

Karen:

And I'm Karen Gimnig, and this has been Employing Differences