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: The mushroom syndrome From:Tom Campbell <tomcampbell -at- EUDORAMAIL -dot- COM> Date:Wed, 20 Jan 1999 14:46:36 -0000
John Gilger and Tasha Benson are definitely right. Invite yourself in. Help the developers/engineers, and they'll help you.
Tasha: "I've gotten the entire development and Product
Operations groups to work with the writers by having them do the meeting minutes. Not only do we have a good starting point for are manuals but we are usually aware of software/development changes."
John: "Actually, taking the notes of the meetings gives you a good start on developing your manuals because you get to record why the decisions were made."
Taking meeting minutes may be an unpalatable task (I know it is for me!) It's tedious, it can feel subservient, and I can't put meeting mins. in my portfolio!
But remind yourself that you are not in a secretarial role but in a documentation role. Do the minutes well, and you'll be appreciated--and informed. Particularly useful to the group can be the recording and tracking of action items and scope changes.
Here are another couple of ways you can join the gang:
- Offer to create and maintain an issues database in a simple db app like Access (or, to make it easier, in a spreadsheet).
- Offer to create and maintain a knowledgebase, especially if it's web based (the developers may be on Unix boxes or some other system different from yours, so putting it on the intranet will help).
- If you're savvy with the tools the developers are using, offer to help document the code itself. (This is often one of their most onerous chores, so they'll most likely welcome the assistance!)
- Create flowcharts and system diagrams created in Visio or some other charting/drawing app.
The above suggestions apply primarily to software/engineering environments. Maybe those working in manufacturing, medical, financial, or other industries would have different suggestions.
Anyway, these are some of the things that have worked for me.
---
Tom Campbell
tomcampbell -at- EUDORAMAIL -dot- COM
------------------------
"I try to leave out the parts that people skip."
--Elmore Leonard
------------------------
Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com
