The Ideal QA Manager… Technically writes, technically

I love the wiki on editing.  There are so may different types of editors, each having a different specific task leading to the final product.

It has to be a thankless endeavor, that of an editor.  Much like the QA Manager, the only real attention likely comes when things go wrong.  I know I am quick to judge a professionally published copy that is poorly edited.

I can’t say that I’ve ever seen a laboratory with a staff technical writer, whose sole job it is to write highly technical policies and procedures that define the Quality System.  That said, in my experience, the role of author/editor/publisher often falls on the QA Manager.

As the keeper of all things written among the Quality System, I struggle with this role of author/editor/publisher.  I want to do it all perfectly, all the time.  I have this inkling that my colleagues that review those documents expect the same.  Self-torture, I believe they call it.  A glutton for punishment?  Perhaps.  Honestly, I dabbled in journalism a bit in college, but a career as a writer has never been something I’d envisioned for myself.

I have found, however, that I have a particular interest in doing my part to improve the written communication in the laboratory.  It may not be terribly exciting material, but my hope is that I can make reading those mandatory SOPs less painful.  And those documents can be painful.  It seems that every document I pull for review needs serious work.

In this vein, I recently had an epiphany.  After spending the weekend with my blind parents, I thought that I would use the “text-to-speech” function of Windows to “proof-read” a certain document I’m currently working on.  I was extremely excited about this idea for about a week.  I even mentioned it to a few of my colleagues on Friday.  And then I saw this.  Grrr…  it just goes to show, there is no unique problem, only solutions.

This idea is revolutionary to me.  It may, very well, change my life.   If I can listen to a section of copy and make sense of it, then reading it shouldn’t be that tough, no matter how technical it is.   And if I can’t make sense of it, well then that’s where I can concentrate my efforts.

I’m adding this trick to my bag of tried and true methods for improving the readability of quality system documents, including modified grammar checks, monitoring the readability statistics by paragraph, and maintaining styles at all costs.  I’ll be sure to update on the results soon.

It’s not perfection, but it’s definitely a step toward progress.   With that, I have to ask… What tricks do you use to improve your technical writing/editing?

 

Leave a Reply

Your email address will not be published.