Employing Differences

Employing Differences, Episode 39: What do they know?

February 09, 2021 Karen Gimnig & Paul Tevis
Employing Differences
Employing Differences, Episode 39: What do they know?
Chapters
Employing Differences
Employing Differences, Episode 39: What do they know?
Feb 09, 2021
Karen Gimnig & Paul Tevis

"How do we help people understand the value that other folks – on teams, in groups, that they're working with – bring?"

Listen on the website and read the transcript

Watch this episode on YouTube

Show Notes Transcript

"How do we help people understand the value that other folks – on teams, in groups, that they're working with – bring?"

Listen on the website and read the transcript

Watch this episode on YouTube

Paul:

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

Karen:

I'm Karen Gimnig.

Paul:

And I'm Paul Tevis.

Karen:

Each episode, we start with a question and see where it takes us. This week's question is, "What do they know?"

Paul:

One of the most difficult and useful things that I've done in my career has been working with teams of people who have different backgrounds, different areas of expertise, different skills being brought together to accomplish something. And this is incredibly useful, because groups like that can accomplish an incredible amount. And this is incredibly difficult, because we often tend to emphasize the value of our own area of expertise, and not see the value of other people's of expertise. And so it can be really hard when we start to get these cross-functional groups together, to actually get them to work well together. And so one of the things that Karen I kind of wanted to explore today is this idea of how do we help people understand the value that other folks, on teams, in groups, that they're working with bring, even when what they bring is very different in terms of knowledge, expertise, skill, things like that. So really about how do we help people understand what other people know.

Karen:

So I think that that partly is really reinforced by our cultural norms around hierarchy. And the idea that some people know more than other people. And while that's probably true, within any given context, I'm going to challenge us to consider that, particularly in a professional environment, each person is really expert at the thing that they do. And the thing that they do is probably a really essential and important part of the system that you're looking at. And so when we get into hierarchical systems where one person is presumed to know the most and maybe that's true, maybe they have more training, maybe they have but that doesn't mean they know everything. And if you dismiss the person who got their expertise with fewer years of school, or less years in the company, or whatever, but they still have a piece that they know that others don't. And so if we can kind of smooth out that hierarchy, bring in feedback loops, and other things that make it really safe for everyone to say what they know, without it being tied to respect for the expertise of somebody else, without it being threatening, I think that makes a big difference.

Paul:

I think that piece about respecting what other people know is really key. And recognizing how both in society at large, but also in any organization that we're in, any group that we're part of, what is the knowledge that is most respected. I used to work inside of a lot of software development organizations, in product development. And there, it was very clear that if you were a software engineer if you were writing code that was the high-status knowledge. Whereas if you were a user experience designer, if you were a tester, that knowledge was not as highly valued. And you could just see that in all sorts of structures in the organization. You could really see how that manifested. But the thing was that for the teams to get the work they needed to get done, they needed all of those areas of knowledge. They needed all of those pieces of expertise. And so by ignoring the status that we conferred and didn't confer, based on these sort of areas of knowledge, that became a barrier to teams working effectively together. Because you sort of unconsciously would have things like testers saying, "Well, I shouldn't interrupt, the engineer who's doing this thing because their work is more valuable, and so I won't to ask this question that I have." That would have saved saved hours and hours of time. It leads to these sort of that invisible hierarchy of status actually gets in the way of teams working really well together. And so one of the things that I try to do when I work with teams like that is actually get them to start having a conversation about what is it that someone else on this team can do that you can't that you really respect? Starting to get them to articulate what is the mutual respect that exists within the group? Because it can start to break down those barriers.

Karen:

And I think the other piece so absolutely agreeing, what's the thing that they can do that I can't but also, okay, I could do that thing. And maybe I used to do that thing. And I've raised the ranks, whatever. So it's a thing I could do. The fact that I'm not doing it every day, all the time means I'm not as attuned. There are things they will see doing that thing over and over and over again, every day and being in that space, that even if theoretically, I could do their job, the fact is, I'm not. And I can't possibly be seeing that perspective as well as the people who are in that spot.

Paul:

Yeah. Yeah, that becomes a real challenge in organizations where you have very senior level people, who were founders of companies, for example, like, the technical founders 10 years on are always saying things like, "Well, you know, when I was working on the code, we could do blah, blah, blah, blah, blah." And it's like, well, how is the environment changed since then? You know, how many multipliers of of lines of code do we have now? Right? We had 1000 lines of code when you started, right? We have 10 million lines of code. Now, guess what, we can't do those things. And so I think it's recognizing, sort of in there as well, where you have enough knowledge to know what you don't know and naming it. I think the other thing about the sort of mutual respect piece is actually just giving voice to the fact that we have respect for and admiration for the people that we work with. Because if we aren't saying that, then that hierarchy that exists is going to assert itself. Like we have to sort of consciously be working to counter that, in order to make it an environment where people know that we actually respect their opinions, where we actually need their input and their knowledge, because they're receiving all sorts of signals from the rest of the environment that tells them that we don't want that.

Karen:

And I think the other place where we get into trouble with expertise is where we're in very different fields of expertise, but working within the same system. And there is a tendency to say, Okay, well, you guys that know this thing, you go over and work in that little pod, have that expertise, and you guys that know this thing, go and work in your little pot of expertise, and we'll just kind of hope it all comes together, somehow. And, and of course, it mostly doesn't. But it's also true, I think that when you kind of throw those two groups together, which can be super useful for all kinds of reasons, they may not have a shared language, or they may not realize, like the things that you know, in this field, everybody just knows that, whatever that sort of basic, we don't even talk about those things, because we all just know it. And the other folks or the general public, you don't know those things in the same way. And so I think there's a piece about both getting good at that sort of translation and education and really explaining and expressing ideas. And maybe this is just my putting own my expertise in the mix with higher value, but I do think there's the thing about, you probably need someone on a team who's a translator. I don't think it's reliably true that people who have the expertise that you need for your business will necessarily have the skill to translate what they're saying, or to communicate it in a way that's going to land for the other, or that the other will have the skill to take it in. And I do think that this is a place where facilitators and that may not be their primary role, you may just have a team member who has that skill but what I think of as a translator, somebody who can really kind of inquire until they really get it and then sort of translate it into language that goes the other way. That is itself an expertise that needs to be on the team for shared expertise to work well.

Paul:

Absolutely. That understanding of how the interpersonal works, of group dynamics, of how we can actually bring these skills together is itself a skill and that needs to be present on the team. It's not just the technical pieces. It's also the interpersonal, the group, the how-do-we-work-together skills that you need. And you're right, sometimes that lives within someone who also has some of the technical skills that the team needs and sometimes it doesn't. And we need to be cognizant of that. Who can you find that is the glue that will actually help hold this group together effectively so that they can achieve the thing that requires all of those different skills?

Karen:

Yeah. And I think sometimes it's just the willingness to ask the questions. I had an experience in my younger years when I was fresh out of college and knew nothing about, you know, construction or roofing or anything like that. But I was in a management office answering phones and things. And one of the things I did was I worked with the roofers. We had a lot of roof that we managed. And we worked with really good roofers, well intentioned, great guys, you know, long term contract with it. And it was the same guys that came out over and over again. But what I discovered was that, if they came in, and I just sent them out to the roof leak, there was about a 50% chance that the roof leak got solved in that visit. But if I went with them and asked a bunch of questions understanding I knew nothing, I had nothing to contribute. But just asking enough questions, so that they would think through all the steps of what they were doing, that there was then about a 90% chance that that roof leak got fixed in the first round. And so I think that is a piece of getting the full expertise in the room actually benefits by somebody who doesn't have it, connecting and, and just that curiosity and interest and teach me so that I understand. It wasn't an accountability thing, it was just a process of thinking through and encouraging deep thinking about it. So the expertise got built in a different way or got applied in a different way.

Paul:

That's one of the things that is really amazing to watch with well-functioning groups is their ability to actually think collectively together. Where it's not just everybody's doing their own pieces by themselves and then hoping that it all sticks together, when we come to the integration phase. It's actually watching them go through their thinking processes together. That's actually where the benefits of multiple expertise come in handy, where they become useful, because you start to have things happen that wouldn't happen with those people doing that same work in isolation. And the thing that I often say is that collaboration is not a faster way to do things, it's a better way to do things. It will slow you down slightly because of the need to do more of those things together. But you will get way, way better results. And so usually, in these situations where we're bringing multiple different areas of expertise together, we're building cross-functional teams, it's because we need those better results. And so we need to make sure that the groups actually have some of that glue to hold them together, to make sure that they understand about group process, to make sure that someone's asking the "dumb" questions, to make sure that the group is actually getting the benefits of working together. And really asking each other about what each of them sees and what each of them understands about what's going on and getting curious about and respecting each other's knowledge.

Karen:

And I want to throw one caveat in there to your point, which is that sometimes faster is what you need. So there are times for experts to go off to their corners and do their piece and you don't need the input from everybody else. They bring it back and you don't need that level of understanding. So there is a discernment piece here about where are we needing to be in the collaborative collective mind because we need better? And where does it just make sense for the person who knows how to do that thing to take it and do it and bring it back have that faster piece work? So it is the balance between the two.

Paul:

Absolutely. Well, I think that's going to 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.