Supervising a novice?

Subject: Supervising a novice?
From: Geoff Hart <Geoff-h -at- MTL -dot- FERIC -dot- CA>
Date: Wed, 26 May 1999 08:40:20 -0400

Michele Marques has <<...never supervised a technical
writer, and am looking for advice (other than "don't do it") for
supervising an extreme novice.>>

Without knowing the newcomer, it's pretty hard to come up
with specific advice other than "be flexible and adapt your
approach to the specific person's needs". Probably the best
initial approach would be to start by working very closely
with the person to get a feel for her skills, then gradually relax
your supervision as she gets up to speed; even if this takes a
while, you'll want to relax a bit anyway so you don't smother
her. Start by developing a large-scale outlines for the overall
project, then smaller-scale outlines for each individual phase
of the project; in effect, you're coming to an agreement on the
overall deliverables. Do this well before you actually turn the
writer loose to begin writing, since planning is crucial,
particularly with novices. Resist the temptation to do all the
work for her; lead her to finding her own answers rather than
simply providing the answers. (This is both more effective as
a teaching strategy and more likely to get her up to speed fast
enough to take the pressure off you.)

As you work together, you'll begin to get a feel for how
organized the person is and how they think. If you're
confident that they're working up to (or even beyond--that
happens!) your standards, you can progressively relax your
supervision as she begins the actual writing. If not, then you
know you'll have to work with her much more intensively
throughout the project; some people are lousy at "the big
picture", but do a good job on the actual writing; some are the
opposite. Make sure you intensively review the person's first
_small_ writing project; not only does this give you an idea of
what problems to expect, if any, but it also lets you teach
your house style as you go (e.g., "that works, but here's how
you can do it beter based on our specific audience analysis
and usability testing"). This is based on incremental
improvement: any mistake you correct at the beginning won't
have to be corrected repeatedly for all subsequent phases.
You'll gradually get a feel for how good this person is: the
better the writer, the sooner you can move away from
"looking over your shoulder" supervision to peer review and
collaboration.

That's obviously the ideal situation; you may actually end up
with a writer who simply can't be taught to write, and then
you'll have to come up with other coping strategies. Drop us a
line with details if that's the case. (Hope we don't hear from
you! <g>)

<<I am throwing her at the mercy of the programmer to learn
about the product itself.>>

Not usually the best idea, unless you've got an unusually
patient and cooperative SME. You should spend some time
investigating the writer's interpersonal skills, and provide tips
on how to work with the specific programmer involved in this
project (e.g., "don't send Jean notes, he never reads them;
arrange an appointment no earlier than 9 so he has time to
absorb his coffee"). And warn "Jean" that he'll be working
with a newbie and should expect the need for additional
patience at first. You may have to arbitrate between them
initially--but don't get caught in the trap of patronizing either
of them; they're both adults and should be able to work things
out alone once you've made the initial introduction. Make
sure your new writer understands that it's better to come to
you immediately with a tough problem rather than struggling
futilely and making the situation really bad; that probably
won't happen, but it's remarkably reassuring to know you've
got someone who won't spit on you for reporting a problem.

<<I have ForeHelp Premiere and will be assigning her to
work through the tutorial (to learn about the basics of
building help files or even what goes into help files).>>

I don't know what their tutorial is like, but tutorials typically
explain how to use the tool, not why you'd want to use it or
what to do once you know how to use it. Find out whether
your writer has had any training in online help; if not, turn her
loose on a good practical book such as Deaton and Zuback's
"Designing Windows 95 help"; other listmembers can
propose more recent references, since I believe this one is
now out of print. Any of William Horton's books are helpful
reading, though more general/theoretical than practical.


--Geoff Hart @8^{)} Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca

"If pro is opposite of con, then what is the opposite of progress?"--Anon. (possibly Richard Lederer
)

From ??? -at- ??? Sun Jan 00 00:00:00 0000=




Previous by Author: Microsoft rules on navigate vs. explore?
Next by Author: Quick-start guides?
Previous by Thread: If you are a member of the STC. . .
Next by Thread: The Microsoft Dominion


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


Sponsored Ads