Not given work we *are* qualified for

[Stuart Burnfield <slb -at- FS -dot- COM -dot- AU>]

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
can't do.

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
so on.

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
      planning.

BOSS: No, I mean something *like* this, but for the project, not the
      manuals.

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. . .
      (frowns)

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
      something?

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".

Regards
---
Stuart Burnfield
Senior Ignorance Worker
Prolix Communications Pty Ltd
mailto:slb -at- fs -dot- com -dot- au