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: Promotion (was RE: IT documentation From:Mailing List <mlist -at- ca -dot- rainbow -dot- com> To:'John Posada' <JPosada -at- isogon -dot- com>, TECHWR-L <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 4 Mar 2004 11:01:29 -0500
John Posada [mailto:JPosada -at- isogon -dot- com] is reported to have said:
> Doing your job well is to all the time, every day, with
> everything you do or everything you touch, look for a
> better/cheaper/faster/more competitive way of doing
> it...something that impacts the bottom line.
Hmm. I learn about the new product or the updated product,
and I write about it. Until recently, we had been doing
a Setup Guide and some stray sheets as paper documents and
all else as PDF. Recently (because we were bought by a
company that had decided to go that way) I switched over
to producing a QuickStart Guide (very much like that Setup
Guide) and some stray sheets as paper documents, and all
the rest (product Concepts, Configuration, Integration,
Administration, Reference, etc.) as WebHelp. Brought us
in line with the new owners, and let me shine for a few
months, but didn't save much money. Will probably save a
tiny bit due to greater re-use of doc components, but I
was already re-using a lot, anyway.
I'd love some suggestions on how to affect the bottom line.
My current pet project is an uphill battle to have us
switch from an obscure CLI (command line interface) to
a Webb-ish interface. It would not take very much work on
the part of developers, but it would take a bit. Everybody
nods and says what a good idea and how it would make our
product look so much more polished and mature, etc., but
it has managed to get left out of every project for the
past three years because it's not a money-making feature.
Marketing and Biz-Dev can't see where anybody will buy more
units (the margins are already quite comfortable, per unit)
if there's a sensible, structured GUI/Web admin interface.
So, where SHOULD I be looking. It's not like I can save us
money on print costs. We sell smallish quantities of high-end
products, so print runs are tiny (for the only remaining
printed documents). There are no further savings that I can
see now that everything else is Help.
I could volunteer to take on greater duties in documenting
the requirements (though that would crimp the style of the
people whose job it already is, and I already attend the
meetings and make suggestions and ask semi-intelligent
questions), or the functional specs, though our senior
architect writes as he conceptualizes, including his hints
on how development should proceed, and he's at least as good
a writer as I am. I'd be adding a layer, and not really saving
anybody any work -- just shifting it.
> I may be naïve, but I need to believe that if you do this
> consistently (and not just before review time), a company
> MUST recognize you because if you don't, they don't just
> loose you, they loose the possibility of future bottom-line impacts.
> >lone writer and the sr. technical writer,
> >what is there to be promoted to?
>
> Manager of the Documentation Department (of 1), though with
> more money.
Around here, there are rules that preclude somebody
who supervises no-one from being a manager. Self-supervision
doesn't count, and besides, everybody reports to somebody.
Nobody in the company does her/his own performance evaluations.
Besides, while I report to the PV (some call it QA) manager
(who reports to the Engineering honcho), I'm protected in an
environment that is VERY conducive to getting good technical
docs produced... much more so than if I was reporting to
(say) Marketing (also, our Marketing crew is being laid
off and the functions consolidated in Maryland -- I'm in
Ottawa, Canada).
The latest purchasing company has a couple of writers who
are under the command of a Marketing type. They do ok, but
their product cycles are longer. They actually have some
time after the hardware and software are frozen... not like
our nimble little organization where I'm delivering reviewed
and signed-off document sets sometimes minutes after the
real code freeze.
What are some of these bottom-line improving strategies?
John, you are not likely to ever come to Ottawa seeking
consultant work (snowy and wet and cold and ick-ick-ick
located in Canada.... :-), so any hints that you give
away to me won't be stepping on your own future income
opportunities. Ahem.
/kevin (senior writer and only writer since being hired here
in 1998)