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.
Dan tells my dad's favorite story (abridged version):
>Sort of like the little sparrow who burrows into a fresh, warm horse apple
>to keep from freezing and is so comfy he starts singing. This attracts the
>attention of a passing cat, who proceeds to eat the bird. Sometimes it
>doesn't pay to be noticed. (Sanitized version)
Ah yes, but the additional moral is this: sometimes landing in s*** is not
the worst thing to happen to you, and sometimes those who pull you out of it
are not there to help.
Hem... ookay. Now I'll try to make this post relevant to TC.
Guru asked about how to publicize his seminar on the net. You might want to
consider whether the net is the best way to get the word out about the
seminar. If companies are unaware of what technical writing is, they're
unlikely to go searching for information on it. The web (as it stands) is a
"pull" technology. You need to push your information toward the potential
If you had access to e-mail addresses for the training and information
services functions in these companies, you might try sending them an
overview of the seminar. If e-mail access isn't universal there, you should
send out mailers directly to the training and computer support folks. (You
may also hit marketing functions since they're often responsible for product
data sheets and such.)
I think the key here is not plastering electronic or paper bills all over
the place. You want to target the folks who have a need--the ones who are
saying, "We have to train all of these computer novices how to use this
software, but the manuals are horrible," or the software developers who are
scratching their heads, muttering, "We're getting so many calls on our new
application. How can we avoid this on the next release?"
What specifically do you intend to deliver? Are you providing an overview of
technical communication and how it's used in industry, or do you intend to
teach people technique? I'd suggest you focus on the former. Target the
folks that have a need but don't know how to fix it. Plant the concept of
technical communication in their minds. Make a connection between TC and
theirparticular needs, and when they return to work and have an ugly
instructional issue come up, they'll be inclined to remember the connection.
Generate the demand for the skills, and then you'll be able to sell the
billdb -at- ile -dot- com