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: Tech Writers as Trainers From:Elna Tymes <etymes -at- LTS -dot- COM> Date:Sat, 23 Aug 1997 12:21:57 -0700
> As the manager of our training department, I am now on the other side
> of the equation. It is my responsibility to get a million other
> projects done while trying to maximize our exposure to the systems so
> that, when they are implemented, we know as much about the system as
> possible. It is virtually impossible to meet all of our goals because of this.
It sounds like your department has a severe case of "It's all your
problem." That comes from management not understanding that there are
different kinds of support, and that training is - or should be -
responsible for only one kind.
See if you can do a collaborative presentation with the dept. heads
from Tech. Pubs, Customer Service [or Support, depending on what it's
called in your company], and Training. Most upper management doesn't
really know the difference between the kinds of things each of these
groups is best able to handle.
For instance, Tech Pubs is usually responsible for doing the most
complete gathering of information possible before a product is released,
and accurately gathering this information into the appropriate set of
manuals, online Help files, and any other (usually) written material
that is packaged with the product. The purpose of this material is to
allow users to make a reasonable search for answers as to how the
product works before turning to other forms of help. Training, on the
other hand, is usually tasked with creating structured learning
experiences so that people will feel more confident about using the
product for normal tasks, and turning to reference material or other
forms of help only when they need to go beyond the normal tasks.
Training also is used when product managers feel that the product is so
intimidating that people won't use it at all without some of the warm,
fuzzy "small experiences of success" that personal attention is so good
at delivering. Customer service is tasked with helping customers, on an
individual, ad hoc basis, with a particular problem related to
exceptional things, such as a bug in the software, something related to
a particular application of an otherwise-obscure feature, etc.
That said, such a collaborative presentation to upper management usually
provokes some discussion about which group should be doing what set of
tasks. Sometimes this discussion produces some resolution.
So what are the resources each of these groups have? Tech Pubs usually
has early access to the developers, and the first-line experience with
how a product works - or worked before some developer changed the code
without telling people. Training usually has a wonderful set of
anecdotes about how people make mistakes, or what they try before
figuring out how something works, or what constitutes a reasonable set
of steps and what's too much for one gulp. Customer service usually
amasses - formally or informally - a database of problems and
Note that each of these sets of resources is extremely useful in feeding
back information to the developers and marketers, and to each other. If
Customer Service gets a lot of calls about some feature that can't be
changed, Tech Pubs can be warned to rewrite that particular section of
the manual and Training can be warned to cover that feature in some
detail. Likewise, if Tech Pubs runs into problems describing a feature
adequately, Training can be warned to devote some attention to it and
Customer Service can be armed with some backup data to help deal with
related customer calls.
A lot of development organizations don't realize that when they release
a product - or think they've released a product - they also have to
allow time for Tech Pubs/Training/Customer Service to learn the product,
AND that this learning time is extremely valuable because of what these
people learn about learning to use the product. Lots of experience has
taught me to be very, very careful when agreeing to work for developers
who insist that their products are "inherently intuitive" and therefore
require little or no explanation. There are a few such programs around,
but very, very few.