summary of responses

[Dickie Selfe <rselfe -at- MTU -dot- EDU>]

This is a summary of the posts I received a couple of weeks ago.

On Wed, 23 Aug. 1995 I wrote to TECHWR-L asking for comment on an
observation that I had been making about the new expectations and
responsibilities of graduating technical writers.  They often seem to be
expected to research, support, devise policy for, install, and instruct
others in the use of new communication technologies.  I would like to make
the case to others in our department and to the discipline as a whole, that
we should be teaching these skills or at least introducing our students to
these skills through our curriculum.   I am inclined to include in this
curriculum discussions of a critical nature.  (i.e., how is our dependence
on these new technologies changing for better and worse our working culture
and our private lives?)

I received nothing but enthusiastic (though sometimes qualified) support
for the idea.  Let me first thank these folks for responding to my query:

"Christine A. Dobos" <CADOBOS -at- accusort -dot- com>
Dianne Driskell  <ddriskel -at- cs -dot- utexas -dot- edu>
THALEY -at- sctcorp -dot- com (Tiffany Haley)
"Grant Hogarth" <GRANT -at- onyxgfx -dot- com>
Rick Lippincott <rjl -at- bostech -dot- com>
sarah -at- teleport -dot- com (Sarah Perrault)
Mike -dot- Starr -at- software -dot- rockwell -dot- com (Starr, Mike)
Peggy Thomson <Peggy_Thompson -at- CCMAIL -dot- OSTI -dot- GOV>
Elna Tymes <Etymes -at- LTS -dot- COM
Michael Andrew Uhl  <uhl -at- vislab -dot- epa -dot- gov>
K Watkins  <kwatkins -at- quickpen -dot- com>
KJOlberg -at- aol -dot- com

I note with some interest that 6 out of 10 of the gender-identifiable
responses were from women.  Is this the gender make up of TECHWR-L?

I am also interested in arguments AGAINST the idea of a curriculum that
includes this expanded literacy education, an expanded technical literacy.
Please respond to me privately <rselfe -at- mtu -dot- edu>, and I will again post a
compilation for the list.

The following is a summary of the reactions I received to my first post.
If these activities seem to jibe with your own working conditions, I would
think this list might be useful for those thinking of making a case for
salary raises and improved positions.

NOTE: Each use of '&' indicates another respondent's confirmation of this
job activity.

**** Short Summary *****

*  purchase requests and install my own stuff. (%, %, %, %)

*  a end-user computer consultant & troubleshooting (in and out of company)
    (%, %, %, %, %, %, %, %, %, %)

*  Research and purchase (%,%,%, %, %, %, %)

*  I answer tech support calls for some of our products

*  Policy making (%, % , %)

*  system testing and interface design (%)

*  asked by new clients to recommend SOLUTIONS
    to their communication problems.


**** Summary with Anecdotes & General Comments *****

*  purchase requests and install my own stuff. (%, %, %, %)

*  a end-user computer consultant & troubleshooting (in and out of company)
    (%, %, %, %, %, %, %, %, %, %)
Anecdote:
I also help staff learn software, etc. with which
I am familiar with but all of our staff does that.

Other anecdotes:
-  I'm an unofficial internal consultant for
Windows-based page layout products
and graphics products (I spent an hour
yesterday helping three internal
users with Word for Windows)
-  I give lessons on the company pool table.
-  ... As well as being content provider, wet-nurse and nanny.....

*  Research and purchase (%,%,%, %, %, %, %)

Anecdote:
I was given the task a few months ago of
choosing one of the nationwide search engines
to align our technical report bibliography with.
That is, several search engines are being
developed which allow a user to search
bibliographies from many universities for
an author, key word, etc.  I argued that this
was really a job for the system's person but
to no avail. The reasoning was: I was the one
with the technical report bibliography so I
should choose the engine. UGH. I am learning
more than I ever wanted to know about
"system innerds."

Other anecdotes:
-  As part of the documentation process,
I'm a software tester
-  Evaluation of software and hardware tools
-  Browse appropriate Internet fora participating,
learning about tools, and scoping out competition

*  I answer tech support calls for some of our products

*  Policy making (%, % , %)
Anecdote:
I instituted a set of backup procedures, and
defined the sign-off process for technical
accuracy in the documents I produce; but are these
what you're talking about? (Partly, yes.)

*  system testing and interface design (%)

*  asked by new clients to recommend SOLUTIONS
    to their communication problems. (%)

*  General comments:

>I suspect that most one-person technical writing "departments"--and there
>are plenty of us--are in a similar situation.  When the whole sequence of
>making documentation happen is yours, a lot of what you do goes beyond the
>central researching, organization, and presentation of information.

Dickie's comment:
So perhaps for those in small units or freelancers, these are more
important skills.


>However, I'm not yet convinced (though open to the idea) that STC is the
>best forum for fostering the support and process-management skills which
>technical writers often need.  Experts on these subjects offer a plethora of
>books and seminars--not targeted specifically on writers, true, but that's
>exactly because these aren't specifically writers' issues.

Dickie's comment:
I suppose I think of this type of training as a literacy issue.  True there
are other places in the university where generic support and
process-management skills are taught but we (STC) programs already have
very appropriate sites for instruction based on the writer's/designer's
job: that site is in the computing facilities that support STC programs.
If we have the site for practicing these skills (assuming students are
allowed near the support, process-management, policy making events) and
have the expertise won't our students graduate with a competitive edge?

Dickie said,
>>If we have the site for practicing these skills (assuming students are
>>allowed near the support, process-management, policy making events) and
>>have the expertise won't our students graduate with a competitive edge?

Respondent says,
>Few of those hiring technical communicators are so aware of this part of the
>job as to take into account training or experience on the subject.  However,
>once people have the jobs, such training/experience could make a difference
>to their tenure and advancement.

Dickie says,
Your right of course.  But we often find that our students have to 'sell'
the very idea of technical communication to many employers.  If they're
going to sell their skills anyway, most employers are going to recognize
the value of these skills as well.


One respondent said,

 - basic software development methodology (the big picture, not
 nuts and bolts, to see where they fit in)

 - principles of interface design

 - principles of hypermedia (many of us are being dragged away
 from paper manuals, some gladly, others in a panic)

 - documentation project management, particularly the methods of
 JoAnn T Hackos, author of Managing Your Documentation Projects,
 1993, John Wiley and Sons--her methodology parallels the
 software process model developed by Carnegie Mellon's Software
 Engineering Institute and is inordinately useful for tech
 writers in the software industry AND for writers generally

 From what I have observed, the writer who can't follow these movements, who can
 "only" write or "only" edit, is going to be obsolete. But the future is wide
 open for communicators if we define our roles anew and get trained in some
 credible new skills. I'm glad your looking at all this.


A respondent wrote:
... my opinions are my own..no one else would want 'em.

NOT TRUE

Another respondent put things in a historical perspective:

I've been in this field for something around 30 years.  Early on, tech
writers had NO say in communications technologies.  Ten years ago there
began to be some evidence that tech writers sometimes knew what they were
talking about, and SOME engineering groups would listen to input from a
writer.  In the last three years, however, I've seen more and more
engineering organizations ask for input from tech writers as to purchase,
installation, access, and security issues.  The company I head is just
completing a contract with a very large engineering company where our
writers were consulted all the time about Internet interface issues,
including software purchase, installation, access, security, and
training.  Because of our expertise, we have signed several other
contracts with the same company, basically mixing technical expertise
with writing.



Dickie Selfe <rselfe -at- mtu -dot- edu>

                 (OO)  Director of
    CCCCCCC LLLL iiii  Center for Computer-Assisted Language Instruction
  CCCCCCCCC LLLL iiii  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CCCC  ccccc LLLL iiii  113 Walker Arts and Humanities Center
CCCC cc     LLLL iiii  Michigan Technological University
CCCC  ccccc LLLL iiii  Houghton, MI  49931   906-487-3225
  CCCCCCCCC LLLLLLLLL
    CCCCCCC LLLLLLLLL  "If it's not virtual, it's not real."
                                                      -- Daniel  F. Kamm