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:Not given work we *are* qualified for From:Stuart Burnfield <slb -at- FS -dot- COM -dot- AU> Date:Thu, 23 Apr 1998 17:25:27 +0800
I agree that we need to educate people about technical writing, so we
can concentrate on the work we're qualified for. It's not that we can't
type memos and take minutes, it's just that other people get paid to do
that, and we get paid to do different, necessary work other people
I wonder though, has anyone else experienced the reverse?
A couple of times, interesting, unusual tasks have come up that I was
perfectly suited to. Not because of anything special about me, but
because they required fundamental tech writing skills.
The first happened when I did my very first Information Plan, a la
JoAnn Hackos and 'Managing Your Documentation Project'. I was pretty
pleased with it and sent out review copies to all the project stake-
holders, their friends and relatives, passers-by, Craig Shergold, and
Everyone loved it. At that stage the company had very good technology
but a very haphazard process. No-one had ever seen a single document,
written near the start of a project, that described briefly, in plain
English, the project, the product, the market, the user population and
their main tasks, schedules, dependencies, risk factors, and so on.
Then the confusion started. The boss loved it, and said:
BOSS: We should do this for every product. Let's update the development
procedures to say that someone should write something like this
at the start of every project. . .
ME: No worries, I've been wanting to do this for months.
BOSS: . . . but who should do it? The lead developer? Project manager?
ME: I'll do it. I have to write it anyway, for my documentation
BOSS: No, I mean something *like* this, but for the project, not the
ME: But I have to research and write all this stuff anyway. That's
what I do.
BOSS: Yes, something just like this, but not about the manuals.
ME: But the documentation plan is all in the last few topics. That
can be between me and (my supervisor). The first three pages are
all about the project -- they don't even mention the docs. That's
the part everyone likes.
BOSS: But you're the technical writer. This should be done by. . .
ME: Tell me what should be changed to make it OK as a development
document? Do I need to add some headings? Take some out? Change
BOSS: (riffle riffle) No, it's perfect. But. . .
And so on. I had done all the tech writerly things -- talked to all
the people who had a piece of the puzzle, wrote it up in a brief, clear
document, and sent it to the people who needed to see it.
My boss could see that "something like it" would help every project.
But he couldn't see it as a task for a writer. If it was a technical
writer's document, it couldn't be a software development document. If
it was a software development document, surely it shouldn't be written
by a technical writer?
The second example was a nice idea we had to handle custom software.
We tended to do a lot of custom work to win big deals, so keeping the
documentation, the software and the customer's procedures manual in
sync was a problem. We hit on the idea of putting the procedure manual
online and making it the interface to the software -- find the
procedure, read the instructions, follow the link to perform the task.
When we were discussing how this would work, I said each team should
have one or two techies to do the coding and testing, a TW to write up
the procedures/instructions, and they would all do the analysis
together. The others couldn't see the point of putting a writer on-site
with the techies. The most they could picture was that you could write
standard blocks of text to go with the more common procedures.
In this case I think they discounted the analysis and workflow aspects
of the job, and saw it as largely a software job. I suspect what would
have happened is that they'd package up some scripts and custom menus,
then throw it back at the customer and say, "Here, now all you have to
do is write the procedures."
I should stress this company is great to work for. They're good, smart,
fun people. They like me and respect my work. But for a long time there
was definitely a box labeled "TW".
Senior Ignorance Worker
Prolix Communications Pty Ltd mailto:slb -at- fs -dot- com -dot- au