Re: perception problem

[David Hamilton <david -at- URSUS -dot- COM>]

Maria wrote:

> 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.  [...]

> 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.

The degree matters only until the work experience starts, from what
I've been seeing in the workplace.  I only hear degrees discussed
among recent graduates.

Engineering, especially in the computer industry, is a unique endevor.
Gender doesn't matter, nor does appearance, dress, or even language
skills.  The only thing that matters is what the engineer produces.
It is creativity on demand.  If the design works well, is done on
time, and doesn't require a lot of rework, the engineer is successful.
If it doesn't work, no other factors are evaluated.

To successfully interact with engineers, one must understand their
perspective.  Typically, they will see themselves as the only persons
within the organization for whom these rules apply.  They will view
view most other job functions within the organization as judged more
on subjective grounds than the brutally objective performance
evaluations to which they are subjected.  This, and not the type of
degree, is the real dichotomy.

It is very easy to see if an engineer's work was successful - either
the design works or it doesn't.  The time frame for evaluating success
or failure is quite short.  Contrast that with the evaluation of a
marketing program (for example).  It can take a year or more to see if
a program is successful, and often the personnel involved are promoted
or transferred long before the results are in, based on "other"
criteria.   Tech writing may be viewed in the same light.  How does
one evaluate the success or failure of a documentation set and what is
the time frame involved?  If the product is a failure, is it a problem
with the engineer's design and implementation, or is it a failure of
the documentation, marketing, and customer support?  To the engineer,
it is a classic situation of "doers" vs "suits".  If the product is
successful, the "suits" are promoted and rewarded.  If it is a
failure, the engineer is blamed (since the product wasn't good
enough).

In the classical scenario, from the engineer's perspective, the job of
the tech writers is to explain their creation to the masses.  The
skillful users won't require much in the way of documentation, and the
inexperienced users will require far more than is ever provided.  The
engineer has created their "masterpiece" for the skillful user, almost
without exception, since only the skillful user (read other engineers)
can appreciate the subtleties and intricacies of the design.

Thankfully, this classical scenario is dying fast.  Organizations are
realizing that there is a much more important role for tech writers -
that of user advocate.  In a healthy operation, the tech writer is one
of the first "non-technical" (or less technical) persons to work with
the product and has a major impact on the implementation of the
engineer's design.  Feedback from the tech writers can provide
valuable input to engineering, QA, support, and marketing, and help
shape the designs into a viable product.  In one sense, the tech
writer functions a bridge between the developers and the "suits", and
can help the developers focus on the user needs while the product is
still malleable.  This is an important role that does not fit into the
traditional departmentalization scheme.

As a matter of routine, I always get a current copy of the source code
or schematics from the engineers, a copy of the design spects from
project management, and a copy of the marketing plan.  The engineers
may have never seen the marketing plan.  Marketing may not have seen
the actual design spec.  Much of my job function, as a technical
writer, is to translate this information to the terms understood by
the person with whom I must communicate, and to translate all of it
into terms and organization understood by the targetted customers.  In
the meetings, I must translate and correllate one to the others,
allways into the language or terms understood by that department, but
always representing the user's perspective.  What a fun job!

-dh
_____________________________________________________________________
David Hamilton                                        david -at- ursus -dot- com