Being a Technical Writer in a team with extreme time zone differences

This article is a summary of a Technical Communicator’s experience working in a distributed team with 9 hours of time zone difference.
But first, let’s use our imagination and …

‘Houston, do you copy?’

Imagine you are flying through space. Your space station is orbiting the planet at a mind-blowing speed of 28, 000 kilometers per hour or 7.6 kilometers per second.

You are not flying for the fun of watching the sun appear over the horizon 16 times per day. You have lots of work to do. For many tasks, you can manage on your own. But sometimes you’d rather use a subject matter expert (SME) advice before you proceed.

How do you talk to your mission control when you need help?

Well, if you are NASA, you have communication centers deployed across the globe, so you can talk to mission control at any given moment.

But what if your mission control is only on one continent? How does this impact your communication pattern?

In this case, the radio waves can only reach the receiver when your space station is flying directly over the needed continent. For the rest of time, you are sending your messages to the cosmic void. So, you are waiting, waiting, and waiting until the desired land comes into view.

That’s it, grasp the moment and talk as fast as you can! Soon your ship disappears over the horizon and now you have got to wait for another happy time overlap to chat with mission control.

Sounds difficult, heh?

Now you can imagine what it feels like working in a distributed team with a 9-hour time zone difference. 😄

Of course, this comparison is a little extreme and a Technical Writer would not be flying in space while crafting product documentation (although it would be fun!). However, when you only have an extreme time zone difference with your team, it is exactly how work communication feels.

But let’s start from the very beginning

My name is Vasylyna and I’m a Technical Communicator. For the past year, I have had the privilege to create end-user and developer documentation for teams located on the other side of the globe.

Time zone differences are no news for European software development companies working with North America. However, most of the development team is usually located in the same time zone, which simplifies the communication.

For the case in question, I’m the only team member in Europe while the rest of the team is in the western part of North America, which gives us literally 2–3 hours of time overlap during the day.

So how does one survive such time zone extremities?

The short answer is — with pain. Makes one reminiscence of ye olde days when the product development teams could sit in one room, standups were real face-to-face gatherings, and team coffee breaks were a thing. With no possibility to turn the tide of time back or teleport myself to SMEs, I had to search for other ways to work effectively.

Some of the given recommendations break unspoken rules, but trust me, there is a good reasoning for that.

Shift your working hours

The first and most obvious solution is to readjust the working hours by starting one’s day later and wrapping up around 7–8 PM.

This gives about additional 2–3 hours of overlap, which mostly consists of daily standup meetings. This brings up another issue — how does a Tech Writer conduct SME interviews and stay up to date with changes when there is so little time to talk?

Keep reading to discover my solutions.

Be a Tech Writing detective

Start every day by being your own detective Colombo (or Sherlock if you please). This includes:

• Reading emails
• Skimming through team chats
• Checking commentaries in Confluence
• Having a glance at the team board and tasks
• Peeking into the code changes

Detective responsibilities go as far as being able to find the links and materials on one’s own. For example, I needed to take a nice screenshot of a CI/CD pipeline run, but I didn’t have a link to it. Instead of waiting for my SME to log on and help me, I used the GitLab search to find what I was looking for.

Start your investigation early

Is it the very start of the sprint? Even if the majority of the user stories are still waiting to be assigned, you can already start digging into them. Remember that you are learning something new, and your task is to write documentation about it and sound confident.

Sometimes learning a new technical concept is extra hard, especially when I lack a technical background and have troubles operating basic concepts. That is when I start googling. And the more I dig, the harder it gets. Sometimes I end up opening an Azure, Terraform, or GitLab article, and the only things I fully understand are articles and prepositions. The rest of the words are either new or don’t make much sense when put together in a sentence.

This is where generative AI comes in handy. Here are examples of prompts that I asked ChatGPT:

“Act as a seasoned DevOps who is explaining concepts to a newbie. Explain what a Docker image is. Provide examples of using a Docker image during application deployment.”

“Act as a cloud developer who designs data flows for applications. Explain what the difference is between Microsoft SQL databases and flat files in a Blob Storage. Provide use cases when each of them would be used.”

“Act as a seasoned Git expert who explains concepts to a newbie. Answer this question: If I commit my changes, and then switch to working in another repository, will I be able to push my changes when I return to the first repository?”

“Act as a specialist in Azure Function Apps hosting who explains basic concepts to a newbie. Explain what a SKU within the Premium plan Function Apps is. Use simple terms and examples.”

Important part here is to tell AI it’s talking to a newbie, so that it generates the most understandable examples.

Remember, that the more difficult the concept is, the earlier your investigation should start. When trying to understand machine-to-machine authentication, I spent 30 minutes every other day revisiting the materials I already had until the understanding finally dawned on me. The more concepts I could figure out on your own, the more I was able to understand without bugging the always-busy SMEs.

In this way, when I had those precious 5 minutes of standup after-party discussion, I could use them productively to ask only those questions I could not figure out by myself. Thus, instead of asking a myriad of questions starting with ‘What is a pipeline job and what is a trigger?’ I asked, ‘Will this job be triggered if a user configures x and y?’.

Ninja soft skill: make yourself seen

To this strategy, there is an important impediment called learned helplessness. When the team is big and distributed, one feels helpless and not seen. If feels like whatever you propose or try to change, your voice is unheard. Over the last year, I had to learn helplessness, and then get rid of it.

The three important points for me here are:

1. Getting to know each other on the team takes time. If the team is distributed, multiply this estimated time by 10.
2. Putting your soft skills first. Show that a Tech Communicator is a part of the team as well. Speak up for yourself, accustom people to your presence and participation. Show up to standup meetings and turn on your camera. Ask questions or raise your concerns even if the question is teeny tiny and you feel awkward. If there is a meeting you cannot attend, ask for it to be recorded.
3. A bit of luck is essential. Whoever leads the team, be it a team lead, product owner, or scrum master, it is vital that they step in. Their big role is to facilitate discussions, pay attention to all opinions, and foster small talks to help people get to know each other. Without their support, try as you might, you are doomed to be left off-board of the main communication channels.

Be yourself (including the weird part)

Do you know nerdy jokes? Do you like to scroll funny memes? Well, my friend, your relentless effort might finally pay off in a business context.

There is nothing better than easing people off with a meme when you need something from them.

For example, when asking to be assigned admin permissions to a resource, I used a GIF of a cat from Shrek to attract attention.

And here is me inviting a developer to chat about a difficult topic.

Write two drafts and afford the luxury of time

How do you imagine the writing process?

Here comes inspiration and your fingers fly over the keyboard, typing and typing those amazing sentences and paragraphs, where everything is super logical and cohesive. Well, no.

Everyone who has written a document in their life knows how many logical gaps can creep into the text.

Thus, I like the idea of writing two drafts. The first one is not pretty to put it mildly. It’s a mashup of requirements from user stories, information captured from recordings and demos, and some ideas of mine on top of it.

I like to let such a draft sit for at least one night before I proceed working on it. During that waiting time, your brain processes the new information and finds better logical connections, and then comes the aha moment when all the pieces come together.

That second draft, after being self-reviewed, is good enough to be seen by someone else’s eyes. This approach is what I would recommend to everyone writing technical documents.

Give up the idea of perfection

Does this sentence hurt? Wait, there is value underneath.

With little to no time to chat with your teammates, your goal is to get their feedback as fast and effectively as you can. At this moment, your team cares not about perfect grammar, styles you applied, or perfect screenshots you took from the final version of the application.

The content can be rough around the edges, the screenshots could be Figma designs — what matters is that you get the nitty gritty technical details right.

Provided that SMEs are busy people, getting review and feedback takes time. It is important to allocate a couple of days for cases when an SME forgets to check your document, and you must gently ping them once or twice.

Sometimes I bring up the document during the standup after-party discussion to make sure everyone has seen it. And in some rare cases I’m lucky to have an SME meeting for a full-scale review.

When the technical side of the document is done, I have all the time in the world (a.k.a all the time with no time zones overlap) to fine-tune sentences, take better screenshots, and scrutinize over commas, capitalization, and double spaces.

Allow for chaos to jump in

Because it is going to happen anyways. Miscommunications happen from time to time, priorities change, and so do the release plans.

No matter how hard I try to stay on top of things, unexpected turns happen. Accepting this reality might have been the hardest of lessons to learn. Having good relationships with the development team helps tackling risks and uncertainties gracefully and release the documentation on time.

Summing up

Overall, connecting and working with a team with 9 hours of time zone difference is arduous, and it can feel desolate sometimes. Moreover, there is no ultimate cure to the occasional sensation of missing out.

However, applying one’s soft skills to build relationships with the development team pays off in the long run. And applying one’s detective skills to become a tech-savvy Technical Writer pays off even more. When combined, you become that seasoned Tech Writer who brings value despite the obstacles.

And how do you tackle time zone differences in work? I will be happy to read and respond to your commentaries.

Until then, happy writing.

Over.