By Sarah Barczyk
(originally published in 2009; updated with permission by Corrigo staff in 2018)
So you want to be a technical editor. You’re well-versed in grammar, style, punctuation, and the mechanics of the English language. You know what it takes to produce a clear, concise, readable paragraph and a coherent technical document.
Subject-matter experts within your company recognize that you’re an asset and routinely seek you out for writing help, and perhaps enlist your aid in editing large documents. But you know that so much more can be done. All you need is a process. It sounds so simple.
But it’s not. As someone who’s suffered the bumps and bruises that come along with setting up an editorial review process, I can attest to that. I can also offer a few tips for integrating the editorial review into the documentation process:
- Start small. If you work for a large company, pick a department or project and garner managerial support by putting together a concise proposal that outlines the advantages of an editorial review process. Mention benefits such as consistency across documentation for the end user and a more polished and professional look to customer deliverables. A clean document will require less rework down the road, resulting in an overall cost savings to the company, and will improve customer satisfaction. If a customer receives a document with a high rate of errors, there’s a good chance the technical content will be perceived as erroneous as well. When you have the backing of upper management, it’ll be much easier to establish a process.
- Be flexible, yet firm in setting up your process. Understand that the unknown is scary (and fond memories of English class probably don’t exist in the minds of your technical coworkers), but stress the importance of a standard course of practice. Research the place that an editorial review will fit in your documentation workflow, and gather feedback from authors, document coordinators, and managers. I’ve found that the editorial review fits best at the end of the writing process, after any technical reviews. Here, the author and editor can work together to resolve any last-minute language issues, and the document will have a professional and polished look and feel before manager approval. There might be instances due to time constraints when this process has to be relaxed. Be prepared to be flexible, but do everything you can to enforce a standard process.
- Expect resistance. Most nonwriters view documentation as a necessary evil. Be they doctors, architects, or engineers, the technical work comes first; documentation is simply a means to transmit knowledge. What’s important is the content.
You’re going to encounter people who view editors as formatters or spell-checkers. They don’t understand that an editor can provide consistency across company documentation. They don’t recognize that an editor can make each document more readable for the intended audience. They don’t appreciate that an editor can catch simple mistakes that have previously gone unnoticed because the author happened to be too close to the document content.
In short, you’re going to encounter people who just don’t care about the editorial review process. They’ll view it as an extra step, which means extra time and money that they’re not willing to spend. And they won’t hesitate to let you know it. Here’s where managerial support will be a great asset.
You’re also going to have to prove yourself. You must prove that you’re just as much an expert in your area as your technical coworkers are in theirs. You need to be able to back up every edit you make with information found in style guides, well-documented conventions, and company policies and procedures. An engineer might have earned a PhD in quantum physics, but that doesn’t mean that he or she has ever taken the time to learn the proper way to punctuate a gerund phrase.
- Each edit must be clearly communicated, and communicated with tact. Pose your comments as suggestions rather than directives, and be open to explaining them. An author might have deviated from the standard, but he or she might have a very good reason for having done so.
There might be times when you disagree regarding a particular point, but you must know when to pick your battles. Resist the tendency to engage in a power struggle, which might result in costly delays. If a writer consistently refuses to implement your changes or suggestions, it might be necessary to escalate the issue.
Keep in mind that a face-to-face conversation is a great way to take the edge off a critique. Schedule a time to discuss your edits and to ask questions of the author. Build a relationship and show your own willingness to learn about the technical content of a document.
- Consider creating an editorial review checklist. This is an efficient way to keep track of items (such as formatting and numbering conventions, capitalization standards, and rules for including acronyms) that might need to be assessed for each document. It’s also an appropriate place to document any specific disagreements that you have with the author’s rejection of a suggested change. A checklist can serve as a tool for gathering metrics and tracking common mistakes and issues that regularly arise during the editorial review process. Finally, a checklist provides a means by which to secure your job as a technical editor; it will serve as the proof of your value to the company.
It might be difficult for a company to justify the added expense that an editorial review process can bring, but in the end, error-free deliverables will save the company effort and money. All documentation can use a little polish; as an editor, it’s your job to make it shine.