By globalization I mean, not only writing for a world audience, but collaborating with coworkers from around the world. When working with people overseas, time zones can be a real challenge. My group has employees in Denver, the UK, and India. Trying to set up a meeting to accommodate everyone is tricky. Often the people in India are forced to attend meetings after regular work hours. This week I was contacted by someone in India and it was midnight at her home. Sometimes just getting a response to a question will take a day due to time zones.
Additionally if you are working with different countries, you need to be aware of that country’s holidays. Recently we had a large project due. Most of our overseas offices were unavailable due to a holiday. The corporate holiday was only one day, but the celebrations were in the evening the night before. Evening hours are often used as overlap meeting times, but that was not the case for the week.
Different colloquialisms are used in English throughout the world. This goes beyond “civilisation”, “taking the lift”, and “using the loo”. Professional documents may be created with non-standard American English words. For example, a cultural trend I’ve noticed is people in India arbitrarily append “-tion” to form new words, such as “upgradation” and “updation” (to match “deletion”). As technical communicators we need to be sure that standard English is used in formal publications and all client-facing documents.
Good communication is key to a successful collaboration. However despite our modern methods of instant communication, there are still discrepancies.
This comic illustrates communication issues commonly experienced in a development cycle. First the expectations must be successfully communicated to everyone. These often come from clients and work through product managers who interpret the clients needs into your product. Then the people who actually implement the changes need to communicate how they made the changes. These updates may or may not match what the product managers want, or what the clients asked for. As a technical writer your task is to describe the technical update in terms usable by the end user.
What ties this cycle together are communications between the collaborators. Such communications are fraught with peril! Email can be fast, but it can complicate things needlessly. “Q: This new feature is described as doing A, but the requirements ask for B. Is that correct?” “A: Yes. It does exactly that, and in describing that, I am describing C.”
“Q: Here are three questions I am asking you …” “A: The answer is Yes. But I will not tell you which question I am answering.”
Other Scenarios: People going on vacation and not setting their Out of Office messages.
Often complicated email chains could have been resolved with a conference call or face-to-face meeting. Meeting in person has become less frequent due to a diversely-located work force. However speaking isn’t always the clearest way to communicate. Accents and shoddy phone connections can ruin discussions. Last week I asked someone if it snows where they live. She thought I was saying “smells”, which resulted in a very interesting conversation.
Does Documentation get the highest prioritization in your product? You may feel like the low man on the totem pole, but in reality you are a step or two up from the man on the bottom. The people who get the points made by the client is usually the Support personal who are often caught between customer needs and an inflexible development force.
Sure, it may seem that Documentation is given the last thought. Changes are made at the last minute and not shared with you. Bugs are fixed with inaccurate descriptions of what was done to address the problem. In my company the release notes for software updates are taken right from the bug resolutions, which are created by programmers. Days are spent editing these resolutions since most are not suitable for clients.
I believe that Documentation doesn’t need to fit exactly into this visualization. As a technical communicator you can move out of this implied hierarchy, much like an agile climber who can ascend and descend the tree to interact with all parties involved, from the management at the top, to the support team and customers at the bottom.
As a technical communicator you possess a unique set of skills to allow you to work with people from all over your organization. While not everyone is an effective communicator, YOU are.
Write your email inquiries with only one question per email. If you have multiple questions, number them. Write your questions, when applicable, so a Yes or No could effectively answer you inquiries. Learn what your team members are personally interested in. If you show an interest in their interests, they are more likely to make time to help you out. Even the most unsociable of coworkers have a personal life. Look for clues as to what they like and work that into conversation before getting down to business. Maybe you’ll be surprised and find out you have more in common than you thought.
Use your superior abilities to communicate effectively across borders, span cultures, and get people to better collaborate.
Your expertise can affect: Product Development User Interface Changes Internal Documentation Practices Client Interactions Training Development Team harmony and bliss
It may be an uphill battle, but corporate leaders will take notice of the results your skills can help create. And if they don’t notice, you just need to figure out a better way communicate with them so that they do! Which you can totally do, if you think about it.
Their chief weapon is surprise! And fear. Their two weapons are fear and surprise. And ruthless efficiency.
So don’t be afraid to ask questions that will be surprisingly answered with ruthless efficiency.