What Practitioners Want From the Academy (*Long Msg: Research Results*)

Subject: What Practitioners Want From the Academy (*Long Msg: Research Results*)
From: Brad Mehlenbacher <brad_m -at- UNITY -dot- NCSU -dot- EDU>
Date: Fri, 22 Oct 1993 22:41:58 -0400

***Warning: Long message attached***

Attached are the results of our survey of potential employers of
graduating Technical Communication students. On behalf of Carolyn Miller
and myself, I'd like to thank the fifteen respondents who invested their
valuable time answering the seven-question survey so thoroughly and
thoughtfully.

To refresh your memories, or for those of you who are new to the list, we
were interested in finding out what practicing technical communicators
valued in potential employees or new hires (and to learn a little more about
industry perceptions towards basic research and thesis training in the
academy).

The fifteen respondents represented a terrific cross-section of the
practicing technical communication community: project specialists, junior and
senior technical communicators, editors, and managers of information products
from companies which included Argonne National Laboratory, Dow USA, Harris
Corporation, Eastman Kodak, Data General, NCR, NEC, and IBM.

What the data told us, and what I suspect they'll tell you upon
inspection, seems applicable to the general debate on graduate school
versus the real world: if you're interested in doing basic research or in
examining and reflecting on theoretical issues over an extended period of
time, industry is not the place to go. Practicing technical communicators,
though, do appear to read research and one rationale for "doing" research
is that it's a perfect way of learning how to "interpret" it.

As a final note, I'd encourage the members of this list to browse
through the comments of the 15 respondents; their positions on various
issues are provocative and the stuff of great debates. Simply opening
such a dialogue, we think, brings us much closer to achieving Stuart's
well-put goal of mixing excellent research with reflexive (instead of
reactive) practice. For our part, Carolyn and I (and many others)
are currently re-examining our thesis requirements in hopes of
accommodating students who are interested in conducting research AND
students who are interested in becoming technical communicators in
corporate settings. Thanks again for helping us accomplish this task.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> Brad Mehlenbacher Phone: (919) 515-4138 <<
>> Assistant Professor Fax: (919) 515-7856 <<
>> Technical Communication <<
>> E-mail: brad_m -at- unity -dot- ncsu -dot- edu <<
>> English Department <<
>> NC State University "An academic is someone naive enough <<
>> Raleigh, NC 27695-8105 to beg downsized companies for money" <<
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

***Data Follows***

RESPONSES FROM 15 PRACTICING TECHNICAL COMMUNICATORS ON THEIR EXPECTATIONS
REGARDING RECENT GRADUATES OR NEW HIRES:

1. HAVE YOU HIRED OR BEEN INVOLVED IN THE PROCESS OF HIRING A TECHNICAL
COMMUNICATOR? WHAT WERE THE REQUIREMENTS OF THE POSITION THAT YOU WERE
AIMING TO FILL?

PARTICIPANT 1: Yes, one time. The main requirements were proven writing
skills and experience using the Information Mapping method of designing
documentation. The person hired had already done several jobs for my company.

PARTICIPANT 2: Yes, we recently have interviewed for hiring two technical
editors, one at the assistant level and the other a technical editor (we
have two grades above Rtechnical editorS). Requirements include a B.S. or
M.S. in Tech Comm (or equivalents in English and technical education) and
at least 1 year of experience for the assistant level, 3 years for the
editorUs slot.

PARTICIPANT 3: I interview and hire software technical writers. The
positions under me generally require knowledge of UNIX, experience using
the vi editor, familiarity with one or two programming languages (C, C++,
FORTRAN, Ada), familiarity with software such as debuggers, databases and
other tools(depending on the project), familiarity with a windows
environment, and knowledge of FrameMaker or Microsoft Word. I look for
experience in both online documentation and hard copy, as we are a small
company and writers must be versatile. I also look for strong writing
skills, knowledge of basic constructs, excellent grammar, and consistency
in presentation style.

PARTICIPANT 4: Yes. We have been interviewing for two positions. One is a
technical writer and the other is a technican (someone who will type.) The
requirements for the technical writer (an entry level position): College
graduate, Experience with programming languages at the college level,
Major in writing/communication/technical comm ...etc., Experience in
writng (must bring writing samples), Experience in FrameMaker (will take
exp in Interleaf or PageMaker though). The technican requirements: High
school graduate/some college preferable, Familar with UNIX, Proficient in
FrameMaker.

PARTICIPANT 5: Yes. Ability to absorb unfamiliar (proprietary) computer
software concepts and communicate them to earth science professionals.

PARTICIPANT 6: In previous jobs, I have been responsible for hiring
contract technical writers. Currently, I review resum
s for potential candidates. Requirements were education and experience in
technical communications. Familiar with software systems. Familiar with
desktop publishing. Comfortable for writing text for Internationalization.
Must have good organizational skills.

PARTICIPANT 7: No, not directly, but I have been involved in hiring people
who require technical writing and editing skills (manuals, newsletters)
and training skills.

PARTICIPANT 8: I use the term communicator to describe writers, editors,
illustrators, artists and production personnel. My point of view is that
writers, editors, and the rest should be equally paid. They all contribute
an expertise to effective communication. Technical knowledge of networking
and computers (this is the most important item in any field). If you do
not know the lingo you will struggle. However, I have found that person
will a can-do attitude and some company sponsored training sometimes are
able to out-perform writers who have been in the field for some time with
a technical degree. A communicator should consider themselves that first
and not let themselves fall into a slot of, for example software or
hardware. However, if a person preference is to be one kind of subject
matter expert over another, that is ok. However in any field the knowledge
base is a lot broader and being employed may mean having to learn
something beyond a cozy niche. 2-3 or more experience in the market,
technical or writing/marketing degree desirable (English is ok, but you
have to have some technical knowledge to be able to write in this market),
recent writing samples of published work in the field and the computer
networking market.

PARTICIPANT 9: I am a senior tech writer. I have a B.A. in English from
NCSU and a Software Technical Writing certificate from Durham Tech
Community College. In the five years that I have been in this career, I
have worked freelance. The positions required knowledge of different
systems and editors (IBM BookMaster, Mac Word, UNIX VI, Interleaf,etc.) as
well as some graphics packages. Also needed was an aptitude to come up to
speed very quickly on the product about which I would be writing.

PARTICIPANT 10: Yes. Familiarity with Windows, Word for Windows, PageMaker
preferable. Not required if candidate has demonstrated ability to learn
such software quickly. Ability to structure information appropriately for
different print and online solutions, ability to work constructively with
an editor, ability to work with other writers as part of a team,
willingness to adhere to our style guide (and understanding of why that is
desireable), understanding of value of usability testing, ability to
research information, assertiveness in dealing with surly developers,
flexibility in scheduling (vital in our environment).

PARTICIPANT 11: Yes, involved as an interviewer of prospective writers for
teams I lead. Experience with tag/style sheet-based desk top publishing
software, preferably using a graphic interface (e.g., MS Word for
MacIntosh or Windows, Ventura Publisher, FrameMaker, Xerox Viewpoint).
Knowledge and experience writing procedures for telecommunications
equipment. Familiarity with Bell System Practices formats. Personal
adaptability and personnel relations skills.

PARTICIPANT 12: Yes. Project Control, Information Design, Courseware
Design and Development.

PARTICIPANT 13: Yes. Document design and programming skills.

PARTICIPANT 14: (a) Yes. (b) BS (preferred) or BA in Technical
Communication with coursework in Computer Science or Electrical Engineering.

PARTICIPANT 15: In my 10 years as manager of a group of roughly six
writers, I have hired over 30 technical writers, all but one of whom write
manuals for software (not hardware). The requirements have evolved over
the years from a heavy emphasis on market knowledge (in our case, the
restaurant and/or hotel industries) to a strong writing background, with
supporting writing samples that demonstrate a working knowledge of how to
present the information logically and succinctly.

2. Do you or your employees perform basic research to help you design more
usable and comprehensive information? If so, what kind(s) of research do
you perform?

PARTICIPANT 1: The only RresearchS I know of is by individuals through
reading the literature, and attending seminars and conferences. The only
organized research I took part in was when several of us saw the need for
improving documentation and formed a team to develop a style guide for
documenting subjects relating to the use of computers. The project
expanded into a general set of guidelines for the complete process of
creating and publishing a document.

PARTICIPANT 2: No, not in any formal sense, although we try new ideas
whenever they might be valuable to the work weUre doing.

PARTICIPANT 3: We are very limited, time-wise, and do no basic research.
We are lucky if one writer can check the procedures another writer provides.

PARTICIPANT 4: The levels of research vary dependant upon the product.

PARTICIPANT 5: No.

PARTICIPANT 6: It is not a formal requirement, and many in our group do
not. I read journals, article, etc. I am very interested in quality in
documentation, and I research and write on the topic.

PARTICIPANT 7: No consideration given to basic research. Just get the doc
done and do it so IUll like it sort of routine.

PARTICIPANT 8: Yes. Usability testing of final manuals to collect info for
the next release, contact with professional groups aka STC, writerUs
connection, continuous improvement of techniques by looking at what other
companies are producing whether they are in our market or not. Customer
phone surveys. Surveys of our customer support organization. We are moving
past the help facility to online documentation and tutorials, minimalist
writing, information mapping, we look at it all.

PARTICIPANT 9: Not really. Usually, if a system is already in place, it is
used (if for no other reason than lack of time to consider a different way
of doing things). Also, changing the docs affects areas other than
documentation (marketing, development). So, normally, the design is not
changed unless there is a glaring reason to do so.

PARTICIPANT 10: We spend a lot of time evaluating our competitorUs
documentation solutions and the market in general. We send people to
conferences (such as the STC one, or the Horton seminars). We do customer
surveys and hold focus groups to find out what information users are
looking for.

PARTICIPANT 11: No.

PARTICIPANT 12: Usability issues and prototype testing.

PARTICIPANT 13: No.

PARTICIPANT 14: We perform research in the form of reading current
literature and benchmarking ourselves against competitorsU documentation.
We also, occasionally, hold focus groups. We do not conduct any formal
lab-based training.

PARTICIPANT 15: First of all, we do not do enough research into the
usability of our manuals. I hope to change that this year. The writers do
participate in internal training classes (where our products are taught to
installers on a very technical level), which gives them access to many
experienced system installers whose opinions we value. They also meet with
our Technical Support staff once each week to discuss product and
documentation issues.

3. Do you or your employees apply existing research in technical
communication to help you design more usable and comprehensive
information? If so, where do you look for the research that you use? What
kinds of solutions does that research provide you with?

PARTICIPANT 1: The recommended method of developing paper-based technical
documentation is Information Mapping at many of my companyUs sites world
wide. One area where standards are needed, but do not exist, is in
developing documentation for delivery on computer screens.

PARTICIPANT 2: We make direct use of existing research very little. The
research results published in Technical Communication, Technical
Communication Quarterly, IEEE Transactions on Professional Communication,
Technical Writing and Communication, and other communication journals
seldom has any direct connection to the work we have to produce on a
deadline basis.

PARTICIPANT 3: Yes, we are beginning to do online, context sensitive Help,
and writers have been researching how to do this and how to comply with
standards, e.g., Motif. They use our in-house library, attend conferences,
read the News groups online, and correspond with those who post.

PARTICIPANT 4: We use the STC journal for the latest ideas and most
current research being done. We will often use the research as a starting
point for our particular project and tailor what is out there to suit our
needs.

PARTICIPANT 5: Yes.(a) STC. (b) Practical books (not original research,
which is generally too woofy-artsy and full of pompous verbiage. Layout;
phraseology; information design.

PARTICIPANT 6: Again, itUs not required, but I try to. I attend local and
national STC seminars, and I read the STC quarterly journal. I have
recently applied to the communications arm of IEEE, and I plan on using
their research as a basis as well.

PARTICIPANT 7: Yes, do apply some research from the literature (JTC,
JTW&C). The research gives us some idea of what might work; canUt usually
directly apply it to our situation.

PARTICIPANT 8: Yes. Pretty much the same as above--usability testing is
extremely valuable, phone surveys of users at all levels, and customer
contact and validation (beta) where we can. Sneaking a peek at our
competitorUs manuals shows us some interesting things also.

PARTICIPANT 9: No.

PARTICIPANT 10: I canUt answer this one quickly any differently from #2.
Mostly we look at what other ground-breaking firms are doing with their
print and online documentation.

PARTICIPANT 11: Yes. Professional publications (e.g., Folio, Journal of
Technical Communication, Society for Technical Communication publications)
Advertising by research companies (e.g., Sandra Pakin & Associates,
Information Mapping, Inc.). More effective methods of organizing and
presenting technical information. Better, more detailed understanding of
communication processes. Better, more effective methods of composing and
presenting graphics.

PARTICIPANT 12: Yes. Corporate research, STC, in terms of formats and
online issues.

PARTICIPANT 13: Yes. Model documents from competitors and other sources.

PARTICIPANT 14: (a) Yes. (b) Journals, textbooks, conferences. (c) Writing
and presentation, organization, etc.

PARTICIPANT 15: I am not sure what this question means. If you mean, do we
explore different writing methodologies that are based on existing
technical communication research, the answer is yes. Until 1987, we used
the Sandra Pakin book called Documentation Development Methodology (DDM),
which I liked very much. More recently, we use the Information Mapping,
Inc. method developed by Robert Horn. This provides us with a methodology
for deciding what manuals to write, what they should contain, and the
format of the information on the page.

4. Do you believe that it is useful for technical communicators to have
experience performing original research? Is the process of writing a
thesis valuable for the technical communicators that you hire?

PARTICIPANT 1: Yes, in that original research (If I understand what that
means) teaches students to consider the writing process and improve their
own ability. Writing a thesis is valuable, because it forces students to
carry a project through to completion under the pressure of a deadline.

PARTICIPANT 2: Do I believe it is useful for tech communicators to have
research experience? No. Is writing a thesis valuable? As both a technical
editor working with practicing scientists and engineers and an adjunct
faculty member in a TCOM program, I see little that persuades me that
graduate students today are being pushed to think and write critically and
rigorously. Much of the writing I see from both sources does not explore
the range of possiblities, it simply latches onto a salient point and
develops it headlong. A thesis can be valuable if it helps a person
develop critical, rigorous thinking, but usually that isnUt the case, from
my experience.

PARTICIPANT 3: Any writing experience is helpful. Most of us never wrote a
thesis, but I did write a number of research papers when I worked for a
Drug company and that was very helpful in learning how to find and present
information. I think basic research, while helpful, can be left to others,
and writers on the job can use it. We have no time for real research.

PARTICIPANT 4: It is more valuable that they posess good oral
communication skills and can ask probing questions to get info directly
form the source--in our case the programmers.

PARTICIPANT 5: Useful? Sure. Name something that isnUt Ruseful!S No.
Definitely not.

PARTICIPANT 6: I think it is, but thatUs because I am a firm believer in
academic research for any type of profession. I believe there are too many
technical communicators without this academic research, and I think that
brings down the standards in the profession.

PARTICIPANT 7: Yes, is valuable but must be applied quickly to a work
situation. Yes, is valuable to write a thesis because shows depth of
research and thought. Also, shows experience in an area.

PARTICIPANT 8: Yes. It can be. However, on of the problems with purely
academic approaches is they start with the theoretical and move to a
provable/unprovable conclusion. The real world research is not so
academic, it is more practical--reporting the facts in a way to satisy
some need of a day-to-day, hands-on user. A thesis is nice for someone
else to use in their research, but when you want to learn how to make
something work good technical communication is a bit different. A
technical communicator in this field has deadlines that are quarterly or
less in occurence and they do not have the leisure of thesis-style
research. Technical communicators have to be instant experts on a
continually changing technological base. Too many technical communicators
in the business today do not interview the people who design and sell the
products being documented. Interviewing techniques are as valid if not
more in getting the correct information in a rapidly changing environment.
P.S.--I would love to join a pure research facility and spend a lot of
time with think-tank types researching and pursuing ideas rather than
continually reporting the facts. Every personality has its dark side :).

PARTICIPANT 9: Not at first. Most writers are really revisers. New books
are undertaken once to writer has experience with the system s/heUs
documenting & a relationship with the developers to be interviewed.

PARTICIPANT 10: For the first part of the question, yes, research skills
are useful to have but in our line of work (designing print and online
docs for commercial, end-user and programmer software) itUs not a vital
skill. For the second part of the question, no, itUs not a big deal for
our company. But then, our billionaire founder is a college dropout.

PARTICIPANT 11: Yes. Research skills are valuable to our documentation
process. We test new formats and styles and statistical methods are
important in evaluating results. Our writers must follow paper trails
through product development documents and interview developers,
determining what to present and how best to present it in our customer
documentation. Yes. Many of the skills used are applicable to our internal
reporting and research processes, to preparing and presenting internal
proposals and studies, etc.

PARTICIPANT 12: No and no.

PARTICIPANT 13: Yes. I think that a lot of theoretical knowledge is very
important because when one is writing a manual one finds no time to think
about such things. So, unless one has intuitive knowledge or has so
internalized the knowledge of necessary to create readable documents one
never gets the chance. ThereUs no opportunity (or very little) to try out
different organizations of the information or different methods of
presenting it or different ways of modelling it. ItUs just collect the
info, create a model in oneUs head, collect more info, plugging it into
the model, adjust the model slightly to fit new info, do a quick
beginning-to-end rewrite/edit and go with it. (Or so it seems).

PARTICIPANT 14: (a) Somewhat, depending on the subject of the research.
(b) It has not yet been demonstrated to be useful here.

PARTICIPANT 15: Students should absolutely learn how to do their own
research. Product specifications and Subject Matter Experts should only be
used to validate research that the writer has performed personally. I
advocate doing a thesis because, as a graduate student at the Cornell
School of Hotel & Restaurant Administration, I did a thesis (obviously not
on a technical writing topic) that was very helpful as an exercise in
developing my writing. It gave me the confidence which lead me to this job.

5. Have you ever asked technical communicators, as part of their job, to
perform original research?

PARTICIPANT 1: No.

PARTICIPANT 2: No.

PARTICIPANT 3: No. My company is small, with limited money. All efforts go
toward developing and releasing products.

PARTICIPANT 4: Not exactly.

PARTICIPANT 5: No.

PARTICIPANT 6: No, I havenUt because IUve never been in a management
position. If I ever do manage a department, I certainly will ask for
either original research, or at the very least, I will insist that some
type of research be applied to our work.

PARTICIPANT 7: No.

PARTICIPANT 8: No.

PARTICIPANT 9: I have been asked to perform original research.

PARTICIPANT 10: Yes.

PARTICIPANT 11: Not of technical communications nature, No.

PARTICIPANT 12: No.

PARTICIPANT 13: No.

PARTICIPANT 14: Yes.

PARTICIPANT 15: All the writers perform software testing that validates
their manuals. In addition, they occasionally do marketing research to
help validate the productsU features.

6. What skills do you think graduate programs in technical communication
currently over-emphasize or under-emphasize?

PARTICIPANT 1: Under-emphasize: Team writing, interviewing, and knowledge
of technical subjects. Over-emphasize: DonUt know.

PARTICIPANT 2: Overemphasized: Theory. I know itUs important to academics
that their field be perceived as RscholarlyS, but little of theory carries
over to a writer or editor in working day to day. Writing and editing are
skills, not knowledge, and having the knowledge doesnUt mean you can
perform the skill well. We hire people specifically for their skills.
Technology. Yes, a tcom person today needs to know how to use a word
processor, something about a DTP system, and how to get around a personal
computer. No, knowing about all of this stuff does *not* make the person a
writer or an editor. These are tools, not skills; the person who cannot
write well with a pencil cannot write any better with aPC keyboard; a
person who canUt draw with a pencil (for instance, me) still canUt draw
using graphics software. A tcom program that produces computer whizzes
will not have a good reputation if the studentsU communication skills are
bad. Underemphasized: Critical thinking; editing as a separate skill from
writing; revision as the key to good writing, rather than preplanning,
which is a small part of the total effort; the importance of technical
knowledge as a crucial base for someone working as a technical writer or
editor; and most importantly, just making sure that each student can
actually write well when they leave the program.

PARTICIPANT 3: I donUt know about over-emphasizing, but IUm greatly
distured at the grammar, spelling, and sentence structure in writing
samples applicants present. Even those that were graded A were
disappointing. (Which leads me to believe not only are the students weak
in those areas, but so are the instructors--a vicious cycle here.) We
canUt be too precise when instructing users on how to do something.
Credibility is on the line, as well as safety and $$$. We must say exactly
what we mean and say it absolutely correctly.

PARTICIPANT 4: I think programs do not place enough emphasis on *real
world* experience. Aside from an internship/fellowship, students in many
programs are too involved with theory. They need more experience in
completing writing assignmts in the *real* sense. Role playing and class
projects are not a good subsitiute for the people who will play an
integral role in the professional technical writerUs world.

PARTICIPANT 5: CanUt say. There are too many programs for a useful
generalization.

PARTICIPANT 6: I donUt know enough on current programs to comment
intelligently on this.

PARTICIPANT 7: Over-emphasize research, and under-emphasize working in a
fast-paced environment.

PARTICIPANT 8: Too many simplified examples. Programs do not spend enought
time with a variety of techniques. They gloss over information mapping,
good outlining, storyboard, and flowchart planning. Graduate and
undergraduate programs do not emphasize the real world atmosphere of being
part of a product development team with real people. Many technical
communicators are thrown into an environment where they perceive the
engineer, marketing person, or even the president of the company is the
expert in the field (which extends to technical communicating by
association) which is very intimidating. If communicators were taught to
participate in a team atmosphere, they could approach each assignment with
confidence that they are contributing, not having to react to the whim of
the week by their manager, a VP, or the CEO. When you have to work with a
variety of points of view, you soon realize that the best solution is not
always the concensus, but a melding of ideas and a compromise. The best
documentation I have written was really a team effort. It breaks down this
way: Engineer--theoretical technical expert, design of the bare bones
level marketeer--user conscious. Pubs Mgr--schedule oriented. Illustrator
or artist--graphical sense of organization. Quality assurance/quality
engineer--technical correctness expert. These are the people who really
know if the stuff works and they are probably the most valuable reviewers
I have had. CSO--Customer Service Organization--This is where the rubber
meets the road. These engineers and technicians help the customer out of
knotty problems that may or may not be documented by me, the technical
communicator. CSO persons are one of the guages that my documentation
works. If they tell me that most of the service calls are from people who
did not read the manual, but when pointed to the manual had an RAha!S
experience I feel good. If CSO tells me we missed the boat I can correct
that mistake in the next release of the documentation. If CSO tells me
that the correct information is there, but the customer canUt find it,
this requires organizational thinking. Editor--keeps my lines of text
straight and has insights that are removed from my up-close day-to-day,
living with the problem. Valuable insights.

PARTICIPANT 9: I donUt know.

PARTICIPANT 10: I donUt know. A friend of mine who enrolled in the
masterUs program in technical communications at the University of
Washington felt that the university program overemphasized theory and
underestimated practice--in fact, had no idea what current practice was in
the industry.

PARTICIPANT 11: The programs with which IUm familiar under emphasize
project management methods. Of the two MS graduates we have employed,
neither was employed only as a writer. Such senior personnel have been
tasked to lead writing teams, usually for new products. These team leaders
are often required to plan, develop, and supervise or manage the creation
of new documents, sometimes in new formats. They must meet deadlines with
available staff but with little or no guidance in the form of existing
documents. For instance, we are currently developing an Electronic
Documentation version of our documents for distribution on CD-ROM. The
team leader for this project is conducting and supervising research,
planning document package organization, and scheduling staff and
resources. The skills required to accomplish these tasks this person
acquired from seminars, profession conferences, professional publications,
and on-the-job training; not in the MS program he completed.

PARTICIPANT 12: Not qualified to answer.

PARTICIPANT 13: Emphasize models of effective documentation.

PARTICIPANT 14: Programs seem to over-emphasize theoretical work and
under-emphasize the need to obtain additional technical background.

PARTICIPANT 15: I wouldnUt know what areas are over- or under-emphasized
because I havenUt examined the curriculum of any programs.

7. What series of activities do you think technical communication students
absolutely need to be introduced to while in school?

PARTICIPANT 1: The writing in my area is, for the most part, very technical.

PARTICIPANT 2: IUm not sure what you mean by Rseries of activitiesS. My
emphases would be as follows: Tech writing: revision as the key to good
writing; stress the *writing*, not the forms (tech report, interim report,
memo, letter, etc., etc.). IUve seen lots of people who had the forms down
cold, but they were still poorly written. I think anyone who learns to
write well can master different forms with a minimum of effort. Tech
editing: the difference between copyediting and substantive editing (the
latter demanding technical knowledge); how to schedule and budget, and how
to juggle projects that are underway simultaneously; how to decide what to
let go of and what to insist on when the schedule or budget is changed and
there isnUt time or money to do everything that was envisioned at the
start; the skill of interviews or conferences with technical experts in
order to gain information (tech writers) or negotiate changes to a
manuscript (editors). Oral presentations: You would think that a
professional communicator should be able to prepare and deliver a
well-structured and well illustrated talk on a suitable subject. So why
are our professional meetings just as irritatingly poor as those of the
technical folks we support? If we canUt produce visible visual aids for
our own talks, how can we help the folks we are supporting once we get a
job? In general: help students develop a clear understanding of the bounds
of tech comm. It isnUt journalism, creative writing, or casual
conversation, each of which has its own style, guidelines, and tone, none
of which are appropriate for technical reports, peer-reviewed literature,
or many of the other types of things tcom people work on.

PARTICIPANT 3: In addition to writing, they should learn project
management. We are very involved with developers of software and writers
must learn to work in the same space as they do. We write documentation
specifications and we schedule milestones. Many companies are using the
Total Quality Management approach. A introduction to TQM would be helpful.
And maybe something on human factors analysis that applies to the real
world. I havenUt had much experience with graduate programs, but I have
found many new grads from a 4-year undergrad program have worked only on
PC-type projects and have not been exposed to larger systems. They need to be.

PARTICIPANT 4: There is a need for writers to communicate the importance
of TW to the powers that be. Often, the challenge is not in the writing,
it is in the convincing. TCs need to understand that there are many
conflicts that do/will/can not appear in an artifical settings such as a
class room. I think the ideal situation for a graduate progam would
incorporate a team of a masters/Phd engineering student and a tech
communicator. The TW would document the project--not write the engineerUs
dissertation, but create a seperate project. That has been my experience
in the working world. I document an engineerUs creation.

PARTICIPANT 5: IUm sure existing curricula address this as a starting
point. Since I havenUt given this any thought, IUll refrain from having an
opinion.

PARTICIPANT 6: We hired some technical communicators with BAs in the field
who still have problems with basic grammar. Also, IUve noticed a lack of
planning and organization skills (planning and organizing a document).
Some writers donUt even believe in outlines! I find a real lack of the
basic, and very little emphasis on traditional research. Also, there is
very little focus on person/machine interaction. And, thereUs definitely a
lack of trainingist, well organized, clear, and concise communication).
The first year teach them to write this way, the following 3 years get
them practical and real world experience. Form teams with other
departments, create a publications team, gather the information from
people in the other departments and from their library. Have the
communicators work individually at first (but part of the team). Then move
into team collaboration where everyone should use the same terms,
definitions, style, punctuation, share ideas, etc. In the last years, have
them go into industry on an intern basis where they will actually be
producing something with experienced technical communicators. Let them
meet and learn to understand the engineer or subject matter experts.
Having budding engineers, doctors, or scientists meet budding
communicators and share experience, points-of-view and ideas is a sure
fire way to remove stereotypes. Note: If I wanted to be an engineer I
would be one. I wanted to be a writer, tinkerer, and lab rat (one who
rolls up the sleeves and learns the new and ever changing subject matter)
first. Documenting the folding of paper into planes and origami is the
place to start, but students should be producing documentation in the
field they wish to work as a communicator.

PARTICIPANT 9: How to write clear, concise, uncluttered documentation. How
to attend reviews and respond to review comments (not personally). How to
create a mutually respectful relationship with developers (including GREAT
interviewing skills). Also, students need to know that this is usually not
a very exciting job. I came into it thinking I would be writing new books
and obtaining great knowledge - tUainUt so, usually. Tech writers need to
be very organized, resourceful and intelligent, basically.

PARTICIPANT 10: How to work in a team. How to dig information out of
reluctant technical experts. (These are both people skills--something many
writers overlook or tend to think isnUt necessary.) How to accept
editorial criticism constructively. How to give up perfectionism in the
heat of crushing deadlines. How to know whatUs good enough. How to deal
with stress.

PARTICIPANT 11: Team exercises and practice document reviews. Our BS
people often are lacking in interpersonal communication skills needed in a
team setting. If possible, exposing them to teams of mixed ages would be
beneficial to developing the skills needed to succeed in team efforts.
More important, students should experience having their efforts reviewed
by subject matter experts who are not technical communicators. Young
technical communicators often suffer needlessly on the job until they
learn to separate their egos from what they write, to not take review
comments personnally, and to deal maturely with the rare comments that are
personal. Creative writing students routinely face gauntlets of such
criticism in their classes, so should technical communicators. One matter
that might be better covered is time management methods. Some new
technical communicators are stymied by the shear size of their first
project. Hundreds of pages to be at least reviewed and updated, perhaps
reorganized, reformatted, or (shudder) rewritten. They need to know how to
divide and organize a project into manageable tasks. They should be able
to prepare their own milestones from schedules provided by management.

PARTICIPANT 12: Organization, marketing writing, presentation skills,
business issues.

PARTICIPANT 13: I think the ability to form a mental model of the
product-hardware-software-information with limited information is a key.
Because once I have a usable model, I can start fitting all the new
information into the overall structure. What I find incredibly lacking is
people who have a good understanding of software development who can
write. (A C-programmer with communication skills is still at the top of my
wanted list (just above a Gordie Howe rookie card). There seems to be a
fair amount of hardware knowledge, a fair amount of end user type ability,
but people who know what a programmer is going to need to know are rare.
And yet, the process of designing a document (set) is very similar to the
process of designing a software package. From the modelling on through.
Except that the writer has to rely so much on othersU ability to get the
work done, and so on.

PARTICIPANT 14: Coursework in a specific technical discipline, writing
projects involved with that discipline, and extensive reviews with someone
other than (in addition to) the teacher of a course (to expose students to
the review process).

PARTICIPANT 15: The most important activities involve the development of
fundamentally strong writing and an understanding of how formatting plays
an important part in the communication process. Actually, I have always
thought that it would be interesting to have a student (or team) redesign
the manuals for an existing commercial product. The class project would
include researching and writing better manuals for the product, submitting
the result(s) for their class, and ultimately submitting their new
manual(s) to the company that originally wrote them. Not only would they
have to analyze the usability of the existing format, but they would
undoubtedly find bugs and suggestions in the product itself (a small part
of their grade could be based on how effective they are in persuading the
company to listen to their suggestions, which is an important part of a
technical communicatorUs job).


Previous by Author: Re: Online Help Guidelines
Next by Author: Re: Grad school (PhDs)
Previous by Thread: Re: Q: Converting Word Doc to ASCII for E-Mailing
Next by Thread: Re: Grad school vs. the real w


What this post helpful? Share it with friends and colleagues:


Sponsored Ads