The Changing Role of Technical Communicators

Some people consider technical writers to be an add-on to their application design and development process, and I think this is a mistake, although it makes our jobs easier. When we're add-ons, we show up after everything else is done, interview our subject matter experts, check facts, take screenshots, and then publish. But this also leads to a cursory treatment of the material, and user guides or help systems that although not factless are without a clue as to the best practices, or even common practices, that confront users.

This is a shame, since technical writers as those who have to explain how a software will work in the daily life of a user are those who can understand the whole of the product in two contexts: why it does what it does (technical), and what practical real-world purposes does it address (user). To write a quality UserGuide, helpsystem or even flashcard help, the technical writer must first acquire this type of familiarity with the product. And all of that is lost when the writer comes in late to the party to sweep up the shop floor with some timely but detached technical writing.

I understand the gunslinger mentality of technical writing, which prefers this approach, because it means the job's there for a few months and then the writer rides off lonely into the golden sunset, six-gun (presumably) thrown over a shoulder. I wonder about how well this serves users or employers, because it seems the most comprehensive view of the product walks out the door when the contract's over. I wonder about how well this serves technical writers, as it puts them in the role of perpetual wanderers who never have any actual stake in the product they're explaining.