You are here: Articles --> 2005 -->
Soften the blow...
Vous êtes ici : Essais --> 2005 --> Soften the blow...
by Geoff Hart
Previously published as: Hart, G. 2005. Softening the blow: taking the sting out of editorial and other reviews. Intercom September/October:25–27.
All editors and peer reviewers eventually confront an unpleasant aspect of our profession: no matter how necessary our corrections may be, the message they send to the author is that "you write poorly" or even "I write better than you do". If an author doubts their own skills or hates writing, this message can feel like a punch to an already sore stomach. Yet somehow most of us manage to strike up mutually respectful and sometimes even friendly relationships with authors. How? We develop ways to "soften the blow".
My editing philosophy has always been that our role is to help authors communicate their thoughts effectively and look good to their readers. To do this, we must find ways to work with our authors rather than against them, and easing the pain of a sometimes painful process is a great way to start. In this article, I'll describe some techniques you can use to turn the inherently adversarial act of correction into a more constructive, collaborative relationship. The same techniques can be used in any form of review, including peer review if you aren't working with or as an editor.
First impressions are important and can affect all subsequent interactions. If the first thing an author sees or hears from their editor is negative, you're both in for a rough ride. Indeed, long before you reach the end of the manuscript, you'll have begun to alienate the author. Instead of just diving into a review and filling the pages with red ink, start with a positive statement or one that is at least framed in a non-negative way. The goal is to precondition the author to relax a bit and pay attention to what you're saying rather than coming to focus on how critical you are. Provide reassurance right away; for example, as soon as you receive a manuscript for editing, confirm that you had no problems opening the files, and that you're looking forward to the work. Of course, if you actually dread working on the manuscript, don't lie. But do find another way to start off on a friendly note: acknowledge the author's request for a quick review by telling them when you expect to return the manuscript, thank them for sending the manuscript ahead of a deadline, and so on. At a minimum, be polite and solicitous.
Emphasize that the editing process will be a dialogue rather than unilateral dictation by starting your interaction with a dialogue: If the author hasn't stated a deadline, ask when they need to receive the edited manuscript—and when they want to receive it. (The two dates are generally quite different. Aim for the want date, and don't miss the need date.) Ask the author what they dislike about being edited, what their goals are for editing, and so on. When they respond, confirm that you've understood what they said and describe how you plan to accommodate their needs: confirm that you can meet their deadline (or propose alternatives), explain what you'll do to make the process less painful, and describe how you'll try to meet their goals. The result of this dialogue is that you've sent the author a clear message: "this will be a collaborative process, I understand and respect your needs, and my role will be to help you through the process".
Some of this initial dialogue gradually becomes unnecessary as you establish your credibility and develop an increasingly productive working relationship with an author. But even then, efforts to be polite and demonstrate concern for the author's needs are never wasted.
Devoting some time to helping the author solve problems before they begin writing can be greatly appreciated, and often saves you considerable time. For example, I once worked with several writers who had terrible problems organizing a document. Moreover, they had tremendous difficulty starting to write because they had no idea what they wanted to say, how to say it, and in what order. As a result, they wasted considerable time getting the job done, and I wasted a large amount of time reordering and rewording each of their manuscripts.
To solve this problem, I discussed the writing process with each of these authors and proposed that we work together to create a highly detailed outline before they even began writing. This cooperation took the form of a conversational interview in which I used the "five W's" (who, what, when, where, and why?), combined with my knowledge of the types of documents we were developing, to reveal the key points they wanted to communicate. As we talked, I typed the relevant information into a word processor.
In contrast to one popular approach to outlining, I insisted that the authors answer my questions specifically and in full sentences rather than summarizing in general terms: "I found that method A was 27.3% more productive than method B", rather than "I'll compare the productivities of the two methods". One interesting advantage of this approach was that the authors responded to my questions in their own voice rather than striving to meet some artificial notion of the formal style they thought they should be creating. The result was a higher proportion of simpler sentences and of active or imperative voice in place of their formerly complex, passive constructions—and thus, much less rewriting for me when it came time to edit the manuscripts.
Once we'd decided all the important things that needed to be said, we rearranged these statements into a logical order. Since each point that I'd typed represented what the author would actually say in the final manuscript, the outline became a simplified version of the actual final document, and thus became a highly effective tool for writing; in many cases, the manuscript was already more than half done before I left the author to complete the work. Moreover, because authors had focused on the truly important points, there was much less redundant or useless padding for me to eliminate during editing.
The investment of an hour or so of my time to help these authors develop an effective outline saved me at least that much time later in my editing, and undoubtedly also reduced time requirements for subsequent peer review. From my employer's perspective, this was also an effective investment of time because authors completed their writing tasks much faster and returned to more important duties sooner. Authors greatly appreciated this too, and subsequently were eager to seek my help in all their writing.
Editors have a sometimes-deserved reputation for making changes purely to demonstrate our authority or to prove that we actually read the manuscript. It's not always easy to overcome that reputation, at least until an author has worked with us long enough to see the kind of difference we can make in the quality of their writing. Once you establish that relationship, you can afford to justify your edits less often, knowing that the author has grown confident in your judgment and in the quality of your advice. But until you develop that level of trust, and particularly while it's early in the author–editor relationship, it's helpful to justify what you've done to reassure the author that your work isn't purely arbitrary.
If you've been asked to follow a specific style guide, you can make certain categories of changes without justifying each change. Simply explain that you've made certain changes (such as heading formats) to conform with the required style guide. But the first time you make a change, add a comment to explain why. For example, I often have to reduce the lengths of the abstracts for journal papers by 50% or more to follow the author guidelines. Rather than simply deleting well-written text and mystifying the author about why I did this, I insert a comment: "Because the journal guidelines require no more than 200 words in the abstract, I've edited your abstract heavily to reduce its length." The key is not to undermine the trust you're trying to build by making a change without informing the author; that change may be perfectly reasonable, but if it looks like you're working behind the author's back, you won't be building trust.
For more complex situations, explain the problem so the author can understand why you felt a change was required. If you misunderstood something the first two times you tried to figure it out, say so; then explain what you think caused this problem. For example: "As written, this wording can mean either [explanation A] or [explanation B], and from context, both are possible; as a result, I wasn't sure which meaning you wanted. Please use one of the two wordings I proposed to clarify the meaning." This kind of approach places part of the blame for the problem on you, the reader, then helps the author see how other readers could make the same mistake or encounter the same problem. That's a powerful way to convince someone to make a change; in particular, if the author saw nothing wrong with the wording in the first place, they're unlikely to simply accept a blunt recommendation that they change the wording.
Sometimes you can simply rely on convention. For example, I work primarily with research scientists around the world, and I generally have a fairly advanced understanding of what they're writing about. Based on that understanding, I can explain to them my feel for the prevailing consensus in a particular field, and can gently suggest when they're contradicting that consensus. Sometimes I can even suggest a way for them to explain why their opinions differ from that consensus.
If all you do is point out problems, you're not being as helpful as you could be and you'll be seen primarily as a critic rather than as an ally in solving the problems. To truly become the author's ally, you should offer solutions wherever possible. After explaining the problem, offer at least one suggestion for how to fix it; even if that solution isn't correct, it at least illustrates to the author that you misunderstood and that the text isn't as clear as they thought. If you're editing a manuscript using a word processor and can insert comments, type the actual solution that you propose so the author can simply copy and paste that solution if they agree, or can modify it slightly if necessary. The goal is to avoid forcing the author to invent a solution unassisted. After all, if they created the problem in the first place, they may not know how to fix it without your guidance.
Always offer to discuss a solution: "If neither of my suggestions is correct, e-mail me a more detailed explanation of what you're trying to say, and I'll propose some alternatives." This approach reinforces the feeling that your approach is collaborative and that you're willing to keep working to help the author solve a problem. Avoid giving the impression that you're unwilling to roll up your sleeves and get your hands dirty fixing things. Yes, it's really the author's responsibility to fix the problem, but that doesn't mean you shouldn't help.
Look for ways to make life easier for the author when it comes time to review your edits. If a recurring problem can be solved simply, identify the problem once rather than repeating it at each occurrence, then solve the problem for the author. For example, if you're confident that your change will be correct, perform a global search and replace operation so that the author won't have to do this work. If you're certain that you're doing the right thing, and can confirm this by means of a quick e-mail or phone call to the author, you can even make the change without using revision tracking; that spares the author from having to accept (or reject, if your supposition was wrong) dozens or even hundreds of word changes. It also clearly reinforces the fact that you're doing some of the work yourself rather than simply creating more work for the author.
If you're not confident that you're right and you can't ask the author, but are confident that your solution should at least be considered, explain the problem the first time it occurs, and propose your solution. Then use the search function to find all subsequent occurrences of the problem and insert a comment containing the possible solution (i.e., a replacement word or phrase). Some editorial colleagues prefer to use Word's "highlighter marker" tool to highlight each occurrence of a problem after the first, thereby making it easy for the author to find each instance of the problem. Unfortunately, the location of the highlighter tool isn't obvious (depending on your version of Word, it's usually hidden in the Reviewing toolbar), so you'll have to teach the author how to use this tool to remove the highlighting; to do so, open the View menu, select Toolbars, then select Reviewing to make the tool available. Select the highlighted text with the mouse cursor, then click the downward-pointing arrow to the right of the highlighter marker icon and change the highlight color to "None".
This example illustrates a helpful general principle: As an editor, you perform more onscreen reviews than your authors, and this means you'll be much more comfortable and faster using the editing tools than they will ever be. That being the case, why not offer to implement the corrections for them? When I've worked with authors who were uncomfortable working onscreen, I offered them an alternative: "Print the edited document, and read through the changes. If you disagree with something, highlight it and explain the problem. (We can discuss these changes in person if that works best for you.) If you agree with an edit, simply ignore it and move on. When you're done, return the printout to me and I'll make all the necessary changes for you."
This seems like a lot of extra work, but in fact it greatly reduced my workload. Rather than relying on the author to correctly implement all my edits, I could instead scan through the printouts looking only for changes, which I would immediately incorporate into the file. Where I disagreed with a change or where the author didn't understand why I proposed a change, I discussed my edits with the author and came up with a compromise solution we could both live with. Once that was done, I could simply accept all changes in a single step: open the Tools menu, select Track Changes, then select Accept or Reject Changes. Click "Accept all changes", click OK to accept all the changes without reviewing them, and you're done. This approach also works well when the authors must incorporate the changes themselves, since it saves enormous amounts of time compared with approving each edit individually.
Since authors are often less conscientious and careful than editors when it comes to ensuring that each change is correctly implemented, this process also gives you a chance to impose a measure of quality control. In most cases, taking responsibility for the changes reduces the amount of rework you'll have to do in subsequent edits.
Remember to use the magic word please often, and to phrase your comments as suggestions rather than demands. (Please is one of those magic words, like said in dialogue, that becomes invisible because of its familiarity but that is nonetheless perceived and understood.) For example, compare your reaction to the following two comments:
Harsh: "Don't use passive voice. Change it to active."
Better: "You should use active voice rather than passive voice in our reports. [give an example of one way to do this.] Please change this as I proposed, or use similar wording."
The goal is to constantly reinforce the notion that you are proposing rather than demanding changes. Once again, the approach focuses on dialog and collaboration rather than on unilateral dictation of changes. People are much more willing to consider helpful suggestions and requests than they are to heed outright demands.
The author–editor dialogue should continue once editing is complete. When I return a heavily edited manuscript to someone working with me for the first time, I always include a note in the e-mail message that accompanies the edited manuscript warning them not to be distressed about the quantity of red ink. (When I work directly with authors, I convey this message in person or over the phone.) For long-time clients, I may even joke that I get paid by the gallon of red ink. For new clients, I let them know that I've edited heavily to ensure that they get their money's worth. But I don't stop there: "Don't be alarmed at the quantity of editing I've done. I always edit this heavily, and since we'll be working together until this manuscript is published, I'm happy to discuss any comments or edits that you don't understand or don't agree with." This reminds my clients that even though they're paying me for the work, our relationship is important.
It never hurts to tell authors what they did right and what they should continue doing right—provided you can do this honestly, since insincere compliments are easy to spot and make authors distrust all your other comments. Consider providing an executive summary that emphasizes the positive (e.g., good coverage of all the necessary topics, effective organization), then remind the author that you've focused on the things that need to be changed rather than cluttering the manuscript with meaningless praise: "I know that this may seem to be a critical review, but as you'll see from my suggestions, most of the problems are minor and easy to solve. Moreover, as I noted in our initial conversation, I'll be happy to explain anything that wasn't clear and work with you to find alternatives if you don't like some of the options I've provided."
All of these suggestions require you to perform a fair bit of extra work, and it can seem hard to justify spending this much extra time when you have a busy schedule. But as I've indicated in this article, much of the extra work can end up saving you considerable time down the road. (If you're a freelancer, it can also guarantee repeat business.) Over time, you can gradually persuade authors to seek out your assistance because they know you'll make their lives easier. Isn't that better than teaching them to resist your efforts because you're just another obstacle on the road to being published?
Speaking as someone who's closing in fast on 300 published articles, I understand how it feels to be edited. [A look back from 2006: More than 300 now. Where do I find the time?—GH] Even if, like me, you understand the benefits of having a critical eye applied to your work and appreciate the opportunity to improve your writing skills, being edited remains uncomfortable. But where the editor has followed the suggestions in this article, and worked to reinforce the idea that editing is a collaborative endeavor, much of the discomfort goes away and it becomes easier to accept the edits. Work towards this goal in your own editing or peer reviews.
©2004–2017 Geoffrey Hart. All rights reserved