TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Explaining what we do From:Jack Shaw <jsh -at- SOFTWARE-AG -dot- DE> Date:Tue, 30 May 1995 18:17:08 +0200
Justifying what we do in a shop that is reluctant to accept "just"
a tech. writer/editor for that and no other purpose is tough unless
you can convince management of the added value, both within and without.
J. Sheldon's comment on making the doc./user info. part and parcel of the
product is one way. In my experience, unfortunately, this mind set comes
about only after having the doc. as an "add-on" and then seeing the light
in terms of being one-upped by a better competitor's product. But an integrated
"all part of the product" mindset is usually the byproduct of a more concrete
benefit to the organization provided by the professional communicator.
When the professional writer can add value in-house, the sales job is
usually much easier. Such value is added when the writer not only produces
the external info., but also manages the internal info. resources such as
functional specifications and design objectives. A professional writer can
make a big difference in the in-house efficiency and indirectly by influencing
the outcome of the devel./design activity by being involved in the dev. cycle
right from the beginning. Most design/dev. engineers love to see their labors'
fruits in written form--they just hate putting them there. Here is just one
of a number of in-house justifications for a professional writer.
But this might not mean a full-time in-house doc. type is justified. And the
scale of the company might make combining the writer and engineer in one and
the same person, an economic necessity. So a knee-jerk reflex against "those
engineers" who write the user info. might be difficult to justify.
As right as it seems to jump on the "get a tech. writer" bandwagon, it might be
thinking about the cases where a dedicated in-house writer isn't called for.
A contract, out-of-house professional might be quite appropriate, tactically and
financially. Most of us foresee a product requiring usage/maintenance info.
similar to the software products we all use daily. But there are other kinds
of products,"one of a kind" hybrids, that might not warrant a professional
involvement. A lot depends on the quantity and type of product(s) that is being
My argument would therefore be, stress what the prof. writer can do for you both
within and without, but be pragmatic when you assess the requirements and how
best to meet them.