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.
> Richard Nelson Bolles has been saying this for years in his "What
> Color is Your Parachute" book series. I've heard it said the resume
> isn'# a hiring document, it's an exclusion document.
>
> You don't need specifics on your resume, only specific stories leading
> to potential benefits:
> - Increased product sales by 30% through the release of preliminary
> product documentation
No one tracks such info at our company. I'm not sure how one could
know. For a new product, product sales numbers are forward-looking
guesses. We'll know next quarter/year whether they were even
vaguely accurate. Unless there's one specific BIG customer that
made a BIG order contingent on a specific item of documentation
(that wasn't otherwise in the plan), there's no way to connect
eventual new-product sales numbers with documentation.
And, even if you COULD, how would you justify how much of the
five-million-dollar order was due to the fabulous doc-ishness,
as opposed to the 27 other engineering requirements that were
also met?
"Gee, Mr. Techwriter, we're also looking at hiring three engineers
who used to work at the same company you did and, combined,
the four of you seem to have taken credit for 218% of the
fiscal benefit from that one project!"
For an existing product, somebody with the knowledge and ability
would need to examine all sales for that product, before and after
you ... ahem... "release[d]... preliminary product documentation",
and decide how to eliminate all other factors in a shifting market
to conclude that it was the docs and not eleventy-two other
factors that made the difference.
> - Reduced support calls by 50% by initiating and moderating a
> user support forum
Now this one, I've done. Sorta. Implemented the TAC BBS and later
the TAC support website for Ericsson in the '90s (kudos to
a guy named Uday S. who did a lot of the technical grunt
work to convert from BBS to early web), and since I
was a member of the Technical Assistance Center (TAC), we
actually did verify that the number of support calls declined
after the site was up.
But that was the last time I had any opportunity
to have that direct an affect and have a clue about
effectiveness.
In my current gig, I report to the local engineering
department, particularly the testing group.
The local tech-support guys (one of whom I never see
because he works a late shift) report to the support
organization, elsewhere in the world. We don't have
the means to track the effect on support calls due to
specific changes in the customer docs. At best, we
get a hint that calls have slightly diminished, or
have shifted emphasis, but it's not always clear that
something I did had any effect. The market and our
customer base are too fluid.
One thing that Customer Support did that DID improve
the customer experience was to streamline the
contact process, getting rid of annoying extraneous
data-gathering - whether via forms on the website or
via the harried Support guy having to ask silly
questions beyond the immediate scope of the customer's
... er... um... "issue".
Calls for XYZ problem - for which I finally got a
good explanation/workaround released - dropped off...
but whoops, it might have been because the introduction
of a new feature has lured many customers away from
the problematic workflow and they no longer needed
to get that old workflow working, or it might have been
because the customers' own markets are shifting and they
no longer have as much call for the XYZ process that
was once a pain for them to implement on our product.
Anyway, my guess would be that most TWs are in no
position to be able to make specific claims about
how their work _positively_ affects the bottom line.
Negative effects are far easier to see - how much
do I cost to keep me warming this seat and using
company computer resources? How much time do I
take from developers and testers who would otherwise
have devoted that time to more development and
more testing?
Those are easily measurable. Just look at my
timesheets or at timesheets of the folk involved.
When I'm doing a good job (or you are in your
respective positions) I'm practically invisible.
Praise for good docs doesn't happen - except if
somebody is visiting and gets introduced to the
techwriter.... Customers just use them.
Complaints do happen. Our masters have the sense
to realize that the same effect applies to all
those expensive engineers and software developers
as does to writers. When something "just works",
people don't take much notice. When it doesn't
work as they expect, _that's_ when they sit up
and make noises.
Discontented noises.
Customers wanting to do something with our
product that we hadn't anticipated are an
opportunity for either Sales (after some new
development), or Professional Services, to make
the company some more money. But customers
wanting to do something with our product that
we hadn't anticipated are an opportunity for
the techwriter to quietly fix that oversight
in his docs. Not quite the same fanfare there.
All of that to say: It SOUNDS good to insert
a bunch of claims that you "raised this by
this amount/percentage", "lowered that by
that amount/percentage", but I'd be very surprised
if the majority of us were able to justify any
such claims.
If I saw such claims, when looking to hire
someone, I'd immediately say the same thing
that I say to other religious claims:
How do you know?
Maybe our brand new Oracle-based ERP system will
open up vast new vistas of opportunity for me
and the other techwriters at the company to
start claiming such stuff. woohoo :-)
- Kevin
The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.
Use Doc-To-Help's XML-based editor, Microsoft Word, or HTML and
produce desktop, Web, or print deliverables. Just write (or import)
and Doc-To-Help does the rest. Free trial: http://www.doctohelp.com
Explore CAREER options and paths related to Technical Writing,
learn to create SOFTWARE REQUIREMENTS documents, and
get tips on FUNCTIONAL SPECIFICATION best practices. Free at: http://www.ModernAnalyst.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
