Tech Writing a Growing Field?

[Nancy Allison]

I feel completely torn between Dan G and Chris B's comments. Both make good points.

I see a creeping desire on the part of companies to believe that if only they can create the cleanest, most precise CMS and single-sourcing solution . . . . the documentation will write itself? The engineers really *can* write the doc, because the structured doc interface will force them to write for users?  . . . something like that! And that supports Dan's point. Beancounters are hoping otherwise, but there is still no substitute for effective professional communicators, and in high tech that still means writers (not talking heads. And even they need someone to write what they say.)

Then again, we do need to lay claim to our technical context, or we will lose control over our final product. I'm really concerned that we will lose control over template design and even the scoping of output. It takes a partnership of the professional communicator's mind and the XML/XSLT/etc expertise to ensure that well-written source files are combined into coherent, useful documents. When companies start thinking that they can cut corners by having only one or two templates, and generating only one or two kinds of output docs . . . all that flexibility will be sacrified to the need to simplify output. And who will make the decisions as to what is output, if we can't speak the tecchie talk and counter the bad ideas . . . 

That goes to support Chris's point, which is that we need to expand our grasp so that we can continue to create good documentation.

That need is what creates titles like "Information Designer," and "Information Architect," and they can be useful if you know that your audience truly understands them. They sound ridiculously pompous in the wrong context. At this moment, "technical communicator" seems like a deceptively simple title that might fit the bill . . . 

--Nancy