Remote technical writer best practices


I worked on my first remote technical writing project when dial up was still dominant in homes, and I find myself still learning as I go along. Remote technical writing projects can work. However, I’ve come to see over time that not every organization can support remote writers. Likewise, not every writer is cut out for working remotely.

Here are a few best practices I’ve come across over the years:

Use the cloud for file hand off and version control

I’ve been burned myself so many times by emailing files back and forth that I should know better. While it’s not a factor when writing articles or blog posts (lightly formatted and simple documents), it is a factor when working on more complex documents. Now with cloud platforms like Podio, Dropbox, and Box that include free cloud space price isn’t an option to not setup an option for file hand off and version control.

Another benefit of using the cloud is it offers better support for alternative work schedules and projects that span time zones. It’s better to have files in the cloud versus the email inbox or local hard drive of a part-time off hours technical writer for security and convenience of other team members.

Use social task management tools to keep the project on track

Asana and Producteev offer intriguing (and free!) options for tracking all the tasks around documents. In fact, I use Asana regularly for editorial checklists on a corporate project and when writing articles and blog posts

Remember not every organization is remote writer compatible. For a range of reasons that aren’t entirely the remote writer’s fault, there are some organizations that just can’t support a remote writer for reasons of corporate dysfunction, politics, and other such things.

I’d like to say that I have sure fire way of qualifying such organizations but I don’t have that trick down yet. Way back when I was a computer book technical editor, the publishing industry had worked with remote contractors down. Remote writer compatibility, usually, breaks down to the following:

  • The right kind of writing project
  • Communications
  • Project management

Technical writers get ignored enough in some organizations when they are in a cubicle at the end of the row. When a technical writer is faceless, it adds another level of potential error into the usual project communications mix.

Use track changes and comments

While it’s easy to hate on Microsoft Word, Word’s track changes and comments are ideal for edits and reviews on documents because they leave an audit trail that’s easy for other team members to follow. Any comments that aren’t approved can always be rolled back. Alternatively, you can review documents as Adobe Acrobat PDFs with the Adobe Reader’s annotation tools.

Write emails, questions, and review comments that can stand on their own It’s one thing to have to defend and add clarity to your communications and comments while working in the same office. However, it takes on an added shade of importance when working as a remote writer.

Use mobility as a redundancy

I keep many of my working files in Dropbox so I can access them while I’m away from my PC from either my iPhone or iPad. I’ve also had to send out client emails during one of the usual Fairfax County, Virginia storms to alert clients when my power was lost.

What are your remote technical writer best practices?


Originally published at willkelly.org on August 30, 2013.

Managing technical document reviews for geographically dispersed teams


Even in the day of mobile devices and Enterprise Social Networks (ESNs), organizations can’t escape the need to review business and technical documents for accuracy, completeness, and message. I’ve been a student of technical document reviews, technical reviews, or technical editing. In fact, I was a computer book technical reviewer during the great computer book over publishing of the nineties.

Here are some tips for managing document reviews if you are on a geographically dispersed team:

Centralize documents online. Teams should place their documents in a central document repository whether it be SharePoint, Huddle, Dropbox, Box or in your project management applications. Emailing review documents back and forth only invites version conflicts.

Establish review guidelines. Truth be told; many organizations don’t know how to review and approve a document. As such, it is important to set out how you want your reviewers to check over each document. Your review guidelines should instruct reviewers to do the following:

  • Follow procedures step-by-step and tell reviewers to point out incorrect steps and identify why the step is in error.
  • Look for better ways to present data, or identify if a different function or listing that would work better in the same situation.
  • Verify if the artwork (listings, figures, illustrations, and tables) corresponds with the references in the text.
  • Test each line of program code and describe any problems.

Designate document stakeholders. Have a designated document stakeholder check over the document(s) undergoing review to help set review priorities and free up resources to ensure the document review happens on deadline. The stakeholders can also tie the document review into the overall project plan if needed.

Identify primary and backup reviewers. When project teams span multiple time zones, and even continents, it’s best to identify primary and secondary reviewers. If the primary reviewer is unavailable to resolve a question, then the team can always go to the backup reviewer.

Set a realistic review schedule. It is rare that a stressed and harried project team can make a full document review in just one pass. So depending on your project schedule, take the initiative to manage expectations and set a review schedule that ensures reviewers are going to add value to the documents they are reviewing.

How does your team manage document reviews?

Image by stock.xchng user: graphiteBP


Originally published at willkelly.org on December 8, 2013.