Tech Biz Writing

Unless an author is a specialist on the equipment being described, first draft material is more than likely to contain a number of technical errors. This is not so surprising when you consider that the writer will spend perhaps two or three weeks absorbing the information that design staff have been studying for years. Despite this, engineers can still become very testy if a writer goes slightly astray on a technical aspect of their product.

In any well planned project, experienced personnel will establish lines of communication to handle the validation of draft documentation. A quick turn-round will be normal practice, and no valuable author-time will be lost.

Unlike editing, technical vetting is not something a writer will ever be called on to undertake in ordinary circumstances. It’s the period in every job when the manuscript is removed, only to be returned covered in comments in a strange hand, and with whole paragraphs summarily deleted.

Occasionally, when information that had been received from an engineer is removed or changed, the author may suspect that it was wrong in the first place. This is one of the hazards. Project info changes from day to day, and designers would not be human if they didn’t seize on the opportunity provided by the vetting session to tidy up some of their thoughts and mistakes.

It sometimes happens too that engineers working on a project fail to grasp certain aspects of their design until they see it in cold print described by a technical author. It’s not unknown for them to scamper back to the “beast” for a swift rejig, leaving the author’s draft untended for days in the quiet room. After a decent interval the unfortunate writer telephones the operative in question to ask after its fate. He will be informed stiffly that “certain design changes are underway, which are likely to take some time”, and would he mind rewriting whole sections of the manual.

This is the nature of technical writing. If you see yourself as part of the project team and build in sufficient slack, it should really be taken as a compliment, not the essence of frustration.

Next: 30. Editing.

This entry was posted on Friday, June 16th, 2006 at 3:56 pm and is filed under Technical Writing, Publishing, TechBiz Writing, Documentation, Design, Research, Technical Vetting. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.