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: Is this just the way things are? From:"krupp, marguerite" <krupp_marguerite -at- emc -dot- com> To:TECHWR-L <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 29 Nov 1999 09:13:17 -0500
I can't let this thread go by without saying that my experience has been,
for the most part, quite the opposite. Maybe it's because I've been lucky,
or maybe it's because I have trouble keeping my mouth shut. Here's a recent
example:
Instead of the following scenario:
<snip>
1. Technical feasibility of a tool for Help creation is determined after a
decision to use that tool has been made.
2. Technical implementation is delegated to a person who has not been able
to
produce acceptable results in more than six months.
3. The approved design of the Help system is constantly changing, depending
on whom one speaks with. <snip>
The company I work for recently formed a task force of volunteers from the
writing groups to examine the features and suitability of HATs, and they are
abiding by our recommendations.
The person doing the technical implementation of the Help (that is, putting
the hooks into the software) is the one in charge of integrating the
software builds, too.
We have a team working on the design of the Help AND of the other
documentation formats, too. There is one very competent person in charge,
and she makes sure that we're all up to date on the latest developments. She
works through our editorial group to ensure consistency, too. Everyone gives
a little when necessary to find an acceptable workaround, and when that's
not possible, the team makes sure that we understand the necessity for
following the prescribed format.
Do we have problems? Sure, the same ones that everyone else has. But there's
an attitude here (and at many other places where I've worked) that we all
need to work together to solve problems. Management does a lot to foster
that attitude.
I'm impressed with this group, but it's not the exception among the big
software companies I've worked at (for over three decades). In fact, the
exceptions seem to have been the smaller places that didn't really have
their acts together. When I did find the types of problems the writers have
described at larger places (sometimes as the result of a megamerger, again
where the group didn't have its act together and fell back upon absolutes),
I left. The job market's too good and our talents are too valuable to put up
with garbage and lack of professional respect.
We definitely don't get all the support we'd like from the engineers and
programmers. Specs? Reviews? Gotta go digging. As for programmers with "egos
the size of Pittsburgh," well, I used to be a programmer, too, so I'm
prejudiced. My best strategy is to treat them like people, not
"programmers." But then, I liked Pittsburgh, too!