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: What employers think about technical writers From:Jim Grey <jwg -at- ACD4 -dot- ACD -dot- COM> Date:Wed, 23 Feb 1994 09:30:00 -0500
I said:
>So of course they'll be likely to undervalue jobs only tangential to the main
>product.
So, Bonni Graham shared her past employment frustration and resolution:
>I don't know how much time I spent at my last company trying to prove to
>them that good documentation is PART of the product, not a sideline.
><snip> One of the chief advantages of manual over tech support is that the
>manual is available 24 hours a day. <snip> I was also able to prove that
>regular-hours hotline calls (and the hostility thereof) decreased after I
>released a good version of the manual.
And, Doug Osborn mentioned my pipedream:
>I think this is an issue. I *don't* see my work as "tangential to the main
>product". From the users' (and it's nice when "user" = "customer") point of
>view, a tech writer's work is integral to the product.
My company claims that the manual is part of the product. Unfortunately,
we don't behave that way. The dollar is tied to the tape containing the
software, and even our company president will approve a tape to go out
without docs because it means we get paid.
The software here is king. Recent projects have begun a change in what we
sell. We now use the products we *used* to sell to develop what we *now*
sell. So we've been working very hard on development. I was pleased to
join the project I most recently worked on near the beginning (for once).
But I was soon dismayed that I was not going to write the manual. I was
instead given design notes and drawings, and told to put together the
requirements document from them. Why? Because the customer would not
pay us until they had approved our requirements and we had delivered the
tape. The design engineer, who normally writes requirements, was too busy
in meetings and development. I didn't get to begin writing the manual until
two weeks after we'd delivered the software. Incredibly, and this is the
case *every* *single* *time* we deliver, the customer didn't pitch a major
fit and reject the product because it came with no manuals. They grumbled
a bit and that was the end of it.
Again, I claim that if my company were in the word processor business against
Microsoft, we'd have top-flight docs, because the docs very heavily impact
sales. WinWord v. WordPerfect, both have similar features, you can do
the same thing with both packages, so having better docs is a real competitive
advangage. But in our bizarre niche (brace yourself, here comes some of our
marketing-ese), Supplying the World with Systems That Manage Systems (TM),
we don't have that kind of competition. Moreover, our competitors propose
"solutions" *from different angles*. When you want to write a letter, the
accepted solution is a word processor, and it's a matter of which. When
you want to provide an interface to a telephone company's toll switch,
managing circuits and testing trunks, the answer isn't so clear cut. It's
not a matter of which company's "X" feature is faster or works easier --
our competition probably has no equivalent to our "X" feature, thinking of
the problem very differently. The software's plan of attack figures very,
very heavily in the purchase decision, pushing variables like the docs to the
periphery.
Now, Bonni does have something in the angle of reducing support calls by
writing stronger docs. When I was hired, I was part of a complete turnover
of this department. We surveyed the existing, HORRID documentation, scrapped
it, and started over. We started getting comments from the Help Desk that,
"Wow, we can actually use the manuals now in service calls. We can refer
them to a page number and tell them to do it themselves." And, folks, we
were writing *reference manuals only*. No tutorials, no task-oriented
procedures. Just economical software-oriented references. But, by God,
everything was covered thoroughly, and it was fairly easy to find things.
This change in what we sell is just a very rough time for everyone. It
makes us very desperate for dollars, and our reaction, for better or worse,
is to do whatever it takes to get paid. For now, this means documentation
is unimportant when the design/development folk can use the technical writers
to offload their pesky writing tasks.
Sheesh. That open position in the Training department looks better all
the time.
jim grey |beebeebumbleandthestingersmottthehoopleraycharlessingers
jwg -at- acd4 -dot- acd -dot- com |lonniemackandtwangandeddiehere'smyringwe'regoingsteadyta
GO/M d p+ c++(-) l u+ e- m*@ s+/ n+ h f++ g- w+@ t+ r- y+(*)
Terre Haute, IN -- The Silicon Cornfield