Peer Review Strategies for Technical Writers

Learning from Your Colleagues

Writers’ groups have existed for as long as there have been writers. Their goal, other than providing an excuse to gather with kindred spirits over coffee or beer, is to obtain expert critiques of your writing. By understanding the comments and learning to distinguish between valid and invalid criticisms, you learn to write better stories. I’ve participated in such groups, and members have ranged from supporters who actually cared about my aspirations as a writer to ruthless egotists who mostly wanted to prove how much better they were than me. If you have a few idle moments, visit my fiction page to see whether I’ve learned anything from their feedback.

Most technical writers have encountered this approach in the form of peer review, but peer review most often has a different focus: to replace a full-time editor rather than to teach writers to write better. Because the goal is to improve the manuscript rather than the writer, honing writing skills often isn’t a priority. Editors, of course, aren’t writers; we’re rewriters. Nonetheless, we can still help each other learn. Since the goal is to discover our blind spots with help from colleagues who have different blind spots, editors can benefit as much as writers from this approach. The goal is identical for both professions: to learn what you miss when you revise manuscripts. Only the author of the manuscript being critiqued differs.

I’ve been part of two editors’ groups. First, I participated in the copyediting-l discussion group  for 20 years. This taught me that, even in an online discussion by a virtual community, learning how and why colleagues do things differently is a great tool for honing your editorial skills. Unfortunately, technology constrains this approach: an e-mail forum can’t deal effectively with whole manuscripts, and must focus on specific examples taken out of the larger context. However, online collaboration tools such as Google docs or its progeny, Google Drive, eliminate that drawback.

Second, I do collaborative editing with several editors from around the world: one of us serves as the primary editor, and does a heavy substantive review of the manuscript plus the usual copyediting, and a colleague reviews our work to catch anything we missed and fix any errors we introduced. The goal is quality control rather than learning to edit better, but when I’ve found time to thoroughly review a colleague’s work, I often learn important things about my editorial flaws.

Though the potential to learn from one’s mistakes is implicit in writers’ and editors’ groups, a more focused approach is needed if the goal is to improve our skills. We can do this in person or online; the key is the process, not the medium. In-person groups are flexible because they’re unconstrained by software limitations, and offer the pleasures of human interaction; I’ve yet to see a satisfactory online replacement for sharing a beer. In-person reviews also bring you face to face with your tormentors, who understand they’ll become your victim in a future session should they treat you harshly. That encourages a gentler approach, but the drawback is the greater risk of embarrassment or humiliation or angry reactions to ill-considered comments. Another drawback is the difficulty of gathering a group at the same time in a single location. Online alternatives offer more flexibility because meetings don’t require travel and reviews can be asynchronous, conducted whenever members have time to participate. This also encourages participants to express themselves more freely, since they can’t see their colleagues, but loses the human touch and risks harsher reviews until reviewers learn diplomacy. An obvious hybrid approach would be a real-time review by participants using Google docs, and a video conference call alternative such as Google+ hangouts or Skype.

All this being said, how can technical communicators use writers’ and editors’ groups to improve writing and editing skills?

A Simple Process of Peer Review

The process begins with writing and revising a manuscript (for writers) or editing someone else’s manuscript (for editors). The goal is to produce the best manuscript you can, while remembering that nobody’s perfect and that blind spots or flaws in our skill set will inevitably produce imperfect results. Once you’re satisfied you can’t improve the manuscript further, submit a clean “final” version to the group for review. Editors can submit manuscripts containing tracked changes so participants can see what you’ve done, how you did it, and the results.

Each participant then reviews the manuscript. Clear overall guidelines should be determined by consensus, such as whether reviews must always be gently supportive, no matter how poor the manuscript, or whether a merciless flogging is occasionally justifiable.

Additional guidelines for a specific review should also be defined by the author or editor: participants may be free to critique any aspect of the manuscript, or constrained to focus on a single class of errors such as imprecision or verbosity. Neophytes benefit from an unconstrained approach in which any error is fair game; this reveals a long list of things they’ll need to learn. Experienced writers and editors can narrow the focus to learning new solutions for new challenges in technical communication, such as single-sourcing or using a constrained English vocabulary.

After completing the peer reviews, discuss what you missed or got wrong. For distributed teams of technical communicators, who often work in different time zones, asynchronous reviews may be necessary: edits and comments are submitted using revision tracking, and the person being evaluated must independently integrate the comments, supported by e-mail or a phone call to request explanations or propose alternatives. Asynchronous works, but a synchronous review is more effective: it takes advantage of a group’s ability to negotiate consensus on an issue; uses disagreements as a tool for learning the difference between subjective and objective problems; reveals additional comments or solutions inspired by another member’s ideas; and teaches each reviewer something about their own blind spots. Best of all, it builds a sense of teamwork.

Once the discussion is complete and consensus (including an agreement to disagree) is reached, the writer or editor must implement the necessary changes and create a list of learning priorities. Prioritize the most serious problems, the problems that occur most frequently, or both, depending on your needs and the needs of your employer. Use these priorities to develop a plan for detecting and solving each problem. One effective approach is to make a separate pass through a document for each prioritized problem, such as subject–verb accord. By avoiding the distraction that comes from trying to grasp all a manuscript’s problems simultaneously, you gradually learn to spot that problem. Once that ability becomes subconscious, start learning to solve the next problem on your list.

You can teach yourself to check specific details in several ways, ranging from checklists that guide your revision to macros that highlight a list of problematic words so you can’t miss them. (I use the latter approach to help me cope with my blindness to excessive use of adjectives and adverbs in my fiction.) The best approach depends on your specific needs, the nature of the manuscript, and whether you can coerce your software to solve some aspect of the problem, as in the example of highlighting words. Problems that are difficult to describe in a way your software can emulate tend to require simpler or less technology-focused solutions, such as checklists that remind you what to watch out for.

Use the feedback from reviewers to learn at least two solutions for any problem, since few solutions work in all cases. Having alternatives increases the range of problems you can solve, and increases your speed at solving them; when one solution won’t work, move on to your alternative solution rather than wasting time trying to invent a solution. Over time, you’ll gradually learn which solutions work best in specific situations and will apply the best solution without hesitation.

Repeat the peer review process as needed. Occasionally ask for unconstrained reviews to avoid frustrating your colleagues by tying their hands and to identify new problems to work on. But when you face a specific problem, ask for a constrained review that will efficiently teach you to recognize and solve that specific problem.

The Learning for Technical Communicators

Making mistakes is an inevitable part of learning to write and edit, and it’s never easy having others rub your face in your incompetence. This is why every editor should write something that will be reviewed by a group: having your own flaws revealed teaches empathy for what your authors feel, and teaches you to edit gently and constructively rather than maliciously. I’ve also found, as have many others, that I learn better from making mistakes and correcting them than from simply reading about solutions.

To improve your skill, learn to ask why? whenever you get something wrong: Did you not understand the subject? Was your writing or revision process deficient? Were you simply careless? Each problem requires a different solution, but the solutions have something in common: each begins with understanding and continues with a desire to fix the problem. If you misunderstood the subject, improve your understanding. I mostly edit science manuscripts, and periodically need to pause and read about a subject until I understand it well enough to edit well. If your process was deficient, find a better process. I’ve learned I can’t edit well in a single pass, and must edit manuscripts at least twice: once to do all the heavy work, a second time the next day to catch anything I missed, and a third time if the manuscript is particularly difficult or if even small errors are unacceptable. Finally, use software to compensate for carelessness. Write macros to automate whatever you can, since this frees up mental energy and concentration to focus on tasks you can’t automate. Use timer software to remind you to take a break and breathe, or set your e-mail software to check e-mail no more frequently than every two hours to avoid the temptation of continuously checking email.

Where a sentence or phrase isn’t clearly wrong, yet has received criticism from others, don’t write this off as a matter of opinion. Finding out why the disagreement exists often reveals important insights into how readers process your writing, and helps you adapt your approach to meet their needs. Sometimes you’ll learn alternatives that may not be optimal for the current manuscript, but that might be useful under different circumstances. Resist the temptation to indulge in absolutes: peer review will teach you that writing is far more subjective in a visceral way you can’t appreciate until you’ve been through the process.

Essentials

Words are the most flexible tools we’ve invented. Unfortunately, that flexibility lets them bend in directions other than the one we intended. It also means there’s more than one way to communicate most thoughts, and that there’s rarely an objectively “right” choice and sometimes not even an objectively “better” choice. Context and audience often provide guidance. For example, if you’re communicating with audiences for whom English is a second language, you learn to avoid phrasal verbs when simpler verbs do the job equally well. Except in fiction, you learn to avoid idioms or obscure allusions. An under-appreciated benefit of peer review is that it can reveal your personal quirks (my preference for parenthetical phrases, for instance) or hobgoblins (styles you dislike but that aren’t actually wrong). If nothing else, you’ll learn to be tolerant of other ways of doing something: a particular style may please you, but if it doesn’t please your audience, you need to adapt to their way of reading.

Tact, diplomacy, and gentleness are essential. Writers who frequently undergo editorial or peer review gradually develop a thick skin, but enduring the slings and arrows of outrageous reviewers never becomes pleasant. Even when criticism must be pointed, it doesn’t need to be harsh; a corollary to Occam’s principle (“make it as painless as possible, but no more than that”) is worth keeping in mind. There’s always a way to make a review helpful (e.g., by offering a solution) rather than merely critical. After 25 years of editing, I’ve learned that a gentle, helpful approach builds powerful loyalty from my authors and an eagerness to discuss and achieve consensus, which is much more pleasant than engaging in power games over who’s right.

Reciprocity is also important. Everyone should have the experience of being reviewed to learn empathy for those whose work you will review. Everyone must review someone else’s work. That way, nobody ends up doing all the work and everyone’s voice is heard.

If you’re an employee, try to make peer reviews an ongoing part of your workflow. This transforms review into an activity that is rewarded and encouraged by your managers. Managers are easily convinced when they see that the time and cost of reviews is repaid by better manuscript quality. Although it’s tempting to focus on rewarding reviewers for finding and fixing errors, that’s only optimal when you’re evaluating the work of someone for whom this is the primary job (i.e., an editor). Even then, you’ll get better results if the goal is to help each group member improve their skills (teamwork) rather than seeking better ways to criticize each other (“beatings will continue until morale improves”). Few of us are sufficiently masochistic to enjoy reviews, but they become more palatable when enduring them earns us better performance appraisals.

Oh, the humanity!

I’ve frequently written that editing is a human endeavor, and remembering this is the key to forming a successful peer review group that will improve both manuscript quality and the skills of the writers and editors responsible for those manuscripts. Maintaining the human touch turns what would otherwise be a painful process into an activity that builds a sense of community.

Geoff Hart

During a sometimes checkered career, Geoff has worked for IBM, the Canadian Forest Service, and the Forest Engineering Research Institute of Canada. In 2004, he threw away all that job security stuff for the carefree—not!—life of the freelancer. Geoff works primarily as a scientific editor, but also does technical writing and French translation, and occasionally falls into the trap of leading or managing groups.

Read more articles from Geoff Hart