Confessions Of An Aging Technical Writer


According to the Society For Technical Communication, technical writing is defined as ‘…the discipline of transforming complex information into usable content for products, processes and service.’

I remember when that definition was accurate. Those were the days when transforming meant something different than it does today. Back when media was a tool and not the message.

My first tech writing job was working for a savings and loan. It was 1977 and I got the job because my prospective employer liked an article of mine that had been published in a local literary journal. The article had nothing to do with banking or technical writing for that matter, but it was a published article with passing grammar and sentence construction and positive reviews by a few obscure specialists in the article’s field.

I knew nothing about the savings and loan business, but in my boss’ mind I could write, and that’s what mattered. Her logic was that good writing was the hard part, understanding savings and loans came second. She had a point, but its days were numbered.

I didn’t know it at the time, but 1978 marked the beginning of the end of transformative technical writing. The glory days of Haynes and Chilton auto shop books, intricate electrical diagramming by Radio Shack and IBM, and typewriter and stereo equipment repair manuals ended when the process of transforming information changed to hiding information.

The end began in Japan and Germany while I was tech writing for a hydraulic machine tool manufacturing company. The company made hydraulic presses and shears the size of a house, and sold them to international markets. They were arguably the biggest and the best in the business. ‘Spare no expense’ was a popular catch phrase when it came to product development, marketing and sales. The engineers were patient and honest with me and we worked together to explain every maintenance step, illustrate every part and identify every hazard. I was in tech pubs heaven. So what if the engineers used slide rules and I typed on an IBM Selectric typewriter. The electrical schematics might have been drawn by hand, along with the assembly drawings, but they were beautiful. Clueless to its significance at the time, I fiddled with a digital, hand-held calculator a friend gave me as a curiosity from Japan. The calculator’s manufacturer had a funny name. Casio.

Japan and Germany popped our comfortable analog bubble with computer aided design and automated manufacturing technology. Within two years they captured the hydraulic machine tool market with cheaper, more efficient products, sending me out on the street and my company to an unexpected grave. It was 1980 and all of us held our pink slips with dazed looks on our faces, wondering what the hell just happened.

Five years and a steep learning curve later, I resumed my tech writing career with another manufacturing company, this one made integrated circuit manufacturing equipment. Tech writing is tech writing, I told myself. So what if they used word processors instead of IBM Selectrics? What difference did it make if product design was done using a software platform called computer numeric control? I knew all about computers. I had a word processor at home. “Bring it on,” I said.

What I didn’t know when I took my seat in a sterile room full of technical writers was the engineers were no longer just down the hall, they didn’t know my name and they had no interest in documentation. Many of them barely knew enough English to qualify for a green card.

Innumerable corporate training classes repeated the mantra that computer-assisted anything was a vast improvement over what came before. The opportunities for increased output and efficiency were endless and management expected employee performance to increase proportionally. Timelines for product design, implementation and delivery squeezed tighter.

Technical publications may have advanced to word processors, but the end product was the same, ponderous books that took vast amounts of time to be printed, managed and maintained in warehouses. Production schedules for documentation were expected to stay in line with the new, product development schedules even though product engineering and documentation followed very different paths.

Engineers had the very latest productivity tools at their fingertips, but nobody had time. Everyone was supposed to share their work, but nobody shared their passwords.

Electronic schematics, essential for troubleshooting, where phased out of common-source databases so that nobody, except engineering, held the key to accessing their research. Then, in the name of efficiency, engineering implemented a new design process, ‘modules.’ Interchangeable modular components that were quick to design, quick to implement and quick to modify. Suddenly, all a machine’s parts became moving targets. Changes to a machine’s design were instantly dropped into the hands of manufacturing. Forward Thinking! we were told. Increased Customer Satisfaction! became the buzzword.

The ECO (engineering change order) program is a slow-moving, administrative function whereby all changes to a machine, no matter how small, are incorporated into a high-level plan that requires a formal review, an implementation schedule and sufficient notice to everyone affected by the change. In the name of customer satisfaction, modular engineering side-stepped the ECO, leaving everyone outside the engineering department in the dark.

The ECO program was essential for documentation. We needed the time it took to implement an engineering change to research and update the ponderous technical manuals. With allowable production time now set at near zero, the manuals sitting in warehouses became an anachronism and the customers, both internal and external, that depended on the manuals cried foul and blamed me.

I decided if you can’t beat ’em, join ’em and developed an HTML-based documentation process that resided within a machine’s software. Since there wasn’t any time to update whole books, we’d keep up with modular-based engineering by focusing on the module alone; a paragraph here, a drawing there, maybe a new chapter. The virtual documents would update in a matter of days instead of months. It wouldn’t be pretty at first, but the process had the potential to grow an interactive function whereby the machine’s software would bring up the appropriate maintenance or repair procedures on the operator’s control monitor. Failed parts would show up on a map, blinking red, or whatever. Sidebar documentation would identify the part, explain how to replace it and provide ordering information.

Virtual documents also solved the cleanroom issue.* Pollutants of 0.3 microns or larger, such as dust, airborne microbes and aerosol particles, adversely affects the integrated circuit (IC) manufacturing process. To protect the IC manufacturing environment, elaborate precautions are taken to ensure low pollutant levels, including, to name just a few, air intake filters, air-showers, gowning and training. Taking fibrous paper products, splashed with ink, into a cleanroom would be a serious breach of cleanroom protocol. Also, speaking from personal experience, consulting a paper manual while gowned is beyond impracticable, involving exiting the cleanroom, removing one’s gown, reading the manual and jotting notes on a cleanroom-certified tablet, re-gowning and showering before returning to the cleanroom. An alternative was essential. The answer was to get out of the Gutenberg mindset and eliminate paper entirely.

What could be better?

Turned out, a lot.

Besides customers, training was the biggest user of technical manuals and their biggest critic. The manuals were their textbooks, their lesson plans and the basis for their curriculum. Many thousands of dollars and man-hours went into developing their training classes and nobody was going to scrap it all and build a new curriculum that dovetailed with some hair-brained tech docs process. Trainers were engineers. Technical writers were glorified secretaries. Training didn’t deploy cleanrooms in their labs, and considered cleanroom protocol a customer issue. When I explained my project to recalcitrant training administrators, they responded; “Just do the manuals right!” I walked away disappointed but undeterred. “Don’t say I didn’t tell you so,” I said.

But my process also meant cutting corners. To keep within the production time restraints, down-slope research, such as adherence to OSHA and ISO guidelines, safety contingencies and compliance with local, state and federal regulations of all sorts, got short shrift. In the name of efficiency, I compromised professional standards and put the customer in harm’s way. I was no longer transforming information.

I had my back against the wall. Either continue publishing paper books and sink into semiconductor oblivion or convert to a digital process, thereby compromising industry standards and alienating training.

So I resorted to a typical management rationale. While presenting my plan to a committee of disinterested administrators, I argued that industry standards and training issues would be cleaned up in future revisions. They stared at their laptops while I made noises in front of PowerPoint slides and Excel spreadsheets. My strategy depended on upper management’s indifference to both training and documentation. In their minds, we were insignificant blips on the company’s balance sheet. An obligatory cost of doing business, nothing more.

As I expected, after the usual platitudes, nobody said no, so I hired a C+ programmer and we went to work transforming complex information into bits and bites that moved fast, but hid the truth.

I succeeded in launching a documentation website and a suite of lean, module-based informational packets that took the place of manuals. The company’s forward thinking customers gave me satisfied reviews and engineering even bought in to installing the info packets in the machines’ operating program. I called the project a success.

Training, meanwhile, howled in protest. They claimed they were blind-sided and, while their out-dated lesson plans and textbooks became useless, they demanded my digital boondoggle be suspended.

A year of hostility and stonewalling later, Training convinced my manager to hire an outside consultant for me to groom as my replacement.

I was relieved. With the ghost of transformative manuals skulking over my shoulder, and the specter of legal action for missing and misleading information staring me in the face, it was high time I bid adieu to my tech writing career. I left at the apex of a booming economy, when a middle manager could still leave Silicon Valley with some money in his/her pocket. The lean recession years started the next day.

* * *
*Unique to the semiconductor manufacturing and similar industries. Not associated with ‘cleanroom design,’ defined as the process of copying a design by reverse-engineering and recreating it as a new product without infringing on any of the copyrights associated with the original product.

Published by James W. White

fiction writer

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: