Re: perception problem

[Maria Townsley <maria -at- MSD -dot- MEASUREX -dot- COM>]

Warning: Soapbox speech in the beginning of this message.  Practical
suggestions futher down.


I think we're underestimating programmers/engineers.  A lot of them really
do know how to read ... and write.  Some of them write pretty well.  A lot
of them *do* understand the need for good documentation and can accurately
judge how good your documentation is.

I'm a female tech writer.  My degree is in English and Secondary Education.
The only programming language I know well is the language my company
developed.  Obviously, I learned that after I started here, not in school.
They hired me because my expertise is in writing.  If they had wanted another
programmer, they would have hired one.

In the past, I have experienced some of the bias that the group of female
tech writers was talking about.  I think it is caused by a variety of factors,
most of which have already been mentioned.
1)  gender
2)  age
3)  "hard" vs "soft" degrees

The first two factors are rapidly disappearing in today's society.  Where I
 work now, most of the guys are in my same age group (@30).  They all have
 working wives, working sisters, and working female friends.  Some even have
 working mothers.  They went to college with women.  Sometimes the women made
 better grades.  They work with women, compete with women, and respect women.
 Guys like this won't expect me to be stupid just because I am female.

However, there is another generation still in the work force. Their mothers
were home when they got home from school and their wives maintain the home.
If their wives hold jobs, they are not considered "bread-winners".  Even
these men can be educated. In my first position as a marketing assistant,  my
new boss took me on a tour of the facilities.  The last room he showed me
was the kitchen.  He informed me that he liked his coffee with 2 sugars and
1 cream, then proceeded to show me.  I watched attentively, then pulled out
another cup and started making my own coffee with the comment,
"And here's how I like mine."  His jaw dropped open.  Needless to say, our
working relationship was established at that moment. Obviously, such
aggressive techniques won't always work.  I never did learn to respect his
abilities, but once I established that I wasn't a secretary, he did learn
to respect mine.

The third factor will never go away.  Society will always think that math
and science are "harder" than communication skills.  After all, anybody
can talk and write a grocery list, but not everybody can use a slideruler.

In the beginning of this note, I said that we are underestimating programmers
and engineers.  Someone commented earlier that programmers didn't know that
their documents looked terrible before they got a tech writer.  Guess again.
My programmers knew exactly what kind of impression they were giving with
their documentation, and they know what kind of reaction they get now.  I'm
one of the best marketing tools this company has.

I could tell from the beginning of this conversation with Kate that the
problem was not that they were female tech writers, but that they were
inexperienced tech writers or tech writers that had not gone about proving
their worth in the right way.  There is no slam intended in this. You started
behind the 8 ball when your supervisor took off for parts unknown after
hiring tech writers without a lot of experience.  Without anyone to tell you
what your job was, there was no way to learn it.

Some companies don't know what tech writers are really suppose to do, but
they will recognize it when the job is done and done well.  This would have
happened by now for you if you had already worked at other companies in
different environments, because you learn what you need to produce in order
to impress.

Some engineers do know what a good tech pubs department can do, even if
their company doesn't have one, because of prior experience.
I know of a company that has 10 tech writers, a tech illustrator, a production
editor, a desktop publisher and a writing manager.  One of the programmers
told me "We don't have a tech pubs department.  We have a word processing
department."  After listening to his reasons, I decided he was right.  The
writers expected the programmers to write the documentation in FrameMaker,
then they spent all their time "prettying it up."  The information was
spoon-fed to the writers and required no thinking on the part of the writers.
I don't think the writers were necessarily bad.  They might have really
excelled if they were given the opportunity in another company.  They whole
setup was bad though.  The programmers had no respect for the writers.  In
this case, they were right.

Here's some practical suggestions:

1.  The 3 of you get together and decide what you can do for the company.  Would
real documentation make your product more marketable?  Would it cut down
on service calls?  Would it have internal benefits?

2.  Decide what kind of input you want from the programmers.  Do you want them
to write it for you?  Do you want them to tell you a product is done and let
you figure out how to use it?  Do you want to be involved while the project
is being developed?  When is the documentation suppose to be done?  Should
it ship with the product or 6 months later?  This determines when you should
get involved in the project.

3.  Do you have the right tools to do your job?  Are you using a DTP or did
they stick you with WordPerfect?  If you need better tools, decide now.

4.  Do some investigative work.  Decide the type of documents that need to
accompany your product.  Do you need a complete set (User's Guide, Database
Guide, System Manager's Guide, etc.)?  Do you need quick help cards?  Do you
need internal or external documentation?  Once you decide what you need,
create outlines so you have something tangible to support your ideas.

5.  Once you have collected all this information, approach your boss.  If your
immediate supervisor is still sailing the seas, talk to your boss's boss.
Present all of your information.  "We have analyzed the situation.  We feel
that our skills are not being used fully.  We can do ... for the company by
producing this kind of documentation.  We need this kind of input from the
programmers.  This would increase marketability, reduce customer service, save
time and money letting the programmers program and letting us write.  You're
paying us for the job.  We want to do it."  Get your boss to buy off on it.

6.  Start working like professionals.  Ask intelligent questions.  Start
sending out drafts.  Make sure your drafts are accurate and professional
-looking.  Don't send out something that looks bad and contains typos just
because you think of it as a working draft.  Let them know what your final
goal is and let them in on creating it.

Once you have created your first document using methods like this, you will
have earned the respect of your programmers.  They will respect a good
document that makes their product look and sell better.

Good luck.  Let me know how things go or if you need any moral support along
the way.

-maria