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: Technical Writing, QA, and Training From:david -dot- locke -at- amd -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 9 Mar 2001 15:21:46 -0600
The first software company I worked for had sales engineers write the
training program. Customers paid for training. The training did not deal
with the trainee's psychological state. At the end of the training, the
customers had learned one thing--they did not want to use our product.
An instructional designer needed to write the training. And, an experienced
stand-up trainer needed to deliver the content. The skills and personalities
needed for these jobs are different from the skills and personalities of
technical writers.
When I moved to Austin, I found myself being interviewed by programmers that
didn't think I was technical enough. The didn't respect the notion that
technical writing is a technology. And, similarly, while anyone can teach a
class, the class would be taught better by someone with real professional
skills in that area. It is to disrespect their technology to do that.
I've worked in one company where programmers did everything. The sales reps
were programmers. The person that developed the training program was a
programmer. The marketing director was a programmer. It should come as no
surprise that the company only sold twelve units and went out of business.
Programmers cannot do all the jobs and neither can technical writers.
If you want feedback on your content, provide a form to capture the
information you would gain if you taught the class and make it part of the
"Train the Trainer package." Then, the customer will have a fighting chance
of having their psychological states dealt with, and they will gain more
from the class.
Further, having an instruction design plan will a chance to validate the
managerial assumptions that get embedded in training programs. Unchecked
assumptions can kill products. An instructional design plan should test not
only what the customer learns from the class, but what the company learns as
well.
IPCC 01, the IEEE International Professional Communication Conference,
October 24-27, 2001 at historic La Fonda in Santa Fe, New Mexico, USA.
CALL FOR PAPERS OPEN UNTIL MARCH 15. http://ieeepcs.org/2001/
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
