From a Distance

(Side note: Every time I see the acronym for Subject Matter Expert, I think of Smee from Captain Hook. Every time.)

Through a co-worker's blog, I came across a post about sitting near your SME at the office. I cannot agree more emphatically. At NI, most of technical writers sit in the same general location as the engineers for whom they write documentation. For most of my three years here, I could swivel my chair 360 degrees and have a direct line of sight to all of my engineers.

I strongly believe that this proximity is key to establishing quality documentation. When the barrier to interaction is low, you are more likely to ask SMEs questions. If you have follow-up questions, you don't have to wait for these follow-ups to percolate through the developer's email inbox -- you can walk over to their cube and have a discussion. The developers are more likely to take your presence and schedule into account - meaning, if the release date slips or if they decide to add six new features, it's easier for them to inform you in person (where, again, you can ask follow-up questions on the spot). Because they don't have to work as hard to tell you about these changes, they're more likely to tell you. You're also more likely to socialize casually in the office, an action that improves interpersonal communication in general.

Phones and email and instant messaging are wonderful and great ways to assist technical writers. But oftentimes there's no substitute for face-to-face communication. Especially not when you're trying to ascertain the finer points of model predictive control :-)

So for all of my time at NI, I've enjoyed these benefits. This situation changed last year when I wrote the documentation for MATRIXx 8.0. During that project, I had to be aware of a small time-zone difference when calling and emailing my engineers. This was only a problem early in the morning and at lunch :-) To ease the pain, we had numerous conference calls, and in 2006 I even spent two weeks at their office so I could better understand the product during its development.

But at least my developers were in the office at the same time I was. This situation changed even more drastically when I begun working with developers in other countries. At this point you're introduced to the fascinating world of late-night (or early-morning) conference calls, reviewing & commenting on documents electronically, and never actually meeting the people you're working with. Add in language considerations, and you have a whole other ball game.

I wouldn't say that this distance decreases the quality of the documentation. However I would say that you don't get as many chances, or you have to work extra-hard, to keep the quality of the documentation consistent with what you've been doing locally. For example, consider this situation:

I email a developer in our Shanghai office at 3 PM CST. They don't get the email until 8 PM CST (9 AM their time). At this point I'm obviously not at work. I don't get their reply until 9 AM the following morning. This email has made its round trip in 18 hours. Compare that to 2 hours or less for a typical email to someone in Austin, or even California.

This fact underscores the importance of being precise when you're corresponding remotely. What if I have follow-up questions, or need clarification, to my Chinese co-worker's reply? I send this hypothetical follow-up email at 10 AM. Then it's another 23 hours until I get all of my information.

Total time for information flow: 41 hours. That's almost two days during which I am stuck on a problem or unable to do my job. And I'm assuming here that the developer actually has time to answer my question during their workday. If not, add another 24 hours onto the cycle.

I see a couple ways to mitigate this issue. One, be as detailed and precise as possible when emailing remotely. Treat your co-worker as an audience of one. Anticipate questions they might have and answer them in advance. Two, you can stay up late or get up early so that you're both in the office at the same time. Three, and this is the most effective measure, try not to rely on remote locations for decisions or information. (I know, I know -- easier said than done!) The finer points of this solution include making every use of local resources. You could spread knowledge around so that no one person solely is dependent on any other person (we also like to call this the "hit by a bus" defense). Four, and this is the most fun measure (at least for me), travel to the remote office and spend some time there :-)

(I just realized that the above paragraph probably should be a bulleted list.)

This situation obviously isn't unique to technical writing. These intercontinental concerns happen also with software development, upper-level management decisions, and technical support. Thankfully, at least in my case, you could get some fantastic travel opportunities out of this way of working. Which is my own very subtle way of segueing into the fact that I will be living and working in Shanghai for at least the first half of 2008. I leave in one week. I look forward to posting about my international technical writing experiences :-)