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.
Peter, you make an excellent point about QA having the "necessary evil"
moniker often attached to their roles as well. Those that suffer under this
kind of credibility/respectability gap might want to ponder why.
A great deal of research, and my own experience, suggests that if you limit
yourself to a single area of expertise, your influence and credibility on a
team (any team, software development or manufacturing, or anything else) is
limited as well. If you add to your functional depth and breadth by
understanding something of the industry, the technology, design, usability,
testing, and/or quality assurance, you are much more likely to gain
credibility since you add value beyond all the fluffy communications stuff
that you're supposed to be the formal expert in. If employers neglect
documentation, sometimes it's because the technical communicators have
isolated themselves into their little ivory towers of syntax and active
voice and font fondling, and neglect (and often refuse) to learn something
of the business, the product and the audience for their products. I will
maintain with my last breath that as long as you treat documentation as
separate from your product, you will be treated as separate from your team.
I've been fortunate enough to add some of those areas of functional
expertise, and combined with the ability to communicate well in most media
and interpersonally, I tend to become a hub within my development teams. Am
I an expert tester? No, but I know enough about it to support QA goals and
efforts. Are the QA people expert communicators? No, but they understand
enough about it to question ambiguity, point out gaps, and make suggestions
that I might have missed. Same goes for development, business analysis and
implementation.
I am pursuing a graduate degree, but not in technical communications,
because I thought it was too limiting. Funny thing is, as soon as I
announced my acceptance into graduate school, management started to take me
even more seriously. I don't know who that says more about, but it's life
here. If I had told them I was getting a graduate degree in tech comm, I
doubt that my credibility meter would have shot up at all, but because it's
in organizational communication, the breadth and depth gives me that MBA
quality they love to brag on.
My advice for gaining credibility is to broaden your horizons, and whether
you choose to do so through graduate school or certification or world
travel, do what works for you. Then prove yourself in your fields of
endeavor--don't simply expect credibility and respect to be handed to you.
Regards,
Connie P. Giordano
Senior Technical Writer
Advisor Technology Services
A Fidelity Investments Company
704-330-2069 (w)
704-330-2350 (f)
704-957-8450 (c)
connie -dot- giordano -at- fmr -dot- com
"Pray that there's intelligent life somewhere up in space, 'cause I'm afraid
that we've been cheated here on Earth" - Clint Black "Galaxy Song"
-----Original Message-----
From: Peter Neilson [mailto:neilson -at- alltel -dot- net]
Sent: Friday, October 10, 2003 9:50 AM
To: TECHWR-L
Subject: Re: credibility (longish but IMO worth reading)
We're not the only ones with a problem. My wife's a quality engineer. QA is
seen as "absolutely necessary" as long as it doesn't get in the way of
production and shipping. If the customers complain about the bad quality
that got shipped over the objections of the QA manager, the solution is to
fire the QA manager. (She's done there and been
that.)
All that we tech writers ever get is bug reports for the software that was
changed after the manual was finished. Or it was a six-week writing
contract (writing finished before beta, but not before the after-beta GUI
redesign), and there's nobody to blame at all.
Oh, am I ever cynical today!!!
On Fri, 10 Oct 2003 09:03:48 -0400, Mike O. <obie1121 -at- yahoo -dot- com> wrote:
> Goober Writer wrote:
>> If someone with your skills and know-how needs to
>> trade money for credibility, then there is something tragically wrong
>> with our profession.
> There is. We have been venting about it for years on this very list.
> Employers either neglect documentation work or hold it in active
> contempt. Employers don't understand documentation work, and
> documentation doesn't appear on their radar screen unless painfully
> forced by a customer. Rational business priorities, or pathological
> arrogance? After all this time I still don't know. Depends on the
> employer, I guess.
RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or view a live demo at: http://www.ehelp.com/techwr-l3
---
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.
