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.
You have a few limited options. First, you can try to win them over. That's
a long-term job in itself. Second, you can ignore them and be as pleasant as
you can be. Third, you can go to a sympathetic boss or boss's boss and vent.
Fourth, you can play their game. Fifth, you can give up entirely.
Within each strategy are dozens of tactics. The strategy you select will
depend largely on your personality and exact circumstances. For example,
being a geek myself, I tend to play the geek game; that's my strategy. But
on occasion I've had to just dig in my heels and pound the table. Try that.
It's hard to do both simultaneously.
But the fact is that if the corporate culture is invention-centric, and
nobody really cares about human communication, you're on an island with
head-hunters no matter what you do. If you want expansion on this principle,
see "Built to Last" at your local bookstore.
If you want to smile wanly and just get along, get "People Styles at Work"
from that same bookstore. It won't solve your problems, but it'll put them
into a new perspective. As for procedures, many companies don't have them
because they're not yet mature enough. For that, do a Web search for
"Maturity Model". You'll find that there are levels of corporate maturity
that run, depending on the model, from zero through five. Until you're at
level three, processes don't enter into the company's paradigm. If your
company is less than a three, ANY process will cause problems. Expect to
encounter strong resistance. In companies that are zeros, ones, or twos,
everything depends on interpersonal relationships and trust. If the
engineers don't trust you personally, they may not cooperate.
Aside from these things, specific suggestions have to fit into one of the
strategies, so I suggest you work from the general to the specific.
Tim Altom
Simply Written, Inc.
Featuring FrameMaker and the Clustar(TM) System
"Better communication is a service to mankind."
317.562.9298
Check our Web site for the upcoming Clustar class info http://www.simplywritten.com
First of all, thanks for being there to share a lonely moment in my
professional life.
Until last year, the organization I work with had only one technical
writer -
he had moved into the role from marketing because there was no technical
writer in the organization. Last year, it woke up and decided that it
needed
world-class documentation for its world-class products. I was recruited for
the job. (I had been an instructional designer making CBTs before this.)
Setting up processes is at the bottom of the priority list in a place where
engineers don't have much of a clue why a technical writer is required at
all.
While the processes are still incipient, is it necessary to be unpleasant to
engineers to ensure that they give inputs on time and do not try to tell me
how to do my work? Also, can anyone give me guidelines on what to include in
processes so that unpleasantness can be avoided.
TIA,
Uma.
