Sarah Barczyk
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 simple 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.
First and foremost: start small. If you work for a large company, pick a particular department or project and garner managerial support by putting together a concise proposal that outlines the advantages that an editorial review process can provide. 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 is a good chance the technical content will be perceived as erroneous as well. Once you have the backing of upper management, the establishment of a process will become much easier.
Be flexible, yet firm in setting up your process. Understand that the unknown is scary (and fond reminiscences of English class probably do not 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 mangers. I have found that the editorial review fits best at the end of the writing process, after any technical reviews. In this placement, 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 may be instances due to time constraints when this process may have 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. I can’t count the number of times I’ve been told, “It doesn’t have to read like a novel. It just has to make sense.”
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 as 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 may have earned a PhD in quantum physics, but that does not 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 explanation. An author may have deviated from the standard, but he or she may have a very good reason for having done so. And always remember that the document is the author’s property. There may be times when you disagree regarding a particular point, but know when to pick your battles. If the author is dead-set against a change that you’ve suggested (whether or not he or she is correct), keep a record of the conflict and move on. Resist the tendency to engage in a power struggle, which may result in costly delays.
Keep in mind that a face-to-face conversation is a great way to take the edge off of 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 may need to be assessed for each document. It’s also an appropriate place to document any specific disagreements that you may 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.
In these tough economic times, it may be difficult for a company to justify the added expense that an editorial review process may 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.