Re: Reorganization Question

["Wing, Michael J" <mjwing -at- INGR -dot- COM>]

I prefer to be a Writer on an Engineering team rather than one of "n"
writers in a documentation department.  However, from the responses to
this topic that I've seen, this puts me in the minority.

I'm a firm believer that there needs to be a variety of skills on a
team.  In this job market, a Writer really needs to broaden their
skills.  Technical documentation is becoming increasingly integrated
with design.  Interactive tutorials, context-sensitivity, reusable
topics/chapters, video, audio, information mapping, and so forth go way
beyond preparing a printed document and throwing it in with the product.
A team of mixed disciplines, IMO, is a good environment for integrating
the Writer with the product.  True, the Writer is often first perceived
as performing an "overhead" function.  There usually is a "break in"
time before the Writer proves their worth.  This may be because "we" are
joining "them" rather than "they" are joining "us".  However, the key
word is joining.  A separate Writing department may reinforce the "us"
versus "them" mentality.  Regardless of first perceptions, "break in"
periods, and so forth, it is easier to change perceptions from the
inside than it is from the outside.

Being on the inside of a development team does not reduce the number of
interface changes, functionality work-arounds, specification deviations,
and other events that "make our tasks so easy".  However, it does help a
Writer understand why these events are necessary.  Personally, I found
that project managers were much more inclined to ask me how changes
would affect the document if I was an insider rather than an outsider.

Also, by documenting while part of the Engineering team, I learned how
to adjust my approaches to getting information from Developers.  Instead
of approaching them with the blank page journalist/interviewer approach,
or the "I'll make a template and have them fill it out" approach, I
research the information, test the product (if possible), and approach
them with specific and direct questions.  I find that this focuses their
thoughts much better than "Tell me everything you know about ...".  I
feel that they provide much more information if they are correcting what
I have wrong (especially if they think the document is going out that
way) than if I say "let's start from the beginning".  Being a part of
the Engineering team puts me in a better position to derive these
questions (much easier if development is happening around you instead of
"down the hall").

I also try to keep the contact time to 15 minutes or less per
interaction.  This keeps focus on the next block of information in which
I have to process.  I can get into detail on a few items without turning
it into a prolonged affair.  Therefore, the next time I contact them I
am less likely to be met with "I'm too busy", "It's going to change,
talk to me later", or the tacit responses indicating that their main
objective is to send me away.

Mike Wing

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/
_/   Michael Wing
_/   Principal Technical Writer
_/   Infrastructure Technical Information Development
_/   Intergraph Corporation
_/   Huntsville, Alabama
_/   (205) 730-7250
_/   mjwing -at- ingr -dot- com
>_/


                  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-