Re: Explaining what we do

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.


Jack Shaw
jsh -at- software-ag -dot- de

Previous by Author: Re: Quick SGML Query
Next by Author: Re[2]: "Technical Writer" en Espanol
Previous by Thread: Re: Explaining what we do
Next by Thread: Re: Explaining what we do

What this post helpful? Share it with friends and colleagues:

Sponsored Ads