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: Radical Idea? From:Barb Philbrick <caslonsvcs -at- IBM -dot- NET> Date:Tue, 13 May 1997 15:23:07 GMT
>Hire multi-talented tech writers and share the three functions between us. <snip> at
>this early stage, I get only a few support calls a week, and training
>comes in bursts.
It could work if you make sure you block out times for people.
Something like person 1 handles support calls this morning, person 2
this afternoon, person 3 at lunch and breaks. Otherwise, you're asking
people to spend their days being interrupted. It takes 15 minutes to
get into a train of thought, so even two or three calls in a day can
disrupt up to an hour and a half of work. (See _Peopleware_ for a
detailed discussion of this.)
The other thing to start is call tracking. I've found that people tend
to remember the screamers. If you actually track calls, you might find
that you had fifteen polite calls about a problem with installation,
yet all you remember is the one screamer whose product didn't work
because he didn't put in the batteries. Your solution as a technical
writer might be to emphasize installation of the batteries, but ignore
the installation problem. Call tracking can be a real eye-opener in
indicating where the real problems are. My cheesy theory on why this
wrong emphasis happens is because you have a lot of emotional input
with the screamer - he (or she) probably called you and your company
nasty names. The polite folks didn't raise your hackles, so are less
likely to be remembered.
Training can be a good perspective, but again, watch your perceptions.
What people need when first learning a program is different than what
they need later on. As a technical writer, you're preparing the
materials that they will need later on when there's no trainer to hold
their hands. This includes more detail and depth than what can be
provided in training. It can be hard for a writer to sort out what's
appropriate to training and what's appropriate for the manuals (at
least it's difficult for me).