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.
Donna wrote, "If you're too vocal, they'll dismiss you." I can vouch for
that. We have two separate engineering staffs, as different from each other
as day is from night. With those that have been here the longest, I have an
excellent relationship. They understand that I and the other curriculum
developers are customer-facing and get the fireballs firsthand from both end
users and business partners. Therefore, they listen to us and accept our
problems/issues as constructive criticism.
The other group is just the opposite. They have very thin skin and take each
issue we find personally, as if we took pains to find errors. They don't
understand that what goes out broken, also breaks our reputation in the eyes
of the customer.
David B. Dubin, PHR
Senior Curriculum Developer
Sage Software
727-579-1111 x 3356
david -dot- dubin -at- sage -dot- com
Your business in mind.
-----Original Message-----
From: techwr-l-bounces+david -dot- dubin=sage -dot- com -at- lists -dot- techwr-l -dot- com
[mailto:techwr-l-bounces+david -dot- dubin=sage -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf
Of Jones, Donna
Sent: Friday, May 19, 2006 11:39 AM
To: TECHWR-L
Subject: RE: Moving upstream
For the most part, our writers are involved with products right from the
concept phase. However, some groups welcome our input while others
resist it. Some even try to dictate how we write to the point where they
create unusable manuals or procedures. In a situation like that, you
have to be confident enough in your abilities as a writer to stand up
for what you know is correct or not. It's not easy to tell a product
manager, "No, that heading doesn't belong there because it breaks up the
logical flow of this procedure/chapter/book." But it can be done
successfully.
On one project, I totally irritated the product manager by pointing out
problems in a user interface that had cost big bucks to design. He chose
not to do anything about the problems--until the lead programmer and
several others on the team complained about the same things months
later. After that, this particular product manager tended to listen a
bit more to what I had to say. I try not to abuse this new situation by
complaining too much. It's nice to know that he will probably listen now
if I truly think that something warrants a change.
Sometimes, you have to establish a reputation for pointing out things
that people need to consider before they'll take you seriously. If
you're too timid, they'll never hear you. If you're too vocal, they'll
dismiss you. As you might guess, I tend to err on the side of being "too
vocal." :-) But hey, I've gotta be me!
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today!. http://www.webworks.com/techwr-l
