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.
Subject:Re: new manager, need advice From:Andrew Plato <intrepid_es -at- yahoo -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Tue, 9 Oct 2001 13:48:33 -0700 (PDT)
"Evelyn Barker" wrote.
> I want to insulate the writer from as much heat as I
> can, but I don't want to come across as a martinet to
> the rest of the company. I don't think a lot of strict
> lines of authority and rules are going to help, but at
> the same time the writer is concerned that he will be
> pulled in a thousand directions by the competing Alpha
> project leaders.
Your writers need to work in facts not opinions. They need the ability to
differentiate bullsh*t from reality.
A common problem in software environments is engineers who pepper their
so-called objective analysis with their personal agendas. This leads to
competing visions and descriptions of the same thing. If you took the
engineers at their word - your company's products would seem to be many
different things.
I see this a lot in our business - network security. Because people hate
Microsoft, they assume all MS technologies are fundamentally insecure.
That isn't true. They are secure if you use more than your autonomic nerve
stem to install and configure them.
A writer who understands the technical issues involved in the project can
begin to sort out reality from conjecture. The writer should never accept
everything from the engineers as fact. All facts should be double-checked
and validated.
Therefore, the writer needs to shift from "how to document this
technology" mode to "how to understand this technology." Once the writer
understands the technologies, he/she can begin to document those facts
which should help smooth out the differences. Once something is written
down in a logical and technically accurate manner, it becomes much harder
to dispute it.
Do not (like so many tech writers are prone to doing) fall into the "we
need an elaborate process to solve these differences" thinking. Processes,
plans, and elaborate methodologies will not solve the problem. You cannot
replace ignorance with organization. There are a lot of well-organized
morons out there who think their structure gives them intelligence. It
doesn't.
Your writer needs education - technical education. He needs the
intellectual tools to evaluate and assess information for validity. He
needs to sort out differences and help people to reach common ground. The
Dorkinstar(TM) process from some reknown tech comm guru isn't going to do
anything but give you some frosting to spread over the piles of crap.
Second point - KNOW THE ANSWERS TO QUESTIONS BEFORE YOU ASK THEM! This is
a really basic concept that many writers simply will not (or cannot)
accept.
If you ask a question in a vacuum, how do you know if the answer is
correct? I could sit here and ask all of you what the weather is like on
Jupiter. And you could give me an answer. But since I have no way of
validating that information - how can you be sure its accurate - or even
relevant?
Writers can't walk into design meetings completely ignorant. They need to
become engaged in the process of developing the products. That means,
understanding what all those "geeky" acronyms and technical details mean.
This also means your writer needs to drop the FrameMaker book and pick up
a programming or engineering book.
Most (and I mean 75% or more) writers sit in meetings oblivious to what is
being discussed. They expect somebody else to do all the hard thinking for
them while they obsess over FrameMaker commands. This leads to ignorant
writers writing useless documents.
They ask technical questions without any comprehension of what it is they
are asking. Don't ask a question until you already have an answer. In a
perfect environment, the engineers are merely validating knowledge you
already possess.
I have a lot of other ideas, but I'm too tired to write them all here.
Wait for the movie.
Andrew Plato
__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals. http://personals.yahoo.com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Announcing new options for IPCC 01, October 24-27 in Santa Fe.
Attend the entire event, select a single day, or sign up for
a Saturday postconference workshop. http://ieeepcs.org/2001
Your monthly sponsorship message here reaches more than
5000 technical writers, providing 2,500,000+ monthly impressions.
Contact Eric (ejray -at- raycomm -dot- com) for details and availability.
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
