My Own Notes on Note Taking

[Moshe Koenig <alsacien -at- NETVISION -dot- NET -dot- IL>]

I've read over a number of comments on the topic of a technical
writer being asked to take notes. The argument in favor of this
practice is ususally that if there is a discussion of a highly
technical nature, the technical writer is more in tune with the
subject material and, therefore, will do a better job. The
argument against is that a technical writer is not a stenographer
and is not equipped to take down the minutes of a meeting.

During a six-month stint with an ill-fated site of Intel Corporation,
I was repeatedly asked to take notes in meetings. Ultimately I
concluded that the reason that I was asked to do so was 1) the
secretary quite rightly found the lack of direction in the
meetings bewildering, 2) there had to be some justification for
retaining a technical writer when no products, let alone
documentation, were being released to the public, and 3) I was
the only person at the site conversant enough with the various
tools to turn out any semblance of notes on what were brainstorming
sessions.

How did I do? As one senior engineer remarked, reading my notes were
a bit like watching a silent movie; sometimes it was enough, but at
times the reader felt that something was lacking. Something was
clearly lacking, because Intel eventually aborted the project and
closed the site with only two days notice. The one tool I had not
mastered was the crystal ball. Apparently when senior staff looked
at my notes -- which came complete with drawings, sketches, flowcharts
and everything but the kitchen sink (for all I remember, that was
there, too) -- they realized the truth: the meetings were a
festival for great ideas that went nowhere.

It could be coincidence, but I had a similar experience in another
job. I took a recorded session that I had attended with a senior
engineer in which he was outlining plans for a product in development
and converted it into a document. When the engineer saw the document,
he reacted rather badly, saying it was "totally incomprehensible."
This time, however, I had the backing of my entire department; all
the technical writers had attended the session and said that to them,
the document accurately reflected the discussion. The engineer said
rather defensively, "It couldn't be. The document makes absolutely no
sense." I then presented him with the tape recording and advised him
to listen. What did it do? It definitely wasn't pleasant for me, but
from that day on, the sessions we had with this engineer were far more
structured, far more purposeful, with far less vagueness.

You might think that the engineer would never have forgiven me for
having made him look like a fool. The truth is that he appreciated
it greatly. He was a very eloquent speaker as a rule, but he was so
close to the development that he took it for granted that what he
said made sense to us, particularly since we had all worked with
earlier versions of the product. The mirror image that I showed him
in that document was a schooling for him, and the department reaped
the benefits later. What were once brain-dump sessions became
informative, structured meetings.

What bothers me about being asked to take notes is that I have often
been asked to sit in long, rambling sessions, as in the Intel
example, in which engineers argued amongst themselves about the
pros and cons of Sybase, Oracle, Informix -- topics of which my own
understanding was not so deep and which were of no interest whatsoever
to an end-user of the product in development. I found very little
justification for having ANYONE take notes on a debate as to whether
to use a tool such as PowerBuilder for the front end of the product;
first a decision had to be made, tests run, and THEN I could have
been called in for a report, but not for the debate of for or against.
I find it rather revealing when an organization misuses its human
resources in this manner; it usually means that the job is ill
appreciated and could easily get the axe. It's one of the reasons
that if I find myself being called to take notes too often, I start
looking for work elsewhere; it means that the tail is wagging the dog,
except that there's no dog.

I also know of one company that makes it a regular practice of
sending technical writers to cover planning sessions for projects
in development. While the nature of the meetings might justify the
practice, I have a close friend whom I know to be a superb technical
writer who took a bad fall in a series of sessions. He was asked to
cover meetings that lasted all morning, meetings that lasted all
afternoon, and come up with typewritten finished copy of all the
sessions THE NEXT MORNING! Even if it could be argued that only a
technical writer could cover these sessions -- and it could in this
case -- the load he was asked to carry would have justified installing
a video recorder instead, because he could not hope to keep up. He
went a few nights without sleeping, which only made him tire out the
next day in sessions that continued six days a week for two weeks.
The story did not end nicely as far as the company went, but my
friend is today self-employed and successful; was it right to make
him out to be incompetent when the only thing that he failed at was
being superhuman?

My ultimate conclusion is that the profession of technical writer is
still poorly understood. Consequently, technical writers often find
themselves being given tasks that seem very unrelated to their job
descriptions because even the managers aren't sure what they're doing.
I don't know how to resolve the problem, because every time I walk
into a job or into an assignment, my task is almost always redefined.
Even if STC were to issue an edict that no technical writer should
take notes, that wouldn't affect the everyday lives of the writers,
each of whom faces a different reality at work. My gut instinct is
to refuse categorically, but sometimes I don't feel that I can take
that liberty. How many people can?

- Moshe

                  TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send administrative commands
         ALL other questions or problems concerning the list
       should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-