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.
Re: nature vs. nurture, those who succeed by working hard vs. those who
succeed by hardly working (started as writers vs. engineers):
Perhaps the issue of relevance to this list is what are the knowledge,
skills, and attitudes that contribute positively to success as a technical
communicator, and what are the distractions, barriers, and disincentives to
same? Maybe we can identify some common factors that people can use to
assess--and improve--their own situations.
I'll start with some that influence me ... not to say that these are factors
that work for anyone else but to start the conversation.
>Interest factors:
Political involvement-
One of the things that helps maintain my enthusiasm for technical
communications is political involvement. An awareness of the overwhelming
technical/scientific illiteracy that predominates in US society is a
powerful incentive for thinking that figuring out how to communicate clearly
about technical matters is important--and probably vital.
>Experience-
Experience in operations-
Certainly I draw on my degrees in engineering. However, the importance of
those pale in comparison to my experience as a engineering procedures user.
I learned more about human factors and structuring clear directions as a
member of operations than anyplace else. Experience using the products that
you create seems to be critical to really creating useful
documentation/procedures. The emerging discipline of usability testing helps
make the point that users are the best evaluators. I would suggest that
usability testing, important as it is, is less effective than a writer who
has a bone-deep sense--based on experience--of what the user knows/needs/wants.
>Rewards-
User feedback-
I enjoy feedback from people who read what I write.
Social importance-
Related to my interests, it is rewarding to work on problems where my
politics and science and technology intersect (such as energy conservation,
automobile alternatives, etc.).
>Barriers-
Societal disrespect for technical communications/lack of professional standing-
As an independent, I'm careful to avoid being pigeonholed as a technical
writer. It's costly when that happens. Right now I'm working on a contract
for a lot more per hour than I would have earned if they had slotted me as a
technical writer. Since the writing is the least part of what I do for them
(unsnarl unworkable and unusable procedures) I have no problem saying that
I'm acting as a management consultant who then documents the solutions to
problems in writing.
However, this did not come automatically. For good or ill, we're an
increasingly credentialized society and technical communicators do not have
one. Almost every other profession has recognized and benefitted from a
professional standard--lawyers, doctors, accountants, engineers. We lag
behind and pay the price in the marketplace. Accountants haven't
particularly suffered from the widespread use of accounting
software--because they long ago realized that you don't sell numbers or p&l
statements, you sell professional advice. I would think that most of us
would prefer to be seen as professionals who sell advice on communicating
technical information effectively (and who can put that advice to use)--not
as scribblers who can produce x pages/screens per hour. The output of both
may look identical, but the pay is better for the former.
>Disincentives
Disinterest in the product--
One of the things that hurts my effectiveness as a technical writer is not
caring about the product/process being documented. My work suffers when I
have to force myself to care. For example, there are a number of
interesting problems involved in creating user manuals/side panels for
consumer products. But when I feel apathy or antipathy towards the product
that makes it tough. Writing product documentation for super-duper lawn
fertilizer with weed killer would be a challenge. I'd have to approach it
from the position that my job would be to see if I could make sure that none
of it reached the watershed--which is next to impossible. And all the while
I would be thinking of the much more attractive technical communications
problem, how to get people to quit with the lawns and to use
climate-appropriate landscaping so that it doesn't require a petrochemical
stew to grow.
ANYWAY, those are some of the factors that influence my performance as a
technical communicator. If anyone else cares to share the factors that
influence their work, we might learn things we can use in our own work.
John Gear (catalyst -at- pacifier -dot- com)
"It is impossible to dissociate language from science or science from
language.... To call forth a concept, a word is needed; to portray a
phenomena [sic], a concept is needed. All three mirror one and the same
reality." -- Lavoisier