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.
> I wholly disagree with some of the advice from some people on
TECHWR-l.
Apparently, that feeling is mutual...
> I
> think your best course of action is:1. Find the lead engineers.
Schedule
> meetings with them. Talk with them about the product. Get to know the
products
> and what they expect of you.
In addition, communicate how they can help you. It is a TEAM you're
aiming for,
is
it not?
>
> 2. Learn the products and technologies you will be documenting. Surf
the net
> for information about your competitors. Get appropriate books on the
technical
> topics. For example, if your product uses Java, get a basic Java
book. This
> gives you a common language with the engineers, something considerably
more
> valuable than a style guide.
Perhaps they are of a more equal value to most of us.
>
> 3. Read all the existing documents.
Depending on that number, eventually read all the documents. You don't
want to
look
like a work-shirking twit, do you?
> 4. Start with a small, simple project first. Make sure everybody
knows what
> your responsibility is at the company. "I am the person writing all
the
docs."
Start with what is the most pressing need - in many cases, if you're a
lone
wolf,
this is the establishment of conventions, standards and all those other
terrible
things found in plans and style guides.
>
> 5. Find out who will be reviewing your docs. Ask them how they prefer
to
edit
> documents. Conform to their wishes.
This needs to be a two-way street - a collaboration. What if the
editor's an
idiot,
and truly diminishes the effectiveness of the document? Trust me, these
types
exist.
>
> 6. Be humble, be respectful, and accept criticism. Do not fall in
love with
> your words. Do not throw a tantrum when the engineers reject your
first work.
> You have to please them as much as you have to please the readers.
Respectfully push back at your engineers if THEY are diminishing the
value of
the
document for the intended audience. Cooperation and humbleness are
great, as
long
as they don't make you a doormat and cause you to ignore the reason
you're
putting
in all the effort.
>
> 7. Produce results quickly. Prove yourself capable.
>
This is always good advice.
>
> DO NOT...
>
> 1. DO NOT Waste time with documentation plans, project plans, style
guides,
and
> other one-off work. This is a tremendous waste of time and energy.
You need
> to prove your value to the rest of the team right away. Spending time
writing
> documentation plans that NOBODY will read just makes you look like a
> work-shirking twit. Engineers do not care about your style guide. And
your
> style guide does little to prove your writing capabilities. A lone
writer at
a
> company does not need style guides and project plans. Do it all in
your
head.
>
The main reason THIS lone writer was hired was to make consistent the
writing
at
our site.
My managers WANT me to make plans, and I just finished our style guide.
They'll
be
using this
as a measure of my future progress.
> 2. DO NOT show up loaded for a battle. You must be accommodating to
the other
> team members. You are here to help them, not the other way around.
You are there to help each other, or you're just not a TEAM.
> Find a way
> to work inside existing patterns first. Showing up and demanding
everybody
> start conforming to some arbitrary documentation process is a great
way to
get
> yourself ignored and shoved in a corner (and possibly fired).
Many writers are hired to establish the process, and will be "possibly"
fired
if
they don't.
>
> 3. DO NOT confuse the idealistic theories of books (like Ms. Hackos'
book)
with
> the harsh realities of everyday writing. The world is not a
well-ordered
> place. People resist change and order unless there is a clean path to
success.
Which often requires a plan...
>
> If you are new and finding your footing the worst thing in the world
you can
do
> is start demanding some foreign process get implemented. Produce
results
FIRST
> then you can build an empire.
But, gee, I was hired to implement process...
> You do not get authority just because you show up and have a title.
Authority
> is earned after you prove your capability. Capability is not measure
in how
> well you can conform to your own standard. That is like saying,
you're great
> at being you.
Capability in our shop is measured by how well the standard developed
serves
the
company's needs. They won't be MY standards - they'll be what the
company needs
- I
sure as hell am not THAT arrogant.
Of course, if they are different from YOUR standards, and you're too
lazy to
change
for the greater good, that's YOUR issue, innit?
> Tech writers are judged by the outside world on their ability to
*produce*
> insightful, useful, and technically accurate documents.
Which requires planning and consistency.
> Nobody in the outside
> world cares one tiny iota what style guide you used or what
internationally
> recognized process you implemented. Therefore, don't waste your time
on
these
> things. Find a way to make the documents GOOD first.
Which requires planning and consistency.
> Then hone the process
> later.
ALWAYS hone the process, now AND later.
Anyone else here glad they don't work for Andrew?
>
> Andrew Plato
>
> __________________________________________________
--
Bash
bashful7 -at- earthlink -dot- net
"...information is not knowledge." Caleb Carr, Killing Time
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY. http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Take XML and Tech Writing courses online! Our instructor-led courses
(4-6 hrs/wk) give you "hands on" experience at your convenience. STC members
get 20% off! http://www.online-learning.com/index.html.
---
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.
