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.
Summary: Reporting Structure in Large Corporations
Subject:Summary: Reporting Structure in Large Corporations From:"Petrick, Emily N" <Emily -dot- N -dot- Petrick -at- JCI -dot- COM> Date:Fri, 28 Mar 1997 11:47:41 -0500
Hi Listers!
Thanks VERY much to everyone who responded to my post a few weeks ago
about the Reporting Structure in Large Corporations. We received many
helpful and insightful responses.
People described many different reporting structures, with varied
levels of successes and failures.
The majority of people thought documentation as a function worked best
when allied with product development, instead of other areas, mostly
because of: the proximity to the development, the personal
relationships, the feedback, and that fact that documentation really
is part of the product, not separate from it. HOWEVER, we did hear
from people who have had success in other reporting structures, so
there are no absolutes here!
Also, the key factors to success seem to be:
1. Having a manager who knows documentation AND.....
2. Having a manager who is a GOOD MANAGER!
One without the other seems to signal disaster.
Other than that, people told many stories of the information wars -
people wanting to take control of documentation - and how it goes in
cycles from marketing to product development to training and back
again. Seems to be quite common.
Some other good points people brought up:
1. Focus on THE CONTENT - is it task-based, can it be repurposed? 2.
Work as closely as possible with the product life cycle and beta
testing, not only of the documentation itself, but the product. Work
early to improve the documentation(and the product). Don't view
documentation as an afterthought.
3. Treat documentation as an asset that has a great impact on the
bottom line.
Thanks again!!!
Emily Petrick
Johnson Controls, Inc.
Milwaukee, WI
Emily -dot- N -dot- Petrick -at- jci -dot- com
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
