Working with an Offshore Team

by Samantha Lizak

Do you ever find yourself casually picking up the phone to call your subject matter expert over in India? No, neither do I, and at least half my subject experts are in India. Another group is in Egypt, a few are in Russia, one is in Japan, and some are on the eastern U.S. seaboard… (And yes, there are a few in Oregon too—but I walk down the hall to ask them questions.)

So how do you get information when your developers are many time zones away? The basics include getting on the project team, being flexible about what you are willing to do, letting your subject matter experts know when you can meet, and being imaginative in presenting your questions so that you can understand the answers. Because this is easier to say than to practice, in this short piece I'll focus on some of the best practices for the channels I use.

Face-to-Face

If your team is assembling somewhere, or a developer is visiting your site, take advantage of it! The time may not be spent directly exchanging information, but it goes a long way towards building trust. Although I was skeptical about the need for relationship building in a mandatory professional partnership when my time was urgently needed elsewhere, it has paid off in easier communication. The replies I receive now often anticipate my questions (such as "Can I put this code example in the manual?") and I've even been directed to information before I knew I needed it. I've also been included in more casual conversations, where formerly I'd have been left out because they weren't ready to have the subject documented yet.

Of course, the drawbacks are that management may not appreciate time being spent on activities not directly related to crafting deliverables, or they may think that you are risking poisoning a decent work relationship. (I've experienced "anti-chemistry" twice when meeting pen-pals; thankfully this has never occurred with a work relationship!) Keep in mind that everyone is busy and wants to use the developer's time effectively; rather than scheduling a one-on-one, include yourself in any team activities or design meetings.

Email

Email is my favorite technique, because:

• The messages are easily stored in case the project is put on hold

• I can bundle several questions together or include attachments

• Everyone potentially has time to think through his or her response

• It is easier to puzzle through a poorly written message at my own pace than to comprehend a strongly accented remark (even when the strong accent is from the US, such as Boston).

Most of the problems with email are the same whether the recipients are down the hall or across the world, such as the tricky nature of written humor or the difficulty of trying to get your email noticed amongst the rest of the messages. I have noticed some additional problems, however:

• Reviewers who are holding out on a point of English rather than a point of content will sometimes try to use the time zone difference to block the manual's approval. Because the writer is usually under a great deal of pressure to release the manual quickly, and because the technical point is sometimes impenetrable for the writer, this situation occasionally works to get the expert's words in just as he wrote them.

• When discussing schedules, a manager has to work harder to eliminate confusion over dates and times. I thought this was a cultural difference until a manager in Oregon commented on the trouble he had pinning down developers from his native country on completion dates. On the phone, he can press until he has an answer that he understands, but over email there are comical communication misses.

Either of the above situations can necessitate the next channel, phone calls.

Telephone

Like email, telephone calls can include multiple parties. The main difference is the immediacy, which is both a benefit and a problem. Over the phone, it can be easier to detect how the audience is reacting to a question and catch misunderstandings before the dialog has traveled too far off path. The response time, even with repeated questions and international telephone lag, is better than the best computer-based collaboration tools. You need to guard against the following issues, however:

• People talking over each other. I have weekly meetings that include developers in the United Kingdom, Egypt, and India, and the variable phone lag causes the conversational equivalent of a hallway dance as speakers start, back off, re-start when they hear silence, and maybe try again.

• Cultural differences in the length of comfortable pauses and whether side conversations are okay also contribute. Some groups have found it helpful to explicitly discuss protocol.

• Making sure everyone understands a conversation. Non-Americans often describe Commonwealth English as "stilted", and as writers we're certainly aware how difficult it can be to understand the other extreme. Heavy accents, whether they are across the room or across the world, add another dimension. When the telephone is connecting groups of people sitting together, there is a tendency to talk elliptically, pointing to things sketched in the air. Use your active listening skills-better still; teach the others to use theirs, and make sure you understand what was meant. I thought I just had an exceptionally poor ear until a project manager thanked me for my notes. He was also having a hard time but had been shyer about asking "stupid" questions. People understand that at least some of the group got up too early or are up too late and need extra help.

• Finally, international phone lines are not as reliable as intracontinental ones - we've had conferences interrupted by echo chamber effects, too much drop out, and even parties losing half the connection completely. Make sure that all parties know what to do if the call needs to be reset.

Samantha Lizak is a technical writer at Mentor Graphics, where her duties include staying awake for late-night project meetings followed by early morning conference calls. She can be reached at samantha.lizak@verizon.net.