Best Practice - Inclusive Language

I've written earlier that Us/Them thinking is the cornerstone of success, or of failure, for global teams. A necessary but insufficient prerequisite to Us thinking is inclusive language. This best practice essay will explore a couple of scenarios, and show both exclusive Them oriented approaches, and inclusive Us oriented approaches.

Put simply, in order to build a highly functioning team, both leaders and staff have to steer away from language that puts up a barrier, or creates a feeling of division in the team.

Unfortunately, this is easier than it sounds.

Here's an example of how a development manager might approach a situation with her global team. The scenario is easy to imagine. Lots of developers are working long hours, there's an integration sprint, and work needs to get checked in so an automated nightly build can kick off. The manager, based in the United States, is talking to her team in India, during an early morning conference call.

We build at midnight, and it has to work this time! You guys better not break the build!
  • The approach creates an Us/Them dynamic right from the start. We're building the software at midnight.
  • That's midnight Our Time.
  • And we're worried You might break the build.
  • The manager might think she's doing a good job communicating urgency and holding her team accountable. But the choice of language and tone here creates an adversarial environment.
This simple, 30-second dialog has established a tone that pits the offshore team against the success of the project. Her team has just become a bunch of people who don't trust one another, but who happen to be working on the same code base. That's not a team. It's a recipe for disaster.

An alternative approach, with more of an Us oriented take on the same scenario, might sound like this:

QA is lined up to start testing this release tomorrow, so we have to get a good build today, team! The automated build script will kick off tonight at midnight EDT - what's that, 09:30 IST tomorrow? How can we all make sure that everyone in the Bangalore group gets their work checked in, and that everything compiles cleanly? Does anybody on the phone have any ideas on how we can make sure we get a good build tonight?

Notice a few things in this alternative approach:
  • The dialog conveys the same information, and asks for the same accountability, but the tone is completely different. It conveys a sense of urgency that is shared, not adversarial. We have to have a good build today team establishes that We're in this together, and that it's an important milestone for everybody.
  • The midnight is qualified with a time zone. That's important. Even if you're the boss, assuming that everyone who hears you speak automatically adjusts to what ever time zone you're secretly thinking about is just obnoxious, and it is divisive, and it makes any portion of your team not in your timezone feel like second class citizens. This manager handled the time offset within her team well.
  • Instead of confronting the remote team with a statement that impugns their professional skills, the manager approached them with a challenge to speak up and solve a problem, together. And she acknowledged that she was talking to a room full of people she couldn't see, by saying anyone on the phone. That is a huge motivator if you happen to be sitting in a conference room huddled around a Polycom.
Of those two managers, I know which I'd rather work with, and I know which is likely to be more successful at building a good global team, or getting a good overnight build for that matter.

It isn't just managers who have to pay attention to this Us/Them language. Staff engineers have just as much impact on team dynamic as their managers - maybe more! Imagine the scenario continuing like this:

It's the next day. Romesh, one of the development engineers from India, missed some files when he did his check in, and the build broke. Joe and Brian, both development engineers in the United States get in to work at 10:00 EST and find that the build is broken. They're standing around waiting for coffee to finish brewing when this conversation transpires:

Joe: Did you check mail yet? Looks like the build broke.

Yeah, I looked at the build log. Who's romeshg?
He missed a bunch of files and broke the build.

That's Romesh something or other. He's one of the offshore guys.

Man, they are horrible. Those guys are just clowns. I can't believe management lets them screw up our code like this.

This is clearly not an inclusive set of statements. You might think it doesn't matter how an engineer in the United States talks about a teammate in India. Romesh, after all, is out of earshot. But it does matter. Energy follows thought, and the thought in this case is clearly adversarial. In this case, both Brian and Joe walk away feeling peeved at their Indian coworkers, and feeling victimized by the global contingent of their team.

A better dialog might start the same way, but could take a different turn all together with a little inclusive language:

Joe: That's Romesh Something or Other. He's one of the offshore guys.

Brian: Man, they are horrible. Those guys are just clowns. I can't believe management lets them screw up our code like this.

Andy walks in looking for coffee, and overhears this conversation..

Andy: You both know Romesh. It's not Romesh Something or Other. It's Romesh Gaikwad. He came here for three weeks last fall, and sat in the cube next to mine. We all went out for beers together.

Joe: Oh, yeah, that Romesh... He was a nice kid.

Andy: Yeah, he's a good guy. What's the deal?

Brian: He broke the freaking build, that's what the deal. He blew a check in. Those guys are just clowns.

Andy: So? How many times have you broken the build this release?

Brian: Hmm. Seven. What's your point?

Andy: My point is you should cut Romesh some slack. We've all broken the build.

Alex (the release engineer) walks in, also looking for coffee.

Alex: Hey, I've been IM'ing with Romesh for the last couple of hours. He saw the build log and came in early while we were sleeping to fix his screwup. I kicked off another build a few minutes ago. Should be done soon.

In this second dialog, instead of walking away feeling annoyance at the "offshore guys", the original engineers feel a little shame at judging Romesh unfairly. After all, he screwed up, but no worse than any of the hotshots on the onshore team. And he did the right thing and fixed his screwup, before any of the onshore team even got their first cup of coffee. It was probably hard for Andy to stand up for Romesh in this situation. But he did, and he created a situation that contributed to Us thinking, instead of reinforcing a combative Them attitude.

To boil this down to a few action-oriented sound-bytes:
  • Say and think "we" instead of "you".
  • Remember that working remotely is hard on everyone. Acknowledge it verbally, and try to make the time-offset into a strength.
  • Involve the team in solutions. Instead of demanding performance, ask the team how they can achieve it.
  • Learn the names of your team mates, and don't make fun of their names, even if they sound funny to your ears.
  • Stand up for your teammates. Hold them accountable, but don't create a double standard.
  • Make sure everyone knows that there isn't a double standard.

No comments: