RE: Hi-Tech Company Hasn't Used Tech Writers in Years (Long and V ERY Worth It)

[George Mena <George -dot- Mena -at- esstech -dot- com>]

Dear Anne Miller,

Many years ago, I worked for the Convair Division of General Dynamics in San
Diego on the USAF's Ground Launched Cruise Missile program, one of five
major weapons systems programs I've worked on during my career. I'm
responding to your TECHWR-L post so as to share some of my knowledge,
insights, and wisdom on military technical documentation with you and the
list.

Following are excerpts from your post and my responses to them:

Excerpt 1: 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).

Response 1: With any commercial high-tech company, this would be ludicrous
indeed. However, we're talking about General Dynamics here. More
specifically, we're talking about a division that develops avionics systems
for US and NATO military aviation purposes, as well as for use in space
exploration and high-orbit strategic defense purposes (read KH-11 type spy
satellites, the MILSTAR satellite system and other programs classified
higher than Top Secret by CIA and NSA at a minimum). As such, the issue of
knowing the reader audience is more than a little critical.

The contention that the documentation is "too good" may in fact be extremely
valid. Not many people are going to be involved in repairing and/or
maintaining these sophisticated avionics systems. Those who are probably
know the systems better than the folks who designed them. Documentation that
is truly too good can be a temptation for someone to copy it and give said
copies to a foreign power. Even though the Cold War has been over for
awhile, there are still those countries, including Bosnia-Herzegovina,
Serbia, Russia, Mainland China, and North Korea, who would love to learn how
some of our more sophisticated technologies work. Why? So that those
countries can develop effective electronic countermeasures systems (read
electronic jammers) to nullify our current strategic and tactical
advantages. 

Remember, during Operation Iraqi Freedom, one of the things we discovered
was that North Korea had sold GPS jammers to Saddam Hussein. The GPS
jammers, which, gratefully, didn't work (due in part to a combination of
lack of quality in the North Korean systems and a lack of technical
expertise by Saddam's Baathists), were acquired so that Saddam could have a
working solution to our GPS-targetable Joint Direct Attack Munitions
(JDAMs). The rest of the world knows these munitions as "smart bombs." These
munitions are more effective than the laser-guided munitions we used during
Desert Storm, precisely because they are satellite guided by our orbiting
GPS systems. These munitions today also comprise a large portion of the
aerial bombardment munitions available for US military combat operations.

Operations and maintenance manuals for those systems would decidedly be a
top priority for foreign intelligence services to acquire by any means
necessary, including blackmail, extortion, graft, and even murder by
assassination. I hope you have considered this possibility, especially when
you stop to consider that some of the people another country's security
service would target for compromising would in fact include technical
writers. Remember, technical writers have a unique access to the technical
information database being drawn upon to author the manuals. Getting a
technical writer working for a defense contractor to provide schematics of a
JDAM's guidance system would be a MAJOR technical information coup.

How major? Try on the scale of the Walker-Whitworth spy scandal of the
1980s, when war-winning significant information (our military message
encryption codes, and their upgrades for over 20 years!) was leaked to the
Russians by John Walker, John Walker Jr., and Jerry Whitworth. The Walkers
have already served their 20-year sentences for espionage crimes against the
United States. Jerry Whitworth, currently imprisoned at the Federal
penitentiary in Lompoc, CA, will die an old man in prison. That's what
happens when you get a 365-year sentence for conducting espionage against
the United States, which is exactly what he got for his acts of high
treason.

Excerpt 2: 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.

Response 2: This contention of yours is NOT true in the defense/aerospace
world at all, nor should it ever be. If anything, this statement leads me to
believe that you may in fact be in your very first defense/aerospace
technical writing position. If true, you need to know a few things:

* Tidbit A: As a technical writer in the defense/aerospace realm, YOU HAVE
NO ROLE AT ALL IN DETERMINING THE DELIVERABLES in terms of technical
documentation being supplied to the military customer. That was decided long
ago by the customer when General Dynamics was negotiating the Start Of Work
(SOW) and the Technical Manual Content Requirements (TMCR) following the
DoD's awarding of each of the contracts to GD-AIS. THIS IS EXCLUSIVELY THE
DOMAIN OF TOP LEVEL MANAGEMENT AT ANY MAJOR DEFENSE CONTRACTOR. You don't
have a "need to know" from a national security standpoint, end of story.

* Tidbit B: The technical program managers and chief engineers take the time
that you think they waste because they are directly responsible for the
development of the avionics systems in question. It's important to remember
how the defense contract award process works. First, you build a working
prototype when your company is trying to win the bid from DoD. Then, once
your company wins the contract award, your task is to build the product on
the scale specified in the contract itself.

* Tidbit C: It's also important to remember that technical program managers
and chief engineers alike can be -- and are -- held criminally responsible
under Federal law for exercising less than best commercial practices during
the project's development and product support life cycle. Since US taxpayer
money is being used to create a state-of-the-art avionics system for
national security purposes, the Defense Department has a very real vested
interest in making sure it gets the most bang for the taxpayer bucks being
spent. 

* Tidbit C1: One example involved the use of electronic components purchased
at Radio Shack when Rockwell was tasked with manufacturing the guidance
system for the MX ICBM program back in the 1980s. These components were
illegally used in the development process because the approval process for
military-grade electronic components was negatively impacting Rockwell's
ability to meet its delivery schedules. When the military-grade electronic
components finally arrived, the guidance system had been approved. The
components themselves were never used, and summarily discarded by Rockwell
at substantial cost to the US taxpayer. This ultimately led DoD to properly
charge Rockwell with very valid charges of defrauding the Federal
government. Heads did roll for that -- but probably not enough heads.

Excerpt 3: The wasted man-hours here are absolutely staggering. ...Although
I joined the company in 2001, I only began working in an official tech
writer capacity here earlier this year ...most of it continues to be done by
engineers and I am not remotely involved.

Response 3: The engineers are the people developing the product. Unless
you're an engineer, you have no business being involved in this process at
all.

Excerpt 4: When I tried to explain how it (FrameMaker) 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 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. ...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. 

Response 4: SCHEDULES ARE REAL. So is a concept you are probably unfamiliar
with: MILESTONE MONEY. When a defense contract is awarded, financial
incentives in the form of cash awards are incorporated into the contract as
a standard practice of doing business with the DoD. The idea is to award a
company for coming in ahead of schedule at key points in the system's
development process. If it works, and if it's delivered to the customer
ahead of the agreed-upon schedule, the contractor is awarded for the hard
work put into delivering that part of the project ahead of schedule. No
defense contractor can afford cost overruns, nor does the DoD enjoy
returning to the House and Senate Armed Services Committees in Congress to
ask for more money for the project being developed. That's the reality
behind the engineers, programmers, and program managers having political and
financial guns to their heads. That's also why these guys write their own
docs.

* Tidbit A: FrameMaker is NOT the industry standard for large documents in
the defense/aerospace world, contrary to your opinion. During the early
1980s, the DoD embarked on the Computer Aided Logistical Support (CALS)
Initiative as a solution to managing the largest database of technical
information in the world, namely the DoD technical information database for
everything in the US arsenal from, very literally, soup to nuts.  As part of
that process, a software program named the Interactive Authoring and Display
System (IADS) was developed at US taxpayer expense for US military technical
documentation purposes.

* Tidbit A1: Before IADS was developed, the defense/aerospace world used a
variety of publishing packages for document generation. The most notorious
was the Wang VS/OIS mainframe publishing software, which is clumsy at best,
yet still in use today by some companies. Other programs included Interleaf
and Intergraph. Others included SGML-compliant ArborText.  FrameMaker itself
didn't even emerge until the mid-1980s, and at first was restricted to the
Unix world, running under Steve Jobs's erstwhile NeXT Computer platform and
under today's Sun SparcStations. Adobe Acrobat came along a lot later. 

* Tidbit A1A: Since FrameMaker was restricted to the Unix world at that
time, most non-Unix end users could NOT open Frame-based documents for
viewing and printing. It made sense for defense contractors to not use
FrameMaker, because they were still in the middle of discovering the
personal computer, desktop publishing, and Microsoft Windows. Defense
contractors don't have unlimited budgets, contrary to what some people may
otherwise believe. Like many companies, they have to make intelligent
decisions on what they buy, how well "it" works, and how much they want to
pay for it.

* Tidbit A2: The IADS software offers a standardized method of publishing
for the defense/aerospace world.  Since the IADS software was developed with
US taxpayer money, it's also available as freeware for download from the US
Army's Redstone Arsenal in Anniston, Alabama at
https://iads.redstone.army.mil/. It's our software. Our tax dollars paid for
it. 

Excerpt 5: 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.

Response 5: You're dealing with a lifer who probably held the rank of
lieutenant colonel at a minimum. Such people are made commanding officers of
entire military units, some easily exceeding 200 men or more. He's not going
to listen to you on staffing issues, nor should you be asking him to do so.
If you were to act this way towards him in the military, you'd be facing
Article 15 hearing on insubordination to a superior officer and be sentenced
to, at a minimum, latrine cleaning for two weeks. 

This is one time you are better served taking orders and following them if
you intend to remain employed there. His job description probably explicitly
grants him the authority to do the things in which you improperly contend
you should be involved. Putting it simply, you're at the bottom end of the
chain of command, and he's above you, period. Get over it. In the end, your
current manager may ultimately decide that he'd like you to be involved in
the interviewing process, but he'll be the one to make that decision, not
you. Sorry to be blunt, but that's the reality of your situation.

Best Advice: Be part of the solution. Being part of the problem, especially
to the type of manager you now have, WILL get you fired.

Best Regards,

George Mena
Sr. Technical Writer
ESS Technology, Inc.
Fremont, CA 94538
e-mail: George -dot- Mena -at- esstech -dot- com

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

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.