Hi-Tech Company Hasn't Used Tech Writers in Years - Help!

[Anne -dot- Miller -at- gd-ais -dot- com]

Hello!

I (re)subscribed to this list today because I need help from my comrades out there in tech writing land. I have been doing tech writing off and on since 1986 so I am not new to the field. I have experience at a variety of companies. Without exception, my work has always been glowingly received so I guess I'm fairly decent as writers go. I've interviewed, hired, and trained junior and senior writers. I've produced huge doc sets in the usual minimal time frame. Despite all this, the current situation is overwhelming me and I need advice. I am stressed to the point where I actually was in the ER a few months back with stress-induced cardiac arrhythmia.

My situation is this. I work for a major defense contractor that employs many tech writers. I love the industry, I love the technology, some of the people are pretty cool as well. However, my specific section of the company has not used writers in many years. I am told that years ago an unnamed executive determined that our documents were "too good" and decided to remedy this situation by firing the entire tech pubs department. Since that time the engineers have been doing all their own writing (with the expected result - incredibly bad documentation).

There are numerous cases where Managers, Senior Managers, Directors, VPs, Chief Engineers, Senior Lead Engineers, and so on, have spent and continue to spend many of their highly paid hours on very poor documentation. The most recent example of this absurdity is the recently instituted Peer Review process which, at the moment, seems to involve a group of (usually very senior) people sitting around looking for critical program errors in documents that have never been touched by a writer. The bulk of the review time is spent in doing a bad job of what a writer could do much better and much more quickly. About 90% of their "findings" include things like typos and consistency that are listed right along with actual program problems related to legality, feasibility, compliance, and so on. In a similar vein we have Technical Program Managers spending hours and hours on such trivial tasks as fine tuning acronym lists and Chief Engineers insisting on manually numbering all their hea!
dings and graphics and refusing to let me auto number anything (in Word).

The wasted man-hours here are absolutely staggering. The number of high-level people doing a poor job of writing and editing is profoundly disturbing to me. The number of programmers and engineers writing docs rather than doing any actual programming or engineering never ceases to amaze me. Although I joined the company in 2001, I only began working in an official tech writer capacity here earlier this year - after extensive lobbying. Even then, it has been an uphill battle. Very few people here comprehend what it is that I do - they think I'm some kind of formatter who "pretties up" documents just before they go out the door - at least that tiny percentage of the documentation that ever crosses my desk in the first place - most of it continues to be done by engineers and I am not remotely involved.

In an effort to keep this somewhat brief let me present some of the specific problems:

FrameMaker (and general tools ignorance) - This company once used FrameMaker - the tool of choice for large doc sets and an old favorite of mine. My former manager here (the company has had numerous reorgs and I am on manager #4 here), despite the fact that he has no writing background and does not participate in producing documentation, determined that FrameMaker was an evil entity to be exterminated from the company. He went on a self-described FrameMaker rampage and personally made sure it is no longer used here. When I tried to explain how it is the industry standard for large docs, he told me he would fire me (he was mainly joking but the fact he mentioned it at all is shocking) if I pushed the issue. His reasons for hating FrameMaker were based in ignorance. His argument was that Frame is useless since no one can read the files without the expensive software. WRONG. I explained about PDFs. This was news to him since his impression was that PDFs were created only by sca!
nning in hardcopies.

This is a specific example of a larger problem here where the uninformed make the decisions and a huge emphasis is placed on the deliverable format. There is no understanding that the formats/tools used to create and maintain a document need not be the deliverable format; e.g., you don't need DreamWeaver to view something made with that tool. We are talking about a company with many brilliant people who publish original research, hold patents, and so on. However, general ignorance of appropriate tools for documentation and the role of the tech writer is widespread.

Role of the Tech Writer: Maybe I am wrong, but I think tech writers are part of the development team - along with the programmers and engineers. We sit in on the technical meetings and know the product or program as well as any of the other technical professionals. We provide input in areas such as usability and GUI design. We test the software (if it is a software product). We determine what documentation needs to be created and how it will be created and by whom. We write, we edit, we rewrite, and at the very end we publish somehow - hardcopy, PDF, Word, HTML, XML, etc.

One problem here is that tech writing is considered "tech pubs" with the emphasis on the very end of the program - getting stuff out the door. My current manager is very much in this vein. He is a logistician with 21 years in the Marines. He is not a writer - in fact his e-mails are barely literate. However, he has told me quite firmly that he does not want me involved in building the technical writing department and he has this strange idea that writers must be stovepiped - one per program and never the twain shall meet. He seems to think that there is no reason why a tech writer (me) would or should be remotely involved in, say, determining staffing requirements, writing reqs, reviewing resumes, and interviewing candidates.

At the moment we have a dozen or more hi tech programs, at least 500 or more programmers and engineers (many with PhDs) and me, the only full-time writer. There is also 1 contract writer who hopes to be full time quite soon. You would think I would be swamped with work. On the contrary, although things are getting busier and sometimes I am swamped, there have been many weeks, if not months, where I have roamed the hallways begging for scraps of work and have had to actively seek out bits of things to do. I think it is fair to say that in the two-plus years I've worked here, I have accomplished far less than I typically do in a normal tech writing job during the first month or two. What I do is very well received but there are still no processes in place whereby I can be made aware of what needs to be done. There is no list of the current programs (yes, some are classified but they could be listed in some way) or who does what on each program so there is no way to contact peo!
ple to determine the writing needs for a particular program.

This is far too long and I do apologize but I think you get an idea of the scale of this problem and I would welcome any and all suggestions as to how to go about handling this situation.

Thank you.

Anne Miller


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP FOR FRAMEMAKER TRIAL NOW AVAILABLE!

RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.  
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for 
competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4

---
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.