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: new kid on the block (long) Take TWO From:"Jones, Donna" <DJones -at- zebra -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Thu, 10 Mar 2005 12:17:10 -0600
J,
For our product releases (bar code printers, as a matter of fact), documentation is a requirement. And it's not just required by us internally. The FCC has a say in it as well. If I don't have the documentation ready when it's needed, the product can't be released, the same as if any other part of the product wasn't ready.
It's your head (not the former writer's) that will roll if something is wrong in the documentation, so take ownership of what you produce. You're going to have to step on toes to change anything--the trick will be stepping on them gently rather than stomping hard. Here are two possible ways of handling things:
1) If the former writer and your reviewers give you conflicting instructions, send an e-mail to all of them summarizing both sides and your proposed solution. Say, "This is what I plan to do unless I hear a consensus otherwise." Then let them duke it out rather than taking jabs at you. Keep the conversation going with all involved if someone tries to take it back to a one-on-one battle with you. You may find that they give in more easily when they have to answer to each other.
2) Filter through all of the input and do things the way you think they should be done without involving the former writer or the reviewers until you're finished. Your response to their complaints should be, "I took everything into consideration, and I felt that I needed to do it this way because it made the documentation more usable." It's difficult to argue with someone who spouts usability as their reason because then you sound like your goal is to create something UNusable. (I've seen this trick work.) If nothing else, it will certainly make them think about what they want changed and why. Maybe they'll grudgingly come around and work with you instead of against you.
If neither of these approaches work, smile and do what they tell you to as you look for another job.
Good luck!
Donna L. Jones
--------------------------------------
Technical Writer II
Zebra Technologies Corp.
Vernon Hills, IL
djones -at- zebra -dot- com
WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo: http://www.webworks.com/techwr-l
Your Ad Here! Have a product or service you'd like to get some attention for? Use this space to get the word out! Contact lisa -at- techwr-l -dot- com for more details.
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
