5
.STC.org
Society for Technical Communication
Management Special Interest Group

Home
About Us
Hot Topic
List Service
Newsletter
Events
Learning
Contact Us

 

 

Border Corner


Writing Training for Engineers?

The following topic was raised within the Management SIG's list serve in January.

Original Issue

I have been charged with developing a tech writing training program for nonwriters/engineers. The company is looking at a 16 week, 2-hr/class program designed to bring the staffs writing skills up to speed. Does anyone have experience in setting up such a program or references that might be of value? Things I should conclude? Pitfalls to avoid?
Jeff O'Gorman

Donald S. LeVie

... First thing I would suggest if you want to be successful, is to go to the powers that be and have them rethink the 2- hours-a-week-over-16-weeks program. Classroom setting? Fugetaboudit. Training online with NetMeeting and conference calls? Odds are slightly better that a few people will take you off mute to ask a question or two. Then they'll put you back on mute and go back to checking their email, writing code, designing transistors, or whatever.

Sounds funny, but I have been there (several times with several companies). Here's what I suggest instead:

1. Combine your own research with input from engineering about the topics that would benefit the audience the most.

2. Create a one-hour training session for each topic--classroom or NetMeeting (or consider making a .AVI training video using Camtasia)

3. Keep the number of topics to no more than 16...and do one each week. When that 16-week period is up, repeat the cycle for the people who missed the first go-round. We used this method and "advertised" the 16-week agenda in advance. We did use NetMeeting and conference calls to conduct the training. We planned on placing a few modules on .AVI video using Camtasia--especially helpful with FrameMaker training...it's like a live Netmeeting session captured on video. We kept our topics tightly focused so the Camtasia videos would be no longer than 5 to 7 minutes each. The modules would reside on a server so ANYONE, ANYTIME, ANYWHERE IN THE WORLD could access them from their desktop.

4. By repeating the training every 10, 12 or 16 weeks, over time, the people who want and need the training get it. Your odds for success will be much higher than expecting engineers to sit for 2 hours over 16 weeks through technical writing training.

5. Rather than trying to get the engineers in one of our satellite offices together for a full day of training, I set up 2-hour appointments for 1:1s with them (over 2 days) to discuss what their specific FrameMaker or content
development issues were. Much more targeted approach to delivering the training they needed/wanted.

Sue Harper

...As a personal writing coach, I find that one-on-one coaching with the individual person yields more benefits than a more general class/session. With the individual coaching, the training is customized to that person's particular writing skills needs. Sometimes, it's a matter of a reading difference impeding the writing process, or the English as a second language phenomena. There are so many individual characteristics that could be interfering with a successful writing experience for a person.

In addition to Holly's response ... Also, most of the time these 1:1s can be done over the phone. That saves
time and expense if those who need the training are scattered geographically.

Holly Harkness

We regularly offer an internal 5-week class in business writing skills, so I can share some of my experiences with you. Remember that writing is part science and part art. You can teach people the rules, but there will always be some who have more talent and aptitude than others. Having said that, you can go a long way with people by drilling them on the basics and alerting them to the common mistakes made in writing.

Here are a few suggestions:
Send out an assessment ahead of time to help you learn how to focus the class. This was useful for us. We asked everyone to write a simple procedure: using the self-service gas pump, ordering a book on Amazon, making a peanut butter and jelly sandwich, etc. We also tested for some of the common writing errors. We found, for example, that most people knew the difference between "its" and "it's," but few knew the difference between "effect" and "affect."

Remember adult learning principles: adults learn by doing. Use plenty of exercises in class and as homework. Ask them to write whole paragraphs or page-length examples. Spend time individually with each student to go over their homework.

We found many employees didn't understand when to use narrative vs. numbered steps vs. bullet points. They also didn't understand how to break a procedure into steps.

You also want to cover active/passive voice.

We tried to avoid detailed reviews of grammar rules, in the interests of keeping everyone awake. We reminded them of the parts of speech and then showed them how to avoid common grammar mistakes.

We covered punctuation pretty thoroughly, especially commas.

If you have a style guide where you work, include that in the course material. For example, if your style is to hyphenate "e-mail," it's worth teaching everyone to write it that way. And, of course, teach them the value of a style guide!

If their main writing tool is Word, I'd suggest a session that reviews the standard Word features that tech writers use: numbered lists, heading styles, tables, inserting graphics, etc. If they will be using standard templates, teach them how to use the template.

If some students are not native English speakers, you should be prepared to devote special attention to their needs. For example, we found that many non-native English speakers had difficulty with when and how to use articles. Native English speakers had no problem with this.

Here are some suggested resources. Note that some of these are oriented toward business writing rather than tech writing.

Alred, Gerald J. Handbook of Technical Writing. Bedford/St. Martin's, 2000.

Choy, Penelope, and Dorothy Goldbart Clark. Basic Grammar and Usage. Thomson, Heinle, 2002.

Hacker, Diana. Rules for Writers. Bedford/St. Martin's Press, 1988.

Hodges, John C., et al. The Writer's Harbrace Handbook. 2001

Jones, Dan. Technical Writing Style. Allyn and Bacon, 1999.

Lanham, Richard. Revising Buisness Prose. Longman, 2000.

O'Conner, Patricia T. Woe is I. Riverhead Books. 1996 (This is a good source for common writing blunders, although I don't agree with all of her opinions.)

Microsoft Manual of Style for Technical Publications. Microsoft Press (Useful if your "engineers" are software developers.)

Tarutz, Judith A. Technical Editing: The Practical Guide for Editors and Writers. Perseus Books, 1992. (Chapter 7 lists the "100 Most Common Errors.")

Online resources: TechCommunity http://www.abacon.com/techcommunity/

Guide to Grammar and Writing http://webster.commnet.edu/grammar/index.htm

Ann L. Wiley, Ph.D.

STC Fellow Ron Blicq is an expert in teaching technical writing to engineers and offers books and online courses as well as instructor-lead workshops:
www.rgilearning.com.

© Copyright 2001. All rights reserved. Contact: Web Master   Created by WebConcepts Unlimited

Opinions
The opinions expressed by contributors to this web site are solely those of the individual contributors and do not reflect the opinions of the STC, the STC Management SIG, the members of the STC Management SIG Leadership Team, or the STC Management SIG WWW volunteers.
Product Endorsements
Reference herein to any specific commercial firm, commercial product, process, or service by trade name, trademark, service mark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the Society for Technical Communication (STC) or the STC Management SIG.

Last updated . Please provide comments, questions, and suggestions to the Webmaster.