Skip to Content Skip to Main Navigation

Confessions of a Quality Queen: Getting Good Reviews in Bad Times with Remote Teams 

22nd November 2011 Posted in Blog, Documentation, Industry Articles 0 Comments

Editor’s Note: This was the feature article in this month’s TechCom Manager newsletter, reprinted here with permission. Click the previous link to subscribe to the newsletter.

Luanne Oleas, Author of Confessions of a Quality Queen- Getting Good Reviews in Bad Times with Remote Teams

Luanne Oleas

The projects, they are increasing. The number of writers is decreasing. Jobs are floating across oceans. Agile, thy name is fickle. What’s a good writer going to do? You have to change. Adapt. Be ready for anything, because chances are, that’s exactly what’s coming your way.

One of the hardest principles slipping from our grasp in these tense times is the quality factor. It used to be one area where the technical writer could be the master of his or her fate. Developers revised your content, project managers overruled your phraseology, but you, as an experienced writer, could still make the final product shine. Now? Not so much.

Part of the problem could be that your Subject Matter Experts (SMEs) are no longer sharing your water cooler. In fact, in this year’s budget, they nixed the water cooler, too. Your reviewers could be thousands of miles away, which can make motivating them difficult. OK, impossible. Well, almost.

We have moved to the “release it now” age of products and technical documentation. Horror stories now include the online help button that connects to nowhere. The appendix that applies to nothing. The readme that no one reads.

All the old standards are out the window. We are left with our wits, if we are lucky, and the wiles we’ve developed over the course of our careers. But sometimes, just sometimes, writers can defeat the deadline dragon. You can overcome the overriding fact that you are overwhelmed. How? Here’s four techniques you could employ:

  • Facing Facts
  • Future Casting
  • (Virtual) Face Time
  • Follow-up

Facing Facts

My manager once told me to stop banging my head against the wall. The wall wasn’t going to move. He was right. I had too many projects and too little time. His advice? Pick one project to do well to prove to yourself― and everyone else― that you are capable. The rest of your work? Just accomplish it somehow.

Unfortunately, for we technical writers, the mother of all perfectionists, this can be hard advice to follow. However, if we don’t follow it, we do so at our own peril. There is your health to consider and your career. Live to write another day.

When the economy turns around, when corporations start hiring again, you will rise from the documentation rubble, dust yourself off, and become the comma-Nazi you once were. For now, put your head down and keep typing. Focus on that one project that can be your show piece, and let everything else just be adequate.

Future Casting

Try to get the best start on a project that you can. This holds true particularly for the project you want to use as your special project. That project is going to get you your next job—after you recover from the one you have now.

In a word, have a plan. In two words, have a documentation plan. It can act as your shield throughout an exhaustive release schedule. If you can get someone to sign off on it, that’s even better. If you can’t, don’t worry. You are probably more organized than half the people you work with, and half of something is usually enough these days. If someone on the team has a schedule, even if it’s the technical writer, sometimes people will follow it. It’s easier than creating their own.

For the writer, the critical part of the documentation plan is the content of the deliverables being produced. This is especially true if you are using the Darwin Information Typing Architecture (DITA) method of writing. For the team of reviewers, the critical part is the schedule. Seriously examine the amount of the time available, and break it into segments stipulating what you are going to accomplish. Then, present the plan to your SMEs showing the days allotted for conducting document reviews.

Your distant coworkers will have an idea of what sort of time commitment you expect from them. Back in the day, reviewers would often have one week to go over the content. That week would include the reviewers wasting the first five or six days. Then they would cram the review into the last day allowed. Now, the prudent writer must list only days that are actually used for reviewing. Schedule a day, or three, in your plan and see if your reviewers balk. If not, you saved some time.

The truth is, this schedule will not be followed, but that’s not the point. The point is that you have established some laws of physics when it comes to the amount of time needed to write, and time needed for review. Later, when changes occur― and changes will occur― you can give the song and dance about how those changes will result in less content, poorer quality, or both. Leave it up to someone else to decide if this is what is best for the project.

Creating a timeline works well for the visual learners as well as those who will only glance at your documentation plan. Visio is great for this. My reviewers’ deliverables were above the timeline, and mine were below it. Other dates, such as the beta or GM (General Manufacturing) dates were also included for reference.

(Virtual) Face Time

Sometimes the hardest part of getting good reviews from remote teams is the fact that you can’t see them. If there was a possibility the reviewers would run into the writer in the hallway, they would be more responsive. The “out of sight, out of mind” concept tends to prevail in these days of looming deadlines and less time.

Scheduling a weekly meeting can make you seem like a real human being with real pain points and deadlines. I’ve had SMEs in China and India. It’s important to find a time when you can both attend. The crucial part of the meeting is not the issues you plan to discuss, it’s the ones you didn’t expect.

To make the most of meetings, I draft an agenda and send it in an email before the meeting starts. The benefit can be two-fold. One, you start with a list of issues to discuss, which always helps when you are on the phone/Webex/conference call with a group of strangers. Two, often if English is a second language for your SMEs, this can help speed up the meeting.

One of the most important questions to ask, and ask at every meeting, is “Has the schedule changed?” It’s often the technical writer’s lot in life to be the last to find out anything. With remote teams, you may not find out at all if you don’t ask and ask often. Schedule changes happen quickly, and often it is assumed that everyone knows there was a change. When you are not in the building, or in the meeting, you can be caught unaware.

The meeting is also a time of training. You need to work with your SMEs to train them in the intricacies of documentation. Often, they are unaware of company policies or even the general process of document review and approval. It helps if they have some time with the writer to describe this process for them.

Training is a two-way street. The writer may need to learn, too. For instance, if your main reviewers are in Quality Assurance (QA), you need to learn their modis operandi if you want to get the best feedback in your reviews. Your experts might return reviews with just cursory comments about the margins or the formatting. There are times, right before a release, when they are extremely busy. It might be a difficult time to schedule a review, but you may need one. It helps to note in your document or your review email what sections have changed the most. Break up the review of your documents into smaller sections. If you know your reviewers, you can target your reviews to the real SME for particular functions or features.


It’s important to respect your SMEs and follow up on the feedback they give you. I’ve been guilty of missing the odd email. I understand that. But when you do receive a document review, it’s important to: a) make the changes as requested or b) follow up with questions about the requested changes.

SMEs get swamped like everyone else. They too make mistakes. It’s important to question the review comments you receive, and when necessary, send follow-up emails.

Often comments can come in like arrows from all directions. Find a system that helps you track the suggestions. Use the multi-colored flags on those emails in Outlook to remember each comment that needs attention.

After you have received feedback on a document, find a method for keeping your reviews in order and for completing all the suggestions. It could be folders labeled “To be edited” and “Completed.” In my case, when I finish all the comments in a comment-enabled PDF, I rename the file (document_name)_done.PDF.

And in the end. . .

Make the most of the time, resources, and energy that you have. As my career (hopefully) continues, I plan to add even more techniques to my reviewing arsenal. Until that perfect day comes, when there are enough writers and editors to cover the work that needs to be accomplished, may these approaches facilitate achieving the quality you seek.

About the Author

Luanne Oleas is a Staff Technical Writer for Trend Micro, Inc, a global security company with locations in Nanjing, Taipei, Tokyo, and Silicon Valley. Luanne has worked as both a full-time and contract writer, for such companies as Cisco and Xylinx. In her current position, she has helped to organize workshops about DITA and Agile development. She has been a member of Society of Technical Communicators for over 10 years and has a degree in Technical Communications. She currently produces manuals and online help for enterprise-level software, SAAS, and cloud products, often working concurrently on multiple projects. She has been working with remote teams for over seven years. She currently has five unpublished novels and hopes to rectify that.

More for Technical Communication Managers

Be Sociable, Share!

Leave a Reply