Friday, July 17, 2009

Cop vs Consultant

As a member of the STC certification task force and a former member of the Body of Knowledge committee, I have been interested for a while in understanding the core value proposition for engaging professional technical communicators. The essential question is "How is a technical communicator better than an engineer who writes well?"

I've read a lot of reports, essays, blogs, and e-mails on this topic. One of the bullet points that got to me was that professional technical communicators understand the legal requirements of documentation. It's not that it didn't make sense, it's just that I have never measured up well in that category. Now that I see it as a differentiator, I'm starting to take it more seriously.

Oh did I mention I work for IBM? I wonder if they care about things like copyrights and trademarks.

The kinda good news is that IBM provides me with a ton of information on my internal employee Intranet about trademarks. The really good news is that they provide a tool that searches my documentation and tags everything that could be trademarked. The tags are read by our output rendering tools and they apply the (tm) and (r) symbols appropriately, as in first use in a topic, not in a title, etc. I just have to do a manual scrub and look for places where their use is not a trademark, as in IBM being used in reference to the company not a product. Trust me, that's a small enough trade off.

It also gives me a tool that looks at all my documentation for word usage and notifies me when I use a term that is not approved or might be used in the wrong way. Most of the suggestions are based on how elegantly certain terms are handled by translators versus other terms with the same meaning.

I mention that as a bit of self-disclosure. I'm preaching that everyone should care about this when probably most already do and many do not have the nifty tool-box my employer has provided me.

But, it's probably worth a mention. Pay attention to the legal requirements and translatability issues, not only in your own documents, but in the documents of other groups like marketing and engineering. It's an area where we add value.

The tough part is doing it without sounding school-marmish (still working on that).

Maybe I'll modify the old "feel, felt, found" approach sales people use to handle objections, as in "I know how you feel; I felt the same way, but then I found..." I'll try "use, used, uncovered".

"I see you use the word following as in '...includes the following:' I used it the same way until I uncovered the fact that most translators will interpret it to mean something like 'group of admirers' when it is used as a noun. I now only use it as an adjective as in '...includes the following features.'"

I know I am trying to move away from my "you're wrong and I must warn the others" syndrome, but sometimes there is value in warning folks when something is wrong.

2 comments:

Anonymous said...

Technical communicators also write with a process that includes and requires technical review and editorial review.

I have found that people that consider themselves to be product experts often ignore those types of things.

Anonymous said...

Technical communicators write with a process that includes technical review and editorial review.

Other roles are less likely to get their contnet reviewed.