steel cage job title championship match

Two disclaimers:

1. I acknowledge that these titles are arbitrary.
2. The distinction I describe is my own and my thoughts probably represent the minority.

Less so in recent years because I've had steady, happy employment, but I often agonize over the definitions of technical writer vis-à-vis applying to job postings. Documentation Specialist is probably the second most common job title (which I held in two government positions) which every TW-type job applicant searches. So when one is bored, fretting, and unemployed, trying to sort out the difference between the two is happily time-consuming. I'll add that the HR people who submit job postings probably don't give the difference a second though. But you know, we're writers - so we obsess over definitions.

I don't know if this was the purpose of the blog entry or not, but Collin Turner's discussion of a subject matter expert (SME) has helped me make a sharp distinction between technical writer and documentation specialist.

SME is a term that's thrown around loosely (at least in my experience), but Turner starts with a salient point in that an SME "provides needed content." The SME is the source of the content. The documentation specialist then chaperones the content through the documentation process until a product is published.

In my limited world view, I'll suggest the following difference: While neither the technical writer nor documentation specialist creates the product (computer application, piece of hardware, or process) that must be documented, the technical writer creates and is ultimate responsibility for the content supporting the product. He or she performs the requisite research inside and outside of an organization to identify, collect, and organize this content.

Collin Turner's description acknowledges these internal conflicts, but lays the organizational knowledge arbitration at the SME's feet.

When I am wearing my technical writer hat (which I like to wear most of the time), I am navigating my organization and available resources to identify and collect all the required content. This means obtaining different functional organizations' ideas of a product, resolving their differences, and presenting a unified view.** Secondarily, I need to have confidence that I can identify with the target audience in order to create effective documentation from the raw data which I've gleaned. This is a real world description, not some idealistic cut and paste from engineering and marketing documents, fix the grammar and save as perfect documentation dream.

I generally feel that a good technical writer must become competent enough in the subject he or she is writing about to answer most questions about it. In the SME-documentation specialist system, the DS has a place to ask questions, but isn't ultimately responsible for the content.

The biggest problem that I see is when an SME doesn't have a vested interest in the user and doesn't take the time to understand the user's documentation and learning needs. When the SME is an engineer or scientist, he or she is too busy creating the widget. But this system succeeds when the SME is in marketing and understands that his or her success or failure depends on the customer's success or failure.

**Any good TW knows that his or her understanding of cross-departmental viewpoints somehow is really valuable to the organization. If anyone in upper management realized this too, I think that TW's organizational roles could be elevated.