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.
Karen Graber (long time, no write, K!) wondered: <<My department wants
to hire technical writers to write some manuals on tools and labs. We
have a Publications department that has focused it's time and energy on
science editing of the Initial Reports and Scientific Results from each
cruise. They do a fine job and are very proficient. However, my boss
understands that there is a big difference between a technical writer
and a science editor but we're having a hard time getting this point
across to the previous Manager of Publications who is now a Deputy
Director. She says Publications can do the manuals.>>
You'll probably have the best luck if you forget about the job titles
and focus on the skills required to do the job. I'm primarily a
scientific editor and French translator, but technical writing
fascinated me enough that I invested the time to learn the skills and
discover how the approach differed from science writing. Among other
things, the vocabulary (jargon) and rhetoric (e.g., expository logical
positivist vs. instructional and procedural) are very different. You
can learn to adopt the two very different styles of writing, but need
to be aware that the styles differ before you can do so.
Moreover, there's a very big difference between the acts of editing and
writing. Some editors can't write to save their lives, whereas some
writers can't edit to save their lives. (Others, myself included, do a
credible job of both tasks.) Each profession involves a different skill
set, and learning the new skills may take considerable time even for
those who learn quickly and will eventually become proficient in both
jobs.
The tools are also obviously different; scientific editing primarily
uses word processors (particularly Word), whereas technical writing may
use either Word or something more powerful (e.g., Frame) supplemented
by many other add-ins to accomplish different functions (e.g.,
WebWorks, RoboHelp, HTML authoring software). Learning new tool skills
may be a barrier to some of your editors--not necessarily one based on
competence, but rather based on time constraints and training
resources.
<<We want to use structured writing and framemaker to work toward a
single sourcing process.>>
That raises an initial hurdle right there for your editors: Do they
already understand Frame? (Many people who learned how to type with
Frame running never learn the software's mental model and how to work
with it effectively.) If they know Frame, do they understand
single-sourcing and structured writing? Have they done enough technical
writing to get good at it again with practice? If not, will your
management provide time (probably a year) and resources (formal
training) for them to become proficient in these areas? If not, you
need to hire someone who can already do the work.
<<Our publications people have framemaker experience but not structured
writing and not interviewing experience. They do not often write
copy.>>
See above: this clearly reveals where you'll need to provide training.
If you're not willing to spend the time and money required, and
unwilling to guarantee your staff that there will be no harsh
consequences if it takes them time to come up to speed and they make
mistakes along the way, don't bother trying. Hire someone who already
has the necessary skills, and train your editors to work well with the
new people.
I also have to wonder why your managers think that people who already
have a full-time job can add another whole job to their workweek.
Something has to give: more projects means less time per project means
less quality means more errors. Do you have enough worker-hours to do
both jobs with existing staff? If not, plan to hire more people.
<<I find it hard to believe that a really good tech writer would come
to work here given the low salaries they pay the editors...>>
Depends on the job market. Here, there are enough people out of work
that any job is starting to look good. (So why did I go freelance right
now, you might ask? <g>) But suggesting they hire technical writers
might be a good way to educate your employers about the value of the
editing work too. Just a (seditious) thought...
--Geoff Hart ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)