TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:RE: On degrees and the like... From:"Michael Collier" <mcollier -at- arlut -dot- utexas -dot- edu> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Tue, 28 Mar 2000 11:47:54 -0600
Eric Ray <ejray -at- raycomm -dot- com> wrote:
Do I have a proposal or answer? No. But I think that there's
more to being a really good technical writer than can come
from any program, any certificate, and any specific set of
requirements, and I think that we'd be doing ourselves and the
profession a service if we were to focus our energies on how
to help people enter the profession and on how to prepare
people to succeed in the profession, rather than beating the
dead horses of STC, certification, degrees, and the like.
There must be an answer beyond serendipity and relying on
the good fortune to stumble into the right internship or
mentoring relationship, but I don't know what that answer is.
Any other thoughts?
Part of the problem is that how we do our work is often defined by others -
managers or customers who tell us they need output in a certain format, or
available in multiple formats, for example, or they tell us to write
according to a spec, or they tell us nothing at all. All of these situations
are things we have to deal with. This is where calling tech writing a
profession gets fuzzy - we are not always as self-directed in our approach
to solving the customer's problem as a doctor or lawyer is. This is less
true for some sub-specialities of tech writing such as help development or
projects involving mark up languages - specialities which can be gained
through a combination of courses and on the job training.
In my view a superior technical communication program on the graduate level
would have to be modeled after the case study approach used by master's in
business administration (MBA) programs. Real world technical communication
problems would be introduced, with students working in teams to design and
implement a solution. Example:
"Case 39. A multinational engineering firm is planning its enterprise-wide
project management application and needs training materials, user
documentation, and reference documentation for a variety of users. Project
Managers need to be able to use the application to view and comment on task
status reported by enginneering leads. Engineers and software developers
will use the system to create and update task plans for their projects and
report problems to project managers using a web or e-mail interface. Sales
and marketing teams need access to product development data so they can
produce specs for potential customers to review. Admin assistants need to
use the system to prepare reports for project managers that can be viewed
through a web interface.
"Create a docuemntation plan for training materials, user guides, and
reference guides for this project based on
- your surveys of how the different classes of users mentioned above
currently do their jobs;
- requirements specifications provided for each class of user;
- surveys on documenta formats preferrred by user groups (online, paper,
and produce outlines of documents for the users and tasks described."
I'm not saying the above is any kind of great example of a case to use in
such a class, I'm just trying to illustrate the type of thing I think would
be a useful project for tech comm students. Do any of you who teach or study
in academic tech writing programs use anything like this?
Developing user surveys, requirements specs, etc. could be a different part
of the course or the prof could supply some canned material. The case could
be modified to include various other problems such as how to account for
frequent updates, archiving and retrieving, internationalization, etc. As
for implementing the project, the point of this approach is to show the
students what tools they need to know in order to implement it as they have
decided. Part of their documentation plan then becomes their own training
requirements, if any, so they can produce the documentation according to
I think it's easy for a college offering a certificate program or even a
degree in technical communication to think they are teaching something
useful, and that students are learning something, by filling up class time
with using Framemaker functions, page layout prinicples, the ins and outs of
HTML, or on the other extreme, rhetorical and communication theory. Those
topics would be fine for BA or certificate programs, but in my view students
don't learn about what the essence of this profession is from these courses;
instead they get sidetracked into tools and theories. The essence of this
profession is about communicating technical information and solving the
problems involved in delivering that information - and that's what a case
approach can help teach, whether it's run by a university, a mentoring
program, STC or another organization.
Michael Collier, Technical Writer Office: AX207
Information Systems Laboratory http://isl.arlut.utexas.edu/
Applied Research Laboratories: The University of Texas at Austin
Voice: 512-835-3408 e-mail: mcollier -at- arlut -dot- utexas -dot- edu