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.
> The replies to Mr. Plato (author of the original
> incendiary email) have lent
> authority, unfortunately, to his view that the
> practitioners of our art are a brittle
> tribe. ?I?m component, I?m good, I?m liked, I?m
> esteemed? ran most of them.
I'm a component? Wow! What do I plug into? I have been looking for
a port that would meet all my needs.
> I assume Mr. Plato was deliberately trying to stir
> things up here. Kind of like going
> down to the Republican Club and telling them
> they?re a bunch of buffoons, and
> nothing like us -- objective Democrats. Or vice
> versa. If this list needs a gentle
> stir now and then -- bring it on!
This list needs a full-scale plague sometimes, but that is another
off-topic story.
Actually, I was merely trying to forward my agenda that says:
technical writing should be about content not about tools and
techniques. Tech writers should focus 90% of their energies on
learning and digesting the subject matter they are documenting and 10%
of their energy learning tools.
> But too many replies took his bait. Mr. Plato had
> just two points: 1-HE left our
> profession (another failed TW, alas); 2-He?s become
> an ENGINEER. And incidentally, he?s interviewed many
> many many incompetent TW?s. Pretending to
> wrap these self-serving points in a highfalutin
> discussion about our profession just
> won?t fly ? I don?t buy it.
I would say that your reply to my message suggests you did buy it, you
just didn't like the taste of it when you got home and started chewing
on it. You should have kept the receipt.
> I myself have enough engineer stories to fill a book
> or two. I can?t count the number of failed engineers
> I?ve had to interview for TECH WRITING spots.
> Some things are not worth discussing, among them is
> whether or not technical writing is a worthy
> profession. After you?ve been doing this for a while > you know that
some clients DO NOT esteem this
> profession. So what? Others do. Some do
> not value education or training. So what? Tons of
> businesses are run by people
> who a not insightful, creative, inventive, etc. and
> fail every day. So what? People
> esteem what they do, what they know and are anxious
> to find reasons to dismiss what they don?t know.
> This is a commonplace.
Yes, many companies do not value technical writers. My retort: they
would if they had decent writers. Case in point - about four years
ago I did a gig with a company in Seattle. They hated their technical
writers and treated them like janitors. Likewise, the writers they
had were utterly incompetent. One of the writers who worked on
complex client/server applications did not even comprehend the concept
of client and server.
After six months of training these writers, firing some of the really
bad ones, and hiring some new blood, the company turned the corner.
The writers all became very skilled with the technologies the company
used. When the writers began to truly contribute ideas and technical
know-how to the team, the company responded and gave them all big
bonuses. Also, all of the writers were elevated to respected, equal
positions on the development teams.
The morale of this little story: respect is a two way street with a
reversible center lane. A) You have to give to get. B) You have to
work to get paid. C) If you try to make a left turn between 4-6 pm you
will get hit and wiped out.
Seriously, if you want your company to value your work - make your
work invaluable. It really is as simple as that.
> Within projects that consider our profession
> integral plenty of tough issues arise.
> Let?s stick to them, shall we?
> Does this scenario sound familiar? You?re well
> within the project lifecycle, in fact
> testing ? a major project milestone -- starts next
> week. However, because of
> deadline pressures, unreasonable client
> expectations, and the ITERATIVE ;-)
> nature of the project lifecycle coding will continue
> right up to the minute the project is turned over
> to the testers. The project?s sacrosanct PROJECT
> PLAN calls for the documentation to accompany the
> system into testing. Any problems? Your
> answer is ?HA! HA! HA! Problems? Listen, technical
> writing workdays are 60 hours, not the mere 24 for
> engineers. Problems ? ha!? This IS your answer, of
> course, and the entire scenario is trivial and not
> worth bringing up. But what do
> you do when the project moves into the POLITICAL
> ZONE. When all project discussions revolve around
> what the project will BECOME, not what it IS? After
> a project evolves and develops cracks and fissures
> this is a deadly serious issue. Jobs and careers are
> on the line, and not just your own.
> What do you do when asked to write about how a
> system WILL EVENTUALLY
> behave while ignoring what is actually does.
> Remember, the person asking you
> (an engineer or manager) has their job, and possibly
> an entire team?s or group?s, on the line.
>
All of these problems are easily resolved when the writer is an
integral, contributing component of a development team and not wimpy
and brittle. Your description makes it sound like someone else is
doing all these horrible things to you. Guess what? You're as much a
part of the problem.
A good writer can see serious development and technical issues BEFORE
they become a problem. A good writer can manage the differences
between team members. A good writer contributes technical and
logistical ideas to the group. A good writer is an active, dynamic
part of a team contributing his/her insights and ideas when
appropriate and getting his/her tasks done on a timely basis.
A good writer consumes, digests, and disseminates information in a
practical and effective manner. A good writer has an answer to the
problem before there is a problem.
A bad writer sits there and waits for other people to solve the
problems. A bad writer anticipates nothing, responds to everything,
and produces little. A bad writer sees the problems with a
development group as someone else's issue. A bad writer sees
himself/herself as "outside" the group. A bad writer thinks there is
"good information" and "bad information". A bad writer thinks
understanding the technology is irrelevant. A bad writer thinks
knowing a tool is more important than understanding what he/she is
writing about. A bad writer commands little and controls less.
When a project is having problems be they technical or documentation
oriented, the writer is as much a part of that problem as an engineer,
a manager, or a support person. EVERYONE is responsible. EVERYONE
has a role to play. And when the shit hits the fan EVERYONE is to
blame.
Too many writers erect walls between them and the engineers and
developers. They live inside a bubble of tools and techniques. I
understand the thinking - "if I shield myself from the engineers I
cannot be responsible for their shitty products." WRONG. Bad
products are as much the fault of a bad writer as they are a bad
engineer.
Too many writers also fail to learn the technologies and technical
details regarding the products they are documenting. This leads to
weak, ineffective documentation. Which leads to weak, ineffective
products. Which leads to weak, ineffective companies. This leads to
... well, you get the idea.
Also, too many writers blockade themselves from work and as such never
become an integral part of a team. A good writer has a
"service-oriented" attitude. He/she does what needs to be done. A
good writer sees himself/herself as a member on the team with a role
to fill. When the time comes to catch the ball, a good writer catches
it without any strings attached.
The point of my original post and of many others like it has always
been the same. That writers need to focus on content and less on
tools. That writers need to see themselves as an integral, active
part of a team. And mostly, writers need to command their work in a
"service-oriented" manner.
I realize my ideas infuriate many. I also know that my ideas work. I
use them at my company everyday. Writers at my company are well
respected and well paid. They are also expected to work hard and know
the technologies they are writing about. When a writer churns out a
document about a database, I expect him/her to know exactly what that
database is and what it does. I also could care less what tools are
used. The important point is always to communicate the technical
issues. Whether we use FrameBlaster or MS Turd - as long as the job
gets done, how we get there is irrelevant.
To those that are infuriated, explain to me how, exactly, I am wrong.
How is it that training in tools and techniques is more important than
content? How is it okay to blame all problems on the engineers or
other employees? How is it acceptable to sit in a cubicle all day
waiting for someone to give you the answers you need?
------------------------------------------------------
Andrew Plato
President / Principal Consultant
Anitian Consulting, Inc.
www.anitian.com
------------------------------------------------------
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com
