A few years ago, a manager asked me to provide an estimate for a short user guide project. I started by going to the project sponsor to get a feeling for the length of the guide and the intended audience. I then put together a detailed estimate, including all the important elements of a technical writing project: an outline of all the points to cover, the key team members to interview, an initial draft, followed by editorial review, and then more drafts and more review until the project was finished. I estimated six weeks for the work, which I sent to the manager in the morning.
Later in the day, the manager came to my desk. I knew there was something wrong with the estimate because ordinarily he would have simply sent back a reply via e-mail. He prefaced his comments with a perfunctory thank you, but then launched into his objection: the estimate was too long. Could I shorten it by several weeks? No, I replied, as six weeks was making the deadline tight already. I’d trimmed as much as I could from the estimate. How about eliminating the editorial review? he asked. That’s when I knew the manager knew nothing about writing projects. One simple question was enough to grasp this.
Why was he wrong? Isn’t editorial review an unnecessary luxury? Wasn’t I confident enough in my writing abilities to produce an accurate, grammatical piece of work without wasting weeks of effort on trivial matters? After all, that’s what a technical writer does, right? He translates technical jargon into legible prose. He’s the expert. Well, yes and no. It’s true the writer’s job is to produce audience-appropriate manuals and guides, but it’s also true that ensuring high quality includes reviewing drafts. Sometimes the reviews are technical. Sometimes the reviews are simply a sense check to ensure the text flows well and makes sense. Sometimes a thorough review will uncover structural problems, requiring an overhauling of the entire document or pieces of the document.
I think of editorial review as Quality Assurance for content. No software project would be considered complete until a full set of unit, integration, and user acceptance tests are performed. The same goes for all accompanying documentation, whatever the length and complexity.
You may be wondering how much review is appropriate. This is an it-depends question. Blog posts of 500 words clearly require the least amount of review, given their brevity. Book-length manuals require the most amount of time—often several months—but again, the effort involved must be commensurate with the complexity of the material. When I wrote an Applications Programming Interface (API) manual several years ago, the amount of review spanned several months. On the other hand, when writing operations guides of 20-30 pages, the reviews were finished in less than a week.
In the end, one must always think of editorial review as a required component of good writing. The level of engagement on it must match the effort to write the post, guide, manual, or book.