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: issues in communication From:Kris Olberg <kjolberg -at- IX -dot- NETCOM -dot- COM> Date:Fri, 31 Oct 1997 16:16:42 -0600
From: Jeffrey R. Wiggin <wiggin -at- RPI -dot- EDU>
>Greetings fellow tech writers!
>I'm a graduate student in tech. comm. conducting research on the
>communication problems tech writers often face when dealing with product
>developers, project managers, and so on. I'm currently trying to get
>information about how these problems typically manifest themselves, how
>we might prevent them from arising, and how we might alleviate them once
>they do arise. Of particular interest to me is hearing about solutions
>people have come up with when faced with such problems.
After almost twenty years, I can come up with a boatload! In the interest of
time, I'll limit it to four. Keep in mind that I am generalizing somewhat
in my observations. These scenarios do not occur everywhere.
(1) This one just appeared on the list. A writer was asking for advice on
justifying better machinery. My experiences have shown that machinery is
often dispensed throughout the office based on rank and seniority and is not
based on how well it fits the software used on the machine. I've seen many
managers checking e-mail on top-of-line equipment while underlings run
compilers and graphics programs on much less. My bottom line here consists
of two cliques: choose the tool to fit the job .... time is money.
(2) Management and engineers/developers alike frequently omit the resource
required for supporting documentation when they create their development
schedules. They use metrics and sanity checks to determine development
schedules and probably add a little padding for bathroom breaks, sick time,
etc. But documentation takes time; writers need the information these
engineers or developers have in their heads. It takes time to transfer that
knowledge, much more time than management realizes or wants to acknowledge.
(3) Writers sometime aren't brought into the process early enough. Some
managers view a writer's time in a design meeting to be a waste. "They don't
contribute ... why do they have to be present?" Well, they still have to
learn. They need to understand what problem is being solved by the
product--aka "business requirements." They need to understand the product's
history. My bottom line is this: eliminating a team from a part of the
process causes them to expend some or all of their production time on
getting over the learning curve. All too frequently I hear writers say "I
was just starting to get comfortable with the product" just as the product
... and the docs ... go out the door.
(4) Management/developer expectations don't match what a writer is doing.
This could manifested in a number of ways: the writer takes source material,
edits it, and the developer is offended by the changes; the writer was
really hired as a typist; the writer is expected to plow through C++ source
code, requiring skills not requested when hired. This is, IMHO, caused by
the lack of standard definition of what a technical writer does, which is
our fault as technical writers.
Regards...Kris
------------------------------
kolberg -at- actamed -dot- com
kris -at- olberg -dot- com
