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: More on Validating documentation From:"CB Casper" <knowone -at- surfy -dot- net> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Tue, 26 Mar 2002 20:02:59 +0400
This is from a history as a Manufacturing Engineer,
a TW with a different label.
Engineering Design (design) = Developer
Mfg Engr (ME) = TW & make designs producible
first job (1978) - Design throws drawings over the wall.
ME converts into Mfg Specs and fabrication & assembly
documentation. Design gets an opportunity to review
Mfg procedures, but rarely does any review. The only
way to affect change was to convince the design people
that they came up with the innovation that I lead them
to come up with. It took years to convince them that
I had any value to offer. Industry standard practice.
Aerospace industry, building satellite launch & other
second job (1984) - Mfg Engr Development position. It
was part of my job to walk the design boards, offer
advice and prevent problems, and reduce costs. Wonderful
job, management support through and through. Just wish
the job had been in a location that wasn't irrational
for humans to live, so I left. Aerospace company building
small rockets and automotive turbochargers.
third job (1986) - Started out much like first job,
but over the years, the company matured and started to
realize that making Design and Mfg work together
produced better products. Through force, the design
and Mfg folks were made to work together, including
design review by fg, and Mfg plan review by Design.
Over time, this mellowed out to be a good relationship,
but it took management leadership to achieve.
Aerospace company building rocket engines & fighter
jet structural components.
<insert a few, non-TW type postions here>
current job (2001) - Acquired SW documentation TW
postion that encourages collaboration with the lab
folks. A challenge since I'm physically very distant
from them, but workable. Management actively encourages
collaboration with lab and support people.
Large high tech HW & SW company.
Summary, most companies have matured over the years,
and if they haven't figured out that active management to
encourage a good working relationship between developers
and TW's is a very good thing, they are dinosaurs.
So, in your experience, are relationships with developers
really as non-existent or dysfunctional as some threads on
TECHWR-L would suggest? Is there really no sense of
"we're all working together to make this overall product
as good as we can make it"?
If so, are _you_, as a tech writer, part of the solution,
or part of the problem, or both? Why?
PC Magazine gives RoboHelp Office 2002 five stars - a perfect score!
"The ultimate developer's tool for designing help systems. A product
no professional help designer should be without." Check out RoboHelp at http://www.ehelp.com/techwr
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.