This article will be the first in a 2-part series that explores the problems and solutions I’ve found in managing a globally distributed project team. Over the past six years, I have been the technical project lead for several projects with teams spread all over the world. Before that, I managed many other projects where most or all the team members were co-located. On my last project, I had team members in London, New Jersey, Washington, D.C., Miami, Dallas, Denver, Buenos Aires, and India. While the challenges with both types of teams are similar issues, teams are spread out, sometimes across time zones, many languages and cultures can be more challenging.
This first part will focus on a variety of issues surrounding how a breakdown in communication can erode a team’s performance and impact its esprit de corps.
Cultural Differences in the Meaning of Basic Words
Sometimes, even basic words can have profoundly different meanings in different cultures. The following article is a perfect example of how “yes,” “no,” or “maybe” are treated differently in the United States vs. other cultures: Yes, No, or Maybe? Communicating Across Cultures.
For an American project manager who doesn’t understand that in some cultures, the word “no” is rarely uttered for fear of issuing an insult, this can have profound impacts when you’re trying to understand if a developer is going to be done on time or not. This article goes even deeper into how different cultures interpret English: HOW CULTURE IMPACTS THE WAY, WE THINK AND SPEAK.
The point of all this is that if a manager is aware of these differences, it will change how questions are approached and hopefully minimize miscommunication. Instead of simply asking someone if they're going to be done on Friday, ask more probing questions like what percentage of the way are they, have they encountered any roadblocks, and what challenges have they faced. If a project leader takes the time to understand where a developer is at with their project, they won't require the developer to answer the question in a way that makes them uncomfortable.
There also could be language and cultural differences that make communication more challenging. For example, I never realized how many phrases I use until I started working with colleagues from Argentina. If one of these idioms like “fill in the blanks” were to be used while conveying requirements, it’s possible this phrase could be taken literally and result in a UI filled with input fields when you were actually trying to say that there were still a lot of questions to be answered about that UI design.
Native English speakers need to be aware of how the words they’re using are perceived. Idioms should be avoided, especially with team members who aren’t as fluent in English. When speaking with team members from other regions of the world, I try to slow down and use more straightforward sentences that convey my point more efficiently.
While most of the time, idioms are amusing, they could sometimes cause more profound problems. Here is an example which honestly took me quite by surprise that I’ve seen on many sites on the internet:
A subtle area that can confuse stems from the tone of your voice, which may not translate well or at all with colleagues where English is a second language. Think of the word “really” and imagine different ways it can be said: affirmative, sarcastic, questioning, doubtful, cynical, etc. For team members outside of the United States, subtleties in meaning based on intonation alone may be lost. I’ve found when speaking to team members from other countries that I continuously need to resist relying on tone to convey meaning and instead, as my mother would say, “use my words.”
Clarifying What You Heard to Confirm Your Understanding
An excellent tactic I learned long ago when discussing complex topics is to reiterate what someone just said to me in my own words. Not only does this internalize the idea for me, but it also ensures that I’ve understood it correctly once the listener confirms the point. It also gives the listener a feeling that they are being heard and understood, which is something everyone wants. Even more importantly, this allows the listener to clarify their point if either I misunderstood it or if they didn’t convey their message correctly. This tactic helps to avoid misunderstandings and shows the listener that you are interested in what they’re saying and want to make sure that you fully understand. The following is an article that more fully illustrate this topic:
Managing distributed teams is harder when in-person communication isn’t possible. Think about how much information is conveyed through body language alone. If you say the words “you’re right” with a frown and a shake of the head vs. a simple nodding head, that phrase means two radically different things. Distributed team members need to be aware of this. I have found that on conference calls, I need to slow down and choose my words carefully to get my point across fully.
Even on a video conference or meeting in person with team members from other regions of the world, there are significant cultural differences in body language that managers need to be aware of. Examples of these are illustrated here: Cultural Differences in Body Language to be Aware of. One example from this link is the ‘OK’ sign in the United States means something far more insulting in Greece, Spain, Turkey, and Brazil. If you’re interacting with a person from a different culture, it’s worth researching any differences in this area to avoid confusion.
Regarding video conferencing, while I do believe it has value, mainly because it can help to convey body language, I personally find it distracting to see my face while I'm trying to talk. Even if I can minimize this window (depending on the conferencing software), it’s not possible to achieve real eye contact with another speaker, so it actually ends up as a distraction for me. Over the course of several projects with some of the same team members, we also found that video calls are more bandwidth-intensive, which can be an issue when meeting with people in certain parts of the world. This is why my teams have usually chosen to suppress the video on conference calls and stick only to audio and screen sharing.
To further mitigate issues facing distributed teams, requirement documents need to be much more rigorous and contain well-designed UI mockups, process flow charts, and logical data models where applicable. I discuss this further in my previous blog: Bridging the Gap Between Business and the Development Team: The Business Analyst.
Ideally, this documentation should exist in some collaborative space like Google Docs or even better yet a Knowledge Base wiki using tools like Confluence or SharePoint. This will allow a context-based exchange of questions that don’t need to take place in real-time.
When managing a geographically distributed project team, it’s vital for team members and especially for the project leadership to be sensitive to differences and impact of people working in different regions. The key is mutual respect and understanding. An example of this is respecting the holidays and customs in different areas. Why would you make your team members work on their country's independence day when you wouldn't think of working on the 4th of July?
It's also essential for team members to be cognizant of language and cultural differences. For those of us in the United States, that may mean we need to speak a bit more slowly, simplify our sentences when possible, and avoid idioms or shading the meaning of a sentence through intonation.
By being aware of how to overcome the challenges that face geographically distributed project teams, managers can ensure not only better cohesion and productivity for their team but also hopefully give their project a better chance of succeeding.
Please be sure to read the second part of the series, which will focus on how to keep the team balanced to ensure that everyone has an equal voice regardless of where they’re located. It will also discuss how to keep members of a distributed team all moving in the same direction as smoothly as possible: Overcoming the Challenges of Managing a Geographically Distributed Development Team - Part 2: Keeping the Team Balanced