3 tricks of the trade to maintain consistency among multiple authors

I have worked as a tech writer for nearly 10 years, and for all of those nearly 10 years, I have worked on a writing team. Working on a team can be wonderful, but it can also be frustrating. Teams inevitably face challenges—the largest being how to maintain consistency among multiple authors.

In tech writing, teams write as one entity. No byline or attribution is given to any published document. (If recognition is something you seek as a writer, tech writing is probably not the field for you.) Though no reference is given to any one author in a tech writing project, it can be obvious when one author’s work transitions into another’s. One writer uses present tense, another uses past, yet another uses future tense. This writer uses numbered lists, that one uses lettered, and yet another uses numbers, bullets and letters. All of this inconsistency among writers is a big problem. It can cause confusion for the reader. It can cause confusion for the writer.

Abrupt changes in format, style or voice can throw off your readers and even convey a lack of credibility.

A tech writer’s job is to distribute the information his or her users require to use a product correctly. Inconsistency can prevent you from doing just that. Worse still, writing inconsistencies can turn off people from using your product altogether. And that impacts the bottom line.

So how do we overcome inconsistency across writing teams? My software company’s tech writing team uses the three following tools to ensure consistency across our team and across our product documentation:

1. Style guides: Our writing team uses the Microsoft Manual of Style as our base style guide. In some cases we deviate from the Microsoft Manual. For these style deviations, we have an in-house style guide that is maintained on our company intranet. Our policy is to first consult the Microsoft Manual. If after consulting the Microsoft Manual we feel the situation isn’t adequately covered, or if we feel a different approach would work better for this particular document or format, we attempt to find an in-house solution. First the issue is brought up to the team. After a team discussion, we vote on a decision for the appropriate style for the situation in question. If the agreed style deviates from Microsoft, it is added to the in-house style guide.

2. Peer reviews: (Included in the life cycle of a document.) Our writing team uses five steps in our definition of a document life cycle. We call these steps release states, the steps necessary before a document can be released. Included in these release states are two reviews: one review completed by our subject matter expert (SME) and one review completed by another person on our writing team. The first review ensures that the content is on point; the next ensures that we adhere to grammatical, spelling and style standards.

3. Team editors: Our team has one writer who also acts as the lead team editor. (That person happens to be me.) Team editors should have a love and eye for editing, as well as a self-driven desire to edit. Often during busy release cycles there isn’t enough time dedicated for the editing and review phase. If this happens too often, your team’s consistency will take a major hit. It is the team editor’s job to ensure the team sets aside time for reviewing and editing product documentation before it is released to users—before every release—regardless of how much time is dedicated to reviews and edits. The team editor has a responsibility to look for and keep track of recurring style and standard issues, and to ensure that these issues are addressed by the team in an effort to achieve consistency across all product documentation.

Consistency across teams doesn’t happen magically. It is something teams must strive to maintain on a daily basis. Dynamic style guides, peer reviews and appointed team editors are three tools writing teams can use in their efforts to achieve and maintain consistency among multiple authors.

Photo by Matt Hampel