Re: predicting successful writers

Subject: Re: predicting successful writers
From: Maury <alsacien -at- IBM -dot- NET>
Date: Sat, 25 Oct 1997 20:04:50 +0200

Dear colleagues,

I've followed this thread with interest. At one point or another, I could
have been the person whose level was not as presented in an interview.
Sometimes, the reason was because I was talking about one thing, and the
interviewer talking about something else, but we were both using the same
words for different things. Sometimes the interviewer was not telling me
the whole story, either because he/she didn't know or didn't think it
important to reveal all the cards to a candidate. There have been
successes, but if I were asked what was the magic formula, I couldn't say.

My experience spans from very pedantically doctrinaire companies to very
disorganized ones. I've seen that the pedantic companies do not necessarily
limit the writer more, nor do the ones who work on a
by-the-seat-of-the-pants method give the writer greater freedom. Every rule
has an exception.

To relate specifically to the query:

>A. Extensive background knowledge of the technical subject, e.g., jet
>engine mechanics

If the candidate understands the subject AND CAN EXPLAIN IT TO OTHERS IN
COMPREHENSIBLE LANGUAGE, this might do it. I capitalize the latter part
because that's where many technical experts fall flat.

>B. Extensive educational background, e.g., B.S. and above in technical
>writing or related subject e.g., engineering

Sometimes that makes a difference. However, a technical writer writes from
the viewpoint of the person reading the documentation for a product, not
from the viewpoint of the person who is engineering the product. Engineers
can be so involved in the behind-the-scenes processes that they are unaware
that what is second nature to them is confusing and/or irrelevant to the
customer who ultimately purchases the product. The technical writer is
often the first customer to use the product insofar as explaining its use
to other customers go.

>C. Extensive experience as a technical writer on said technical subject

I'd say in most cases, this one works, provided that there is evidence that
the candidate actually did the work. Unfortunately, I fell victim once to a
new employee who was hired with supposedly a lot of experience and had even
passed a battery of tests, but on the job, this person finished not even
one simple document without my having to intervene. Only later did I
discover that the department manager, who had me ghost writing all of this
person's work, passed the work off as something this person had done alone.
The result was that this other person had a respectable output of work,
whereas my output was considerably less because I had to divide my
attention between my own projects and ghost writing. If my manager had been
decent, he/she would have found a way to give me more credit; however, that
did not happen. I came out looking like the goldbrick, while this other
person became a valued employee. It was at this point that I tendered my
resignation and left without leaving so much as a trace in my wake.

>D. Number of years as a technical writer in any subject

Sometimes yes, sometimes no. There's too much not to know in high-tech
these days. Some writers can adapt rapidly because of previous informal
knowledge, but not all can -- or want to. I've worked with writers with
extensive software experience who, when faced with writing hardware
manuals, decided that they were software writers, and I've seen the reverse
as well. One situation I have encountered as well is when I see a person
documenting a software product in which the terminology used in the
software is not the standard but rather terminology used in a specific
discipline, such as electronics; an experienced software documentation
specialist could fall flat quite unknowingly because of this requirement
(which, I might add, was NOT made known in one incident that I remember).

>E. Samples of previous work on said technical subject and/or writing
>tests.

Sometimes reliable. However, testing is not infallible, and writing samples
are hard to link to the candidate. When a candidate presents writing
samples, several problems arise:

* Was the project under a confidentiality agreement? If so, does the
candidate have the permission to submit the document?

* Did the candidate work independently on the document, or is the document
a groupware effort that the candidate worked on at one time or other?

* Did the company requesting the documentation make many esoteric requests
that make the sample appear unconventional? An experienced writer who is
asked to deviate can look foolish in such a sample, whereas a less
experienced writer may not be aware of how much the sample deviates from
the norm. I mention this point because startup companies often want to have
something gimmicky to make their product easy to remember when it hits the
market; the writer is not in a position to refuse when the company makes
the request.

>F. Other

There's one factor that seems to be relevant: luck. A competent writer has
a better chance, but I've seen competent writers go down because of being
assigned a very heavy project too early in their careers. I've seen not so
competent writers make it because even though they couldn't write, they
could understand the technical aspects of projects well and could explain
them, even if someone else had to rewrite all their work. I've seen some
writers who were not so strong in either area who still made it. Luck does
play a significant part; a writer who flops in one corporate environment
might thrive in another.

One issue that this query did not address is what a technical writer is
often required to do: when faced with a product to document, can the writer
make an assessment of what would be the most practical way of documenting
the product from a usability standpoint and deliver? I mention this because
this, I believe, to be the acid test. I do not know how this can come out
in interviews or tests, which is why I strongly favor the setup in which a
writer begins on a short-term contract and then stays on if all goes well.

I wish to be forgiven for giving a personal experience to illustrate. I was
presented with a product to document that was supposed to be an upgrading
of a previously documented product. Consequently, most of the material was
to be repeated; however, the functionality of the product in the new
version was completely different and had to be rewritten completely.

As I sat with the product and tried to understand the explanatory material
I had on it, I discovered that I was becoming lost in a sea of menus and
working modes, and it wasn't always clear to me how to go from one to the
other without considerable manipulation. My first thought was that a new
user would become exasperated very quickly unless he/she knew when he/she
pressed a function key what would indicate that he/she was on the right
track. It was clear to me that the only way I could create a document that
the user would find helpful was to replicate all the display screens on a
step-by-step basis. That way, a user would press a key and then be able to
check the manual to see that he/she had achieved the desired result.

The problem with this approach was that it was a ton of work to do with a
graphic tool. When I proposed the format and submitted some sample pages
for approval, the first question I was asked was: "Can you meet the
deadline?" I felt I could. I was able to complete the project successfully.

I mention this example because if I had not been experienced with graphic
tools, even though I might have been able to come up with the desired
formula, I could never have delivered the material on time. If I had been
proficient in graphic tools but was not able to reach the conclusion that
this approach was correct from a usability standpoint, I would never have
been able to start the work in a productive manner. This was an on-the-spot
situation where I had to assess, decide, and execute with very little time
for faltering.

There were other factors as well, to be sure. The idea of a pictorial
manual was especially appropriate because many of the users of the product
might be barely literate or might not read English as a native language.
Because the target audience was not supposed to be necessarily the sort
that would read large masses of text to understand how to use the product,
the pictorial presentation approach was what was needed.

One thing I will say in the aftermath of this project: it was only because
of my extensive experience in all the tools that I was able to meet the
deadline. The manual was prepared in Microsoft Word, perhaps the least
appropriate tool for a manual of such complexity, but there was no time to
convert it to another DTP tool that might carry the load better. In all
honesty, I am sure that many experienced Word users would have found this
job daunting, and, at times, so did I, because I had to format almost the
entire procedures section in tables of varying dimensions so that the text
and the graphic images would appear properly aligned. Mastery of many tools
is very important in some jobs, but in others, the tools have already been
chosen, the formats have been set, and there's no room for adventuresome
types. In such organizations, tools mastery is not a key to success, but in
many, it is essential.

Which brings me to the conclusion that the best way for the writer and the
employer to know that there is a match is to plan on a trial period first.
If the writer comes on with a contract and later becomes an employee, it
helps the writer decide if he/she wants to stay as much as it helps the
employer decide if the writer is suitable. Even this system is far from
infallible, as I know only too well; good starts can turn bad, and bad
starts can turn good. However, on-the-job testing is still, in my opinion,
the way that both sides get the most accurate picture.

I know that many of you will not like this idea; when a person goes to a
new job, usually he/she wants to think that he/she is going to stay put for
a while. I've found that to be largely an illusion, however. No company
guarantees any employee work until retirement any more. A writer may be a
whiz kid at so many aspects of a job and yet not be able to work with
others on the staff; that doesn't always come out in interviews or tests.
Nor do I support the practice of hiring graphologists as a means of
screening writers -- and the practice DOES exist! The best test, in my
opinion, is in the actual act of doing the job.

I know that what I've written here may be very controversial. I only base
what I say upon my own experiences, without any pretense of being an expert
on the subject. As I have stated above, every rule has exceptions, and I do
not believe that there is one road to success.

- Maury King

Posts: mailto:techwr-l -at- listserv -dot- okstate -dot- edu
Commands: mailto:listserv -at- listserv -dot- okstate -dot- edu (e.g. SIGNOFF TECHWR-L)
Archives: http://listserv.okstate.edu/archives/techwr-l.html,
http://www.documentation.com/, or http://www.dejanews.com/
Subjects: JOB:, QUESTION:, SUMMARY:, ANNOUNCE:, or none of these.



Previous by Author: Job Posting - Dallas
Next by Author: Re: Entry-level tech writers...a new twist
Previous by Thread: Re: predicting successful writers
Next by Thread: Re: predicting successful writers


What this post helpful? Share it with friends and colleagues:


Sponsored Ads