Ten Steps to Handle and Survive an Encounter with a Technical Editor
Author’s Note: This article is based on my reading and response to Cheri Lasota’s article about fiction and non-fiction editing and authoring. Working with a technical editor has some similarities and some differences to other kinds of writing.
Technical writers often cringe when they get edited content back from the editor, but it doesn’t have to be that bad. Here are the steps (yes, take them in order), to follow when receiving edits and revising content from your technical editor or your SME (subject matter expert).
1. Dedicate some time.
If you don’t have time to browse through the comments slowly, then hold off until you do. The reason? If you’re rushed, you won’t be able to take anything in or think critically about it. The comments might sound terse or mean, but everyone editing your content has a vested interest in making the end product as good as it can be. No comment is personal, so take your time and be objective—and understand that sometimes your editors are rushed for time too and might be very straightforward with their comments.
2. Don’t overwhelm yourself
Don’t skip ahead and look to see how many comments there are in the document. Many of those comments could be duplicates of one ongoing issue or one issue that crops up again and again. It could be solved by a quick search and replace. So don’t sweat it and take them one by one.
3. Procrastinate.
Yes, you read that right. Once you’ve read the comments from beginning to end, set it aside, create a reminder for later that week, and come back to it later. It’s hard to separate yourself from your writing and it is 100% natural to be defensive about your work, but giving yourself that extra buffer of time will really help you to be objective. With a little time, you’ll be able to go back, look at the edits again and be able to say (without anger!) that yes, that change should be made or no, it really is correct as is.
4. Let your back brain play with it.
The little errors are no big deal; you may have even fixed them as you went through your first pass of comments. However, bigger problems like flow of content or having a major shift in focus (like when you’re switching from feature-based documentation to goal-based documentation) will take some time for your back brain to work on and come up with some solutions. Let the possibilities come and go and when the right one hits you, you’ll know it. I often figure out the solution in the shower.
5. Make a copy.
Whether the edits were electronic or on paper, you’ll want to have an audit trail of which comments were received, when they were received, and what you did about them (you can add your own responses for those that you disagreed on). You’ll quite likely need to go back to a marked up copy—it might be next week but it could also be next year. Cover your behind and organize and name files clearly so you can search through them as required. Depending on what process/software you’re using, you’ll either want to back up the file before you modify it or keep the edited content in a separate file and update your master copy.
6. Start with the easy stuff.
You can usually you separate your edit into “easy” and “hard.” The easy stuff is straight copyediting issues: grammar, punctuation, etc. These are relatively quick fixes and getting started with these first will:
- Ease you into the revision process
- Eliminate a lot of the editing marks that are riddling your document
- Clear the path for more difficult edits
However, if there are major changes in content, flow, or focus needed, leave the easy stuff until last. Most of them might end up being deleted if you reorganize or rewrite big chunks of material. Work smart and don’t waste your time fixing content that might disappear.
7. Don’t just make changes. Learn from your Technical Editor!
Your editor became an editor because they know their stuff. Find out why they suggested the changes that aren’t clear to you (yes, go ASK YOUR EDITOR). What is the general rule/guideline? What is the goal? If you notice the editor has changed all your comma usage, take a look at the different sentence constructions, and find out what you are doing wrong. Memorize that grammar rule. Look it up in the Style Guide you are using. Learn the rule and vow never to make that error again.
Huge side benefit: You’ll get fewer and fewer edits with each grammar rule you master.
8. Remember, edits are suggestions.
Remember that you don’t have to incorporate all edits. Each and every edit should be viewed as a suggestion to you can take or leave. But keep in mind that if one person had an issue with some content, others might as well. Keep two things in mind at the same time:
- Each edit is optional/recommended.
- Ignore suggestions at your own risk.
The key is to use both your head and your gut when making these decisions. Don’t ignore them out of defensiveness but make sure the change is correct before you make it. If you feel a suggestion is just plain wrong, then put that comment on your list of things to ask your editor or ignore it completely.
WARNING: Ignoring a comment by mentally dubbing it “wrong” is very alluring. However, don’t be too lazy to follow up with the technical editor so you can hash out what they meant and whether or not it was correct. You might be pressed for time or you might be angry about the comment, but there’s nothing worse than having a flag raised after release and then realizing (as you go back through your audit trail) that the issue was raised but you chose to ignore it.
9. Take another vacation.
Once you’ve made all the edits you can bear to make without sacrificing your soul, then take another “vacation.” Take another day off, but don’t delay too long because you’ve still got work to do on this draft. Once you’re back at it, go through the content again, checking for two things:
- New errors you may have introduced inadvertently (from experience, I know that MS Word track changes introduces errors almost every time!).
- Content that wasn’t changed but ought to have been updated based on changes you made in other sections.
10. Be honest with yourself.
If you had minor changes, then it’s ready to go and you’re done (time for a cookie?). But if you re-wrote big parts or re-organized major sections, then it needs to go back for another review (ideally to the same reviewer, but another set of eyes is good too).
Best Practices on Technical Editing & Reviews
Big Note on Best Practices: If you sent out your content to more than one reviewer, then they need to mark up one copy of the document. There is nothing worse than going through four different sets of reviews, all with the same (or, worse, conflicting) suggestions. There are a variety of ways to do this and you’ll have to figure out the best way to work with your tools and IT setup. If you sent out your content to one person and you get multiple reviews back because they sent it on to others, then you send the first reviewed document back to them and ask them to mark that one up with their comments instead or explain how to share the document between multiple reviewers. Do NOT accept multiple reviews in different documents. It may take raising the issue with your manager, but the result should be to establish a process that saves everyone time (hey, they didn’t need to add those 30 comments that someone else already added? Yes, that’s right—we could have saved $700 of everyone’s time just by reviewing the same file).
What kind of experiences have you had with working with a technical editor. Have you uncovered any other best practices? How do they compare to these and the guidelines on from classic contributor Jean Hollis Weber? Please share them with the technical writing community by posting a comment below.
