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: Re[2]: Techie First or Writer? -Reply From:David Locke <locke -at- SUGAR-LAND -dot- ANADRILL -dot- SLB -dot- COM> Date:Fri, 11 Oct 1996 10:00:45 +0000
Michael Sechelski said
> <snip> The difference is that
> engineers/programmers/etc are "producers"
> whereas tech comm is an "add-on service"
> that doesn't really produce anything, takes
> up office space and burns electricity to
> produce those d___ manuals that nobody uses
> anyway. I think that's the perception in
> the eyes of a lot of upper management.
That is the perception and it will take a while longer to change that
perception. STC is no help even after trying to figure out what a technical
writer adds to a product or company, because the best they came up with, as
far as I've been told, is that we are a cost or profit center. I disagree
with both, but only in the context of software vendors. Pharmaceutical
companies doing compliance, or other companies doing ISO will still classify
us as cost or profit centers.
Good user support -- documentation, training, and technical support -- are
critical to long-term customer loyalty. This should be based on the notion
that we reduce use costs and improve end-user performance. Neither of which
is measurable in any practical sense, but I know of one company where the
customers refuse to buy the product after paying for and attending training,
because the product is too complex. The users know that their use costs will
be high and performance will be high even if they can't quantify it. If we
could shift their focus to target costing of use costs, we would get more
respect. But, it will be hard enough to get them to focus on customer
benefit rather than technology.
However, there is reason to remain optimistic. A small but growing number of
software engineers are advocating the use of user manuals as the acceptance
test. They see this practice as an industry best practice and as such the
practice should become an accepted practice soon. These developers believe
that doing this reduces development costs, because prototyping is done in
the document rather than in code, the document is tested for usability, and
the customer approves the documentation before the software is built. Just
like what an architect does when they create a client's building: they plan
it, they get the plan approved, and only then do they build it.
Remain confident that the day will come when the perception changes. We've
just got to keep chipping away at them.
