You Are Here.
Jump to our supported pages.
Great Moments
in
Technical
Writing
- Introduction -
Visit to the FamilyChristmasOnline site.
Return to Family Garden Trains Home page
Visit our collection of resources for collecting, restoring, and making your own cardboard Christmas houses. Tour an Archive of George Nelson's Christmas tree light museum, circa 2008
Visit the Internet's largest resource on choosing and displaying Christmas trains. Best-loved railroad songs and the stories behind them
Return to Big Indoor Trains Home page
Resources for acoustic music, CCM, Worship, Bible study, and Christian thinking
Acoustic instruments, Folk, Americana, stories and songs about the National Road
Click

Written by Paul D. Race for Breakthrough Communications™




















































































In 1980, on the strength of a Bachelor's Degree in English and a couple years' experience teaching teenagers how to program their Radio Shack TRS-80, I got my first job as a technical writer, for the company that more-or-less invented Technical Writing as a career.

For the next 30-odd years, I made my living as a writer, editor, or technical communicator. Sometimes my career seemed as solid as rock; sometimes it felt as risky as crossing the Ohio River by jumping from ice flow to ice flow. Though most of my experience was in computer documentation, I also got to write about history and literature, and hundreds of other topics.

Now that I'm within a few years of putting the day job out to pasture, I can't help thinking about all the great and goofy experience I've had over the years. If you're a career technical writer with a few miles behind you, you will be able to relate. If you're looking forward to a career in technical writing, you may find this informative. If you think that office shenanigans only happen on television sitcoms, you'll find it incredible. If you're a critic, you'll find it self-indulgent. But memoirs always are. What bothers me is when history books or technical manuals are self-indulgent.

But whoever you are, hopefully you'll find it entertaining.

The contents are more-or-less chronological, starting in May, 1980 and going up to present day, although not all periods are covered equally. Although the sections are divided largely by the state of technical writing during the events being described, they're really about what it was like to work in the industry at that time.

If you can relate to any of what I've written, e-mail me and let me know. If you have something to add, I plan on putting a reader response section on every page eventually.

In the meantime, enjoy!

I won't say who it was, but cash registers were involved. Mechanical cash registers, that were sold all over the world, and occasionally needed repair. They were so complex that it wasn't any stretch to call their repairmen "field engineers." Sometimes an FE would come across a problem that had never been encountered before. After he figured out how to fix it, he would write up a report that would be printed up and sent to every office in every country where that particular model had been sold.

When a field engineer who showed particular aptitude for writing was burning out in the field, they would occasionally bring him in to a factory to assist in writing the user and repair manuals.

Field Engineers as Writers

In the late 1960s and early 1970s, as the company finally made the bumpy transition from mechanical to electronic cash registers, they knew they would need their field engineers more than ever. But for a while there was nowhere near enough work for them to do.

Not wanting to lose them to other companies, they brought the best Field Engineers into their headquarters. Based on their albeit spotty writing experience, the company changed their job title to "technical writer."

Field Engineers as Managers of Writers

For over a decade the manager of all these new "technical writers" was a former field engineer himself. By the time I was hired, he was nearing the end of his career, holding a sort of "emeritus" position that both rewarded his years of diligent company service and pretty much kept him out of trouble. So my exposure to him was mostly through "bulletins" he would publish whenever he deemed that some crisis related to technical communication deserved his attention.

Like Saint John, who always referred to himself in the third person, this well-meaning manager had learned somewhere that it was bad to use "I" in a written document. So he called himself "the writer." As in "It has come to the writer's attention that . . . ." That sentence is clichéd and wordy, but at least it's understandable.

Unfortunately his bulletins also talked about writers, and he didn't like using second person, either. So when he would say "the writer must do such and such" you just about had to draw a flowchart to figure out whether he was talking about himself or you.

For many years after that, most of the folks who managed technical writers had started their career with a two year degree in electrical engineering (or less) and a screwdriver in their hands. Fortunately, most of them realized that the college-degreed folks they had working for them knew more about writing than they did, and gave them free rein over the organization and syntax of the documents they wrote.

Still, as late as 1984, I was working for a field engineer who thought stuffy writing sounded "more professional" than straightforward text, and who rated our work on a "pages-per-day" metric that never took into account that the work we were doing required vastly different levels of skill and technical knowledge.

In-House Training

Needless to say, changing a person's title from "field engineer" to "technical writer" does not magically endow him or her with the requisite skills to do the new job effectively. Quite predictably, the first generation of FEs-turned-"writers," supervised by FEs-turned-"writing-managers," tended to turn out disorganized technobabble that only made sense to people that shared their vocabulary and experience. When the company started developing software to bundle with their new mainframe computers, the lack of training became even more obvious.

Finally, the company realized some retraining was necessary, and engaged a professionally-trained writer we'll call "Eddy" to write a "how to write" handbook for the rest of the technical writers to use. That handbook, of which I still have a copy, addressed common problems and explained straightforward syntax better than any book I have seen before or since. Later it morphed into a series of college textbooks on technical writing that helped lay the groundwork for many disciplines and practices that are still taught (if not always followed) today. I have often wished that the original was still in print, as it actually addressed writing in general and wasn't skewed toward technical writing topics. I'd make it a requirement for any course I taught, period.

Like Julia Child (co-author of Mastering the Art of French Cooking and the only one you have ever heard of), Eddy has always shared credit with two other writers, but it wasn't hard to figure out who supplied all of the most telling examples. My favorite, in a section on misplaced modifiers, was "Rolling around in the bottom of the drawer, I found the missing ball bearings."

Eddy also trained writers and writing managers through a series of in-house programs. By the time I hired on, Eddy was less hands-on, although I did have the chance to sit through two of his seminars on managing documentation projects. I always appreciated his wisdom, his gentle humor, and especially his "war stories."

Eventually, our company's writing groups developed a culture of professional technical writing that was second-to-none by the time upper management decided to break up all the writing groups in the mid-1980s, unfortunately sacrificing what we now call "tribal knowledge."

Where I Come In

Enter me, in 1980, hired to work for a former field engineer who, in turn was working for a former field engineer who, in turn, reported to a former cash register sales manager. Most of my coworkers had BAs, though not all in English. At the time, I had a Bachelor of Arts in English, a writing-intensive degree, to be sure. But none of my professors had ever helped me improve my writing since, frankly, high school, where Mrs. Robinson had drilled principles into our heads that I had coasted on for the next four years.

My supervisor and manager both realized I was a better writer than they were and left me to do my job as I saw fit. My immediate coworkers got the same treatment. Ironically, I realized later that they were allowing us all to write mediocre manuals in which each chapter sounded like it was written by a different person, because it was. In retrospect, there were few standards beyond template requirements and not using the term "execute" to describe starting a program. (Our country had customers all over the world, and translators almost always interpreted the word "execute" as "kill," the exact opposite of what the customer needed to do.")

Technical Writing in the Stone Age

Back in those days, our software's "user interface" was a screen of ascii text with blanks or boxes where the operator had to type information. There were literally thousands of screens, and no help systems. So our "user documents" defined each screen field by field by field by field. If the next screen used most of the same fields, they would be redefined on the next page of the document. On a big system, the "user manual" could easily be ten thousand pages long!

As if that wasn't cumbersome enough, many of our clients only had one "user terminal" per mainframe, so the people doing computer input didn't have the luxury of sitting at the screen working on one record at a time. For those clients, we had to create "worksheets" that the customer employees would use to collect the data that the operator would eventually put into the system.

Before 1983, we didn't have computers or terminals either, so everything we did was typed or handwritten, including the "tag names" of each paragraph type (H1, H2, BT, etc.). We then hand-carried the "hard copy" to a typesetting department in another building, a chapter at a time. After the typesetters had done their best, we'd review the galleys. Those always contained manifold mistakes, usually - but not always - caused either by our bad handwriting or by the person typing our copy into the typesetter. We usually had "one shot" to get all the corrections into the system before the "camera-ready" copy was produced. After all, our department was being charged per page by the typesetting department, and multiple turnarounds of big documents cost real money.

In the late 1970s, the company had a huge pool of writers that the writing manager would assign to various software projects. A year or so before I was hired, the company had split the writing department into three departments according to "vocation": retail, manufacturing, and financial (banking)

When I was hired into the financial division, I went into a pool of writers with a single manager who would assign them to various projects as needed. Then, between 1982 and 1983, our department was split up so that each application development project had its own writer(s). The short-term "down-side" was that software development managers never consider documentation a priority, never consider writing ability as a useful job skill, and more often than not find ways to reassign the writers to tasks they consider worthwhile, like testing. So writers wind up not being given time to do their "real job" and working at tasks they're not trained to do and generally bored and frustrated by. The "long-term" downside was that, as more and more writers were assimilated into the individual development groups, and old-timers were replaced by new hires, the company as a whole lost its commitment to world-class documentation, and - eventually - even a basic understanding of what that was.

The fellows who had managed the original big department attempted to prove they were still important by specifying software requirements and documentation standards that nobody used, and by funding internal "research" projects that never benefitted the writers in the trenches.

That said, one of the "breakouts" actually helped me - I found myself assigned to work for a coworker who had been trained to write when Eddy's influence on the corporation was at its highest. (Today, we would say that she was "old school," even though she was not much older than I.)

Under her guidance, I learned to write the way I should have been writing all along,, using most precise, concise, straightforward sentences possible. Always. Passive voice - gone, except where it could not reasonably be avoided. All other inverted syntax - gone. Using more than one wording to describe identical tasks - gone. All those cutesy, self-indulgent tricks that some of my coworkers had actually admired - gone. After six months of her tutelage, my writing - all of my writing - had improved by leaps and bounds.

I've done all kinds of writing since, including academic, K-12 textbook, technical, journalism, and fiction. I've also been brutally overedited by supervisors and senior editors who insisted on imposing their indefensible personal quirks on my prose. But all real success I've had at ANY kind of prose writing, I credit largely to that six months of my life.

Technical Writing in the Bronze Age

Some time around 1983, our department was split up again and I became the uncompensated supervisor of six other writers. We each received primitive "personal computers" that cost as much as a good used car. To save money on software, the company used P-system, an operating system that had been developed to support the Pascal programming language. Since no word processing software had been developed for P-system, we used the P-system text editor to input everything, including the tag names for each paragraph.

At the time, I kept in touch with technical writers in other companies, and I saw the tools they were using. The first IBM personal computers had come out, and they supported programs like WordStar that would have saved us countless hours a week just on inputting the text, even if we still had to send it to the typesetters for the "fancy" copy. When I told our manager (the third FE-turned technical writing manager I had worked for) what my friends were doing in other departments and companies, he accused me of lying to him and refused to speak to me about it.

Not long after, we got our first "laser printer," a text-only printer based on a Canon chassis. Again, I saw what folks in other departments were doing with HP printers that used exactly the same Canon chassis but also had image-processing software built in. I brought samples of professional-looking pages - formatting, graphics, and all - to my manager and explained how much money we'd save in typesetting alone if we just adopted the same tools all the other departments and companies were using.

A few years later, I realized one reason why the manager was so reluctant to get us the tools we needed - the company accountants were more-or-less allergic to capital investments. You could spend a half a million dollars a year on internal typesetting charges, as long as you accumulated the charges $50 at a time. But if you tried to buy a $500 laser printer or a $100 software package, the request had to go all the way to your division's vice president. The nominal capital investments I was requesting would have pushed our productivity "through the roof" by 80's standards. But developing a culture of rejection saved the accountants having to depreciate those investments over a five year period, so it "worked for them." Too bad that it cost the company tens of millions that I'm aware of on typesetting costs alone.

Back in 1984, though, "desktop publishing" and "computer graphics" were in their infancy. When I brought my manager proof that you really could use PCs and laser printers to produce "camera-ready" pages, he accused me of "making stuff up."

One of the funniest things (in retrospect) that ever occurred to me in that department was the day the manager called me into a private meeting to complain about the way I was administrating the project. He had two documents in front of him - one I had written, and one that one of my "reports" had written.

Mine defined a ridiculously complicated process for installing our multi-million-dollar mainframe system, importing up to a million pre-existing user accounts, and testing the result before going live. It was well-organized, concise, straightforward, and written at an eight grade level (never assume that computer engineers or service people read at a college level). On top of that, it had already been used successfully in two beta sites.

"Fred's" document described how to enter a customer name and address into the system. It was verbose, unnecessarily complicated, and - frankly - gave the impression that you'd need a rocket scientist to enter customer information into the system.

I had talked to "Fred" about his obtuse writing style, but he was retired from the military on a full pension, he didn't really didn't need the job, and he had let my manager know that every time I tried to get him to write like a professional instead of a college sophomore trying to sound impressive.

So my first response to being called into a meeting was that the manager had finally noticed Fred's verbose abominations and was wondering why I hadn't busted the guy's chops by now.

To my surprise, the manager asked me why I was documenting all the "easy" tasks and making Fred document all the hard ones. I explained that, ordinarily most people would consider installing a multi-million-dollar computer system harder than entering customer information.

"That can't be," he said, "Look all this." And he ran his finger down Fred's page, in awe of all the apparently complex content. It took several minutes for me to get him to admit that the installation document might have been harder to write and to get right, than the customer information screen page, which only required getting a printout of the screen and stating the obvious: "Enter the customer's last name in the 'Last Name' field." (As a side note, that's the sort of sentence that once inspired Tina the technical writer in Dilbert to add, "But if you're too dumb to know that, userboy, you shouldn't be using this system anyway!")

My manager still wasn't satisfied, though - there was something about our conflicting writing styles that still bothered him. Finally he admitted that I "might" be right about taking the hard jobs myself and giving Fred the easy ones. "But," he added, "When I read Fred's stuff it just sounds more like technical writing!" Sadly, I knew just what he meant.

About the same time a new hire who dressed provocatively and was obviously gunning for my (uncompensated) supervisory position started spending a lot of time in closed-door meetings with the manager.

To his credit, the manager gave me a "heads-up" about his intention to replace me as supervisor and actually helped me find a better position in another department.

At the time, the whole project was on the verge of collapse, since that fellow wasn't the only poor manager in the division, so he didn't have to tell me twice.

Technical Writing in the Iron Age

By the time I landed in another position, I was no longer reporting directly to a "writing manager;" rather I was reporting to the head of the entire software development project. The "up-side" to that was that he didn't second-guess me every time I tried to get my writing projects out of the 1950s, but the "down-side" was that, to him, software developers walked on water and documentation developers were glorified secretaries. I was allowed to have a beat-up old eight-bit PC that one of the software engineers had "outgrown." Later on, when the engineers all got 32 bit machines, I was given a 16-bit machine that I could actually work on without having to wait several minutes for the screen to refresh every time I moved a paragraph.

For the first several months on the project I was mostly planning our "family of documentation and training projects," since the project was new. But now that I was responsible for the "final output" of the documentation, I started looking seriously at desktop publishing as a way of avoiding countless hours of shuffling documents to the typesetter, reviewing gallies, etc., not to mention avoiding all of the cross-charges.

Unfortunately, our company's typesetting department had been merged into the "Information Product Development" department by then. And, since all of the writers had been split out into development groups, the manager had amost nothing else to manage. So he did everything he could to make it seem as if his typesetting department was still critical to the company's future.

He proactively deluged all of the managers in the company with "white papers" explaining that "desktop publishing" was a fraud, that it never delivered on its promises, and that it wouldn't last. At the same time, he bought a 600dpi laser printer and started developing an in-house SGML-interpretation software system that would hopefully replace the paper-tape system-based system that they has been using.

About that time the company went from WordStar to WordPerfect, which was easier for clueless wonders, non-writers, and non-typists to use when writing business letters. Still, I could do most of what I needed to do many times faster in Wordstar, so I secretly continued to use that until I was forced to change.

My new department also had a Hewlett Packard LaserJet that had the graphic-processing software installed (some early version of PCL). So I occasionally experimented with trying to make WordStar (and, reluctantly WordPerfect) documents look like our typeset manuals. I could get close, but it was cumbersome.

I learned that another department in the company (located in another town, so they were slightly insulated) was already using Ventura Publisher with a laser printer. Once their documents were printed on an offset press, they were nearly identical to the typeset equivalents.

I explained to my manager that I could probably save him $200,000 or more a year if he would let me buy a faster computer, a desktop publishing system, and a faster laser printer. He, in turn, did the "responsible thing" and asked the manager of the "Information Products Division" what he thought about that approach. Of course he got an earful. The inhouse system wasn't ready yet, but it would be soon, and in the meantime, we were risking the good name of the corporation if we released documentation that didn't look like we had spent a fortune getting it typeset.

At the time I had one "report," and I could tell that the project was going to be huge. Adding typesetting iterations to the work ahead of us would be overwhelming. Finally, I "bit the bullet" and bought a copy of Ventura Publisher with my own money to try it out (several hundred dollars at the time, equivalent to over a thousand in today's dollars).

Over the next few weeks, I figured out how to make Ventura Publisher work exactly like the "Information Product Development" department's half-million dollar system, except that the latter was still full of bugs. Like today's HTML, all of the words were stored in a flat "text" file along with tag names like @H1=, @H2=, @BT=, and so on. All images were stored in separate image files and plugged into place as needed by the WYSWIG and printing features. To this day, I prefer this system to the "user-friendly" systems that make the graphic part of the file and require you to remove it and plug it back in whenever you need to make a minor update.

I also learned that "prepping" a file from a text editor, WordStar, or WordPerfect to go into Ventura Publisher was exactly the same as "prepping" the file to go itno the IPD's typesetting sytem, except that the tag names were formatted a little differently (something like @H1@=, @H2@= and @BT@=, as I recall - the point was that, not only were the tag names the same, the codes were almost identical).

By then the IPD's non-working home-grown typesetter system was still many months from completion - if it would ever by completed - and any number of writing groups had taken to sending their typesetting to outside contractors. One guy charged $17 a page for the service; he was making six digits from one division alone. I have to admit that every time he drove his expensive sports car onto the grounds to pick up another packet from the company, I was gritting my teeth.

Since my early experience with desktop publishing was so encouraging, I contacted the IPD again. I suggested that they could keep the various writing groups from sending millions outside the corporation every year, simply by bringing Ventura Publisher "in house," and developing templates and procedures that we could use until the "real system" was working.

In response, I was told that the IPD would refuse to print or distribute anything I ever did on Ventura Publisher, because it would never be "the same" as "the real thing." For one thing, the IPD used Plantin and Gil Sans in all of their publications, and our laser printer couldn't print those fonts.

In those days, buying a new digital font was a real investment. But I spent real money to get Plantin and Gil Sans from the Monotype corporation.

Then I went to work in earnest, exactly replicating the "official" corporate templates for all kinds of publications. I showed my manager what I had accomplished, then put in a requisition for two 32-bit computers and for reimbursement for the software and fonts I had already bought. My manager didn't even really know what IPD was, so when he saw how much money I'd be saving him, he went along.

When the new computers arrived, I trained my "report" on Ventura, and bypassed corporate distribution by having a local printer print and mail out the manuals, at another huge savings.

By the time we had done two releases of the software, my single "report" and I had produced just as much documentation as seven of us had produced in the same amount of time on the earlier project. And we did it for about 2% of the total cost (counting salaries). I was sure that the company would see the value of my contribution and reward me somehow.

The assistant vice president in charge of our division heard about our success and asked if I would box up my Ventura release disks and send them to him for him to "check out." I complied, hoping that this meant I was on his radar, or on his "good side" at least. What I didn't know at the time was that he was being forced to resign for alleged sexual harrasment, and my software was just one of countless "souvenirs" he planned to take with him when he left. Gotta love 'em!

Not that it mattered. A few months later, the mainframe that our software project ran on was discontinued, and I was looking for work again.

Technical Writing in the Dark Ages

The first place I interviewed was one of the few remaining technical writing departments in our company. They were still sending their typesetting out at an exorbitant cost, easily spending four times my salary every year. "Here's how I can pay for myself and then some," I said, and walked the hiring manager through my recent experiences. I had even "dummied up" a Ventura Publisher version of one of the hiring manager's own typeset documents.

He seemed to barely be paying attention. When I had done my "spiel," he explained that IPD had already "beat him over the head" about desktop publishing, that IPD's new system was going to be available any year now, and that, at any rate, anybody could easily see the quality difference between a document produced on a 600dpi typesetter and a document produced on a 600dpi laser printer. Actually, when he looked at my samples, he couldn't tell which was which, but he was sure there was a difference, because the IPD had told him there would be.

I didn't get that job. A year later, I heard that he had earned a substantial bonus by saving the company a quarter of a million dollars on typesetting costs. How did he do it, you ask? He came up with the brilliant, original idea of using Ventura Publisher and a 600dpi laser printer to bring his typesetting "in house." Ya gotta love 'em.

In the meantime, I landed in the marketing department of a division that sold PCs and UNIX computers to resellers. In that group, most of what we wrote was for internal distribution only, so there was only a simple template to use. Interestingly enough, we were required to use Ami Pro for our word processing, even though most of us had Microsoft Word on our computers - one of many self-defeating petty feuds with Microsoft I've witnessed in my career.

As a plus, one of the fellows in the department was responsible for testing each new PC to make certain it ran all of the standard applications. So I had a chance to get up to speed on the early-1990s versions of all the "high-end" graphics and desktop publishing applications. I didn't use them for production, of course - that would have been as unethical as "borrowing" an expensive software package just before you left the company.

My job, technically, wasn't writing as much as it was coming up with creative new ways to market our computers to wholesalers and other retailers. We were supposed to come up with all the ideas out of thin air. At the same time, I had inherited a file cabinet full of competitors' material we weren't supposed to have, and my manager used to suggest that I go through that to come up with "original ideas."

As a result of familiarizing myself with the competition, I realized that nearly every time one of my coworkers would announce a "new" marketing program, to the kudos of our manager and his director, I would recognize a point-for-point parallels with some competitor's program. In one case, the marketeer had gotten hold of a Word file describing the competitor's program, done a "search and replace" of the competitors' name with our company name, and presented it as his own work.

Frankly, the place was such a pressure-cooker, I can almost understand why some of those shenanigans occurred - there's nothing like a crisis-junkie manager forcing you to spend 60-80 hours a week at the office for no real reason but his own ego, to make any real creative juices you ever had dry up for good.

People often ask me why I don't find comedies about obnoxious bosses in the workplace funny. Now you know.

For my part, I did come up with a few original programs, one of which proved more useful in the "real world" than anything else I saw produced that year.

War story alert! After my albeit minor successes, I was ordered to come up with a complex program that other people had failed to accomplish. It would substantially help our resellers and give us an edge in the marketplace. But it would also require the "buy in" of several other departments that had no reason to give us what we needed. And that was where the marketeers before me had failed.

After months of negotiations with no leverage but my continued, good-natured "nudging" and a few minor "trade-offs" that I could influence, I finally got the buy-ins I needed, signatures and all. The program needed only the Assistant Vice President's signature to be implemented.

Before that could happen, a new director took over our division. "Eugene" (not his real name) liked my proposal. He liked it a lot. In fact he liked it enough to change the name on the front page from my name to his own, and to start promoting it as "his program." This wasn't the first or the last time this sort of thing has happened during my career. Conventional wisdom is to "close your eyes and think of Christmas," and to expect the idea-stealing supervisor to repay the favor at some time in the future. As hard as it may be to believe, in my experience, most of them do - the smart ones have figured out that it's a good idea to reward employees that make them look good. Sadly, though, Eugene appropriated my proposal without even bothering to read it all the way through.

Eugene scheduled a meeting with the AVP whose signature would be required, made up his own Powerpoint presentation to replace mine, and declined my offer to look over the materials he'd be presenting to be certain he hadn't missed anything (I said it nicer than that).

Finally the meeting day came, and the "Eugene" went through his presentation smoothly and convincingly. Then the AVP asked him a simple question and Eugene betrayed a humiliating ignorance of the most basic details of the program he had just promoted as "his own." He embarrassed not only himself but everyone in the room, although that didn't keep him from giving me a "dirty look" on the way out.

Afterword, my manager told me that I had "let Eugene down, big, time," and it might be a good idea for me to start circulating my resume. I didn't need to be told twice.

Gotta love 'em!

Technical Writing in the Industrial Revolution

Still in the same company, I landed in a customer support organization chartered with writing procedures for our systems analysts to use when putting together proposals or providing on-site services for customers. Most of my work there involved planning and installing voice and or computer networks, a relatively new field for me.

For example, we found a software program that would evaluate whether a client's networking infrastructure would survive Y2K, then charged a regional phone company to "vet" their entire infrastructure. An engineer did the technical research, I wrote up the procedure, and the company grossed about half a million dollars for a few weeks' work.

My "crowning achievement" a the time was a workbook and interview guide that even a relative "newbie" to the field could use to evaluate a customer's LAN and WAN requirements and propose an effective solution, usually using Cisco routers. I was proud that we had "rigor" to the process. After you'd worked through the workbook, you would have the "textbook solution," not only to the customer's perceived needs, but to the real needs you recognized as you were meeting with the customer and touring the site(s). If the customer still preferred another approach (say, Novell over MS or vice versa), we could deliver it, of course, but there was no way the customer could claim we had failed to do "due diligence."

The year our project came out, and the year after that, our company sold and installed over half of the Cisco routers installed outside of North America. I was not only starting to feel good about my work again, but I was most of the way to earning my Cisco certification.

Our manager was so pleased with our successes that he approved my request for tuition reimbursement to complete an MA. I took lots of graduate business courses (learning, among other things, why so many of our corporate accountants would rather waste millions they could expense than spend hundreds they would have to depreciate). I was also able to take enough English courses to complete an MA in Composition and Rhetoric.

Then the company split up into three separate companies, and our division was gutted. Eighty-five technical writers out of a hundred were thrown at once into a relatively small market. Judging by the writers they kept, the only way I could have saved my job would have been by getting pregnant right before the layoff notices came out.

To add insult to injury, IPD, with whom I'd been bumping heads off and on for ten years, talked the corporation into establishing policies that would make it impossible for any of us to be hired back as contractors unless we went through a certain agency. Which agency? The one that had just been started by the same manager who had decided which writers to lay off, and who had apparently worked out all of the details with IPD ahead of time. Gotta love 'em!

After fifteen years of service, and several projects that had either saved or made the company millions, I was "on the street." On the other hand, I had just completed a master's degree, and was one course away from Cisco certification, if I wanted to pursue that. So things didn't look as bad as they could have.

Technical Writing in the Information Age

There's nothing like trying to get an interview for a job in a small market and learning that eighty of your former coworkers have been there ahead of you.

Add to that the fact that certain rules that apply to you don't seem to apply to anyone else. In spite of the new requirements that were supposed to keep our former supervisors from using us as consultants, one of the remaining managers seemed to have no trouble keeping several close friends busy.

In fact, one manager paid his laid-off-friends their "layoff bonus," then hired them back as consultants, and when things got better, hired them back as employees again, for more money than they had earned before. Gotta love 'em.

In the meantime, I did a little bit of consulting for a local company. Then one of my former coworkers contacted me and begged me to come work for him on contract. "Ron" (not his real name) had a project to finish and I was the only writer he knew who remotely understod the technologies involved.

Ron and I both spent hours on the phone with "gatekeepers" (Consultant Policy Administrators) trying to figure out how some managers' favorites could come back to work the next week, and I was not allowed back unless I jumped through extraordinary hoops.

One hurdle was that I couldn't come back as myself - I had to be represented by "a company." So I started a company - Breakthrough Communications(tm) - by filling out a DBA form with the state of Ohio and opening a business checking account in the company's name. (I also started the BTComm.com web page, using basic HTML skills I had picked up the last year on the job.)

Then the gatekeepers decided that my "sole proprietorship" wasn't enough. I had to work for a corporation. I asked the gatekeeper I had been "working with" if she knew the corporate structure of every janitorial, repair, and catering service they used. She admitted that she did not - apparently the new requirement only applied to former employees who were looking for work as technical writers. Finally, she admitted that the requirement was unenforceable.

But then she told me that I couldn't contract with the company unless I took out a million-dollar "malpractice" insurance policy protecting the corporation in case I wrote something with mistakes or plagiarism in it. That kind of insurance policy is insanely expensive for individuals. Our former manager's new and "approved" company could spend a thousand dollars a month and cover all of his writers. But for me to spend a thousand dollars a month on the off chance of getting steady work from the corporation would have been prohibitive. I found other local work for a few more weeks, while Ron kept pushing from his end.

Again after several phone calls from Ron and me, the gatekeeper had to admit that the new insurance requirement applied only to former employees who were also technical writers - it didn't even apply to contract trainers, programmers, or marketing writers, who were just as likely to produce mistakes or plagiarism as we were. Eventually, one of my former coworkers threatened to sue for unfair hiring practices, and that requirement vanished as well.

Sixteen years after the fact, all of these petty barriers to former employees delivering services that the company still needed seem unbelievable. But at the time, the twenty or so of my former colleagues with whom I stayed in touch were also being forced through exactly the same hoops. It was increasingly obvious that these barriers weren't there to protect the company - they were being erected by friends of our former manager to help him protect his monopoly. By now, I had no intention of working for the fellow if he'd asked me.

And sometimes there didn't seem any reason to - every barrier fell with a few weeks after its erection. But no matter what Ron and I did, or who we talked to, or how many hoops we jumped through, we still couldn't get final signoff from the gatekeeper for me to work on Ron's project - there was always one more hurdle that hadn't existed a week before.

Finally, frustrated beyond measure, Ron said, "Tell you what, you give me a couple days' work, and submit an invoice and I'll send it through and see what happens." The invoice was approved and paid with no resistance on the part of accounting, who - after all - didn't mind reporting expenses. And my consulting career actually started looking like a possibility.

As I read back over the last few paragraphs, I have to admit, that, all things considered, I got off "easy," compared to a number of my friends. As each barrier fell, I reported back to everyone on my "nice" list what I had discovered. A few folks felt informed and encouraged enough to jump through the same hoops I had, and eventually got into the system and started working again. But there were quite a few others who didn't have the emotional or financial resilience to keep "treading water" until things worked out.

Between the day I registered my DBA with the state of Ohio and the day I actually started working on contract, several people heard that I had "started a business" and asked me to represent them to the corporation the same way our former manager was representing those who had signed up with him. That could have been profitable for me, I suppose, but by then, I was hanging by a thread as well, and the only thing I could tell them was that I'd keep them informed of every step and in mind if I heard of anything at all.

By the time the "dust settled," some of them had got back "in" as consultants, some of them had found work elsewhere, a few had taken worse-paying jobs in other fields, and a few had just dropped "off the map." Back in 1995 there weren't as many ways to keep in touch as there are now, I'm afraid.

Later I learned, that one talented and focused writer in his early sixties had been planning to work a few more years, but finally gave up and started taking Social Security - that and drawing on his underfunded company pension were his only dependable sources of income. He and many others I can bring to mind were a true loss to the industry, and I regret that those of us who eventually "landed on their feet" couldn't have done more.

I do have to confess that my "nice" list got shorter as friends who asked for and received my help with one thing or another stopped taking my calls once they had landed somewhere. On the other hand, I can almost understand why some of that happened - I've been a "new hire" in situations where bringing in a distraught, but qualified friend would have made my new boss question his or her wisdom in hiring me - not unlike the would-be rescuer being drowned by a panicked person he was trying to save. And by the time any appreciable number of us started landing "on our feet," we were all pretty distraught, and, if nothing else, emotionally unpredictable.

At any rate, several of us did find our way back into the company as consultants. As contracts ran out and new contracts started, I made sure to look out for folks who had looked out for me. One interesting event occurred during that period. I was recruited to help "finish" a job that one of our former coworkers had been "working on" for eighteen months. The client figured it would be a two-man job, so I brought in a friend who was a great writer and had been helpful to me. The contract was to be for ten weeks at the most, since "Joe" (not his real name) had almost everything done and just needed our help getting it "out the door."

The project was to document a family of services that the company would sell to its customers - not unlike the work I'd done on LAN and WAN design. Although we were both charging what was then a standard fee for senior tech writing consultants, the client kept griping that we cost "so much." It turned out that he was comparing our fee to Joe's. Joe was charging a third of what we were! His low-balling had certainly kept him employed for the last eighteen months, so maybe that was all he needed.

The client was also nervous about bringing in people who would be working at home. He literally wanted us to call and tell him every time we went to the bathroom.

But the biggest surprise was when my friend and I finally got our hands on Joe's files. We learned that Joe had done nothing more than copy the file from another project, then changed the title page and headers on all the files four times, once for each service he was supposed to be documenting. What was he really doing all day long at the computer? We finally figured out that he was spending all of his time buying and selling things on an online auction site. That was how he could afford to "work" for a third of our salaries.

Knowing it is "bad form" for one consultant to point out the failings of another consultant, we nevertheless had to go back to the client and show him that, to finish the project we each had nine month's work to do - four months, if we could get Joe back on task. The client was unimpressed. "You agreed to get this done, so that's what you'll do."

My friend and I worked out an attack plan that involved only the most critical parts of the project, and with a lot of work and cooperation between the two of us, finished those parts of the project on time - with zero help from Joe. After it was all done, and we made sure that the client was satisfied with the outcome, I said, "Just out of curiosity, why do you keep Joe on, when he doesn't really do anything?"

The client answered, "He works so cheap, I can't afford not to."

Gotta love 'em!

Over the next two years, I was employed almost constantly by different groups in my old company. Then, as that started to thin out, I began finding contracts with other Fortune 500 companies. Ten week contracts came and went, then six-month contracts came and went, then year-long contracts came and went. At the time, I thought I was getting "real money" - I was certainly earning more money than I ever had in my life.

The last really good consulting job I had in that series of work was documenting a huge system built using an oversold so-called "fourth-generation" programming environment. A Fortune-500 consultant had sold my Fortune-100 client on the idea that the programming environment could understand common speech. You would write out your requirements in everyday English, input them into the system, and working code would come out the other end. If the code didn't work the way you wanted, you would tweak your requirements and try again.

This was called "self-documenting," because the requirements would be the documentation.

But, of course, the programmers who discovered that the code didn't come out the way they wanted, fixed the code, and the requirements never got changed. By the third week of development, there was no relationship between the "documentation" and what the program was actually doing. And no writer was brought in for another year!

Eighteen months and 200 hires after the project started, the consulting firm rotated out the guy whose resume they used to get the contract and brought in another guy whom they promised would "learn on the job." After what I would estimate to be a five-to-ten million dollar investment, only one person in the company even knew how the thing worked!

Fortunately for me, the fellow hired to support the thing once it got rolled out saw that as a problem. He brought me in, initially, to write a troubleshooting guide to address a particular problem that was recurring at our beta site in central Europe. "Fine, what causes the problem?" "Nobody knows." "How do you fix the problem?" "You call 'Singh'"(not his real name). "What does Singh do?" "He goes into the database and deletes records that have a null character in such and such a field." "Why does that work?" "Nobody knows." And so it went.

Singh's real problem was that our beta site was seven hours ahead, and the problem always occurred when they were closing down for the night - 6:30 P.M, their time, 1:20 A.M. our time. So, several nights a week he was being awakened by a phone call to come in and fix the problem aain. You can be sure that he was only too glad to tell me everything I needed to know.

I mention this because I had to learn how the system worked before I knew why it was breaking, let alone how to fix it.

As I learned, it was a complex state-based system using a constantly-churning library of Oracle stored procedures. What was "breaking it" was that one of the senior managers who thought he knew how it worked (the same one that had bought into the program in the first place) kept shutting down the stored procedures in a sequence that was guaranteed to leave transactions hanging, half-processed, in the system.

If this had been my first exposure to Oracle, I would have been in serious trouble figuring all this out. As it is, with Singh's help I got my head around it. And while I was learning how the system worked, I documented everything.

I constantly ran the drafts past everyone who would look at them. I was hoping they'd find any errors. But most of the reviewers, including a few senior programmers said things like "I didn't know it worked like that!"

By the time I had been there six months, I had not only written the "troubleshooting" guide; I had also written a technical manual and a pile of training material - since new people were still coming in. My training program was getting newbies up to speed weeks sooner than newbies usually did.

Here's one of those "special moments" that are funnier in retrospect than they were at the time. As I mentioned, the consulting firm that convinced my client/employer to buy into this so-called "fourth-generation" system likes to use one person's resume to get the job, then, after some period of time, use the same person's resume to get business elswhere, and rotate in someone who is only marginally qualified to continue what the other person started. About the time I had documented the system thoroughly and was sending the document around for one last pass before I made it available on the intranet (which I also created), a new guy came in. He used my document to get up to speed, which you would ordinarily consider a selling point. But after he got familiar with the system, he found one minor mistake on page 37. Instead of bringing it to my attention, he sent out an email to the entire division and the Vice President above that. The e-mail said only "Your document is WRONG! Please see me immediately!" When I went to see him and learned that the offending mistake was basically a typo, I told him, "You know, most people like getting on upper management's radar, just not this way."

Gotta love 'em!

Then the same manager who had bought the development system and been responsible for most of the failures decided that the project was taking too long and costing too much, and he shut it down, laying off or terminating the contracts of nearly 200 people.

At the time I had three weeks left on my contract extension. My manager told me to drop everything and find a job. So I searched for jobs all over the region. I also kept my eye out for jobs that would be good for my coworkers, most of whom were great people who deserved better treatment.

During that time, while the office was in an uproar, I met two young women who had seldom strayed from their office before. "What kind of jobs are you looking for?" "Oh, we're professional trainers, they answered me. "We write training materials and such." "Have you been writing materials for our programs?" "No, silly, there's no sense writing training materials until the beta site starts working properly and we have something worth training people on."

So for as long as I had worked there, documenting the system from the bottom up and creating a whole family of training materials, two young women responsible for training had been sitting in their office chatting, reading books, and surfing the web. And nobody in the whole organization noticed. How do you even DO that when there's work available?

But the crowning blow came when I found them jobs. Or thought I had - two technical training jobs that each paid $20,000 more a year than I was earning on contract. I wasn't interested since they were too far from my home, but they lived in the area, so it was worth passing on. I printed out the job descriptions and took them over. They both looked at the job descriptions and - believe it or not - smirked! "I couldn't live on that," one said. The other one said, "Yeah, talk about a step down!" So it turned out that the two young ladies whose jobs I'd been doing for most of the past year were bringing home substantially larger pay checks than I was!

Gotta love 'em!

By that time, the "internet bubble" had burst, so the economy was already on a downslide. Then 9-11happened and the country's depression, emotional and financial, only increased. The market for experienced technical writing consultants bottomed out all over the state, and I found myself piecing together 10-week contracts for half of what I'd been earning just a year or two earlier. And the contracts kept getting shorter and farther apart.

Eventually I took a full-time job for relatively poor pay editing K-12 textbooks. I learned a fantastic amount about writing and editing textbooks, and had some of the best "team" experiences of my working life - we really did work together instead of working at cross purposes as many "teams" have over the years.

The company always seemed on the brink of financial disaster, though. When the job market picked up, I started looking again.

Ironically, I found a job in a company that was a wholly-owned subsidiary of the company that laid me off in 1995. I found out after I started the new job that they were really going to be paying me $15 an hour less than they had promised. But the pay was still better than the old job, and the company seemed much more stable.

Several months later, the family-owned company tanked, so I probably made the right choice.

Technical Writing in the Cloud Age

In the new company, I rewrote a 600-page help system and a related 600-page technical manual. I also started an intranet for storing all of the various sources of information that the other writers had produced.

During this time, the managers kept telling me that they were going to "fix" the discrepancy between what they had promised me and what I was being paid. But they also kept reorganizing, so I had a different manager every few months, and neither the second, third, or fourth manager was in the room when first manager made his promises.

Then the "wholly owned subsidiary" was assimilated, Borg-like into my former employer. As always, positions started being cut. I "hung in there" for another year or so. Then the employer decided to close our office, laying off about 1000 people at once, and transferring a couple houndred to another office. By then I had a pretty good sense of how the company was going to keep treating us, so I accepted the layoff rather than move several hundred miles just to get more of the same treatment.

I'll say this - the company made a point of subsidizing our Cobra payments for a year longer than they legally had to. In our case, that was about a thousand dollars a month, and it carried us until I found the next full-time job.

Here's an odd side-story. One reason that the company didn't think they needed to pay any "real" technical writers was that they were getting good results from several Filipino programmers. And after all, writing manuals is just like programming in English, isn't it?

The company couldn't see how documenting huge complex systems in English for demanding English-speaking customers would be any different. And, frankly, if you have to explain the problem with those assumptions to your new boss, you don't have a future with that organization anyway.

So while I was still an employee, they hired a young Filipino man I'll call Manuel. They allowed me to work from home a few days a week so I could keep a schedule that overlapped Manuel's. And I used the company conference line to train Manuel on the software, walk him through all of the web pages, help systems, and manuals we had done, and coach him on writing the most common kinds of documentation. If I'd had three years instead of four months, I might have made him into an actual technical writer. But in the meantime, I did everything I could to keep Manuel from hitting the wall hard as soon as I was out of the picture.

When I told one of my friends what I was doing, he said, "It would serve the company right if you would do a really bad job of training him, and then they'd be sorry."

I replied that it wasn't Manuel's fault. And bsides, if they couldn't tell the difference between my work after a thirty-year career and Manuel's best work, after several months of coaching, then I didn't want to work for them anyway.

In those days (the early years of Obama's administration), there were a few govenment programs to assist folks whose companies had sent their job overseas. Unlike 99% of the people in that situation, I actually knew exactly where my "job" had gone, right down to the name of my overseas replacement. But I didn't really need those programs as long as the company was extending my Cobra benefits, so I let it go.

Where to Now?

By the time I was officially laid off, the country was in the darkest part of a recession caused by the implosion of toxic derivatives in hitherto unregulated financial markets. Jobs were thin. Professional jobs were very thin. To make it worse, middle- and lower- class Americans who'd been hurt by the financial crises that billionaire bankers had engineered were falling over each other in their rush to blame other middle- and lower-class Americans for their pain.

I went on unemployment for a few weeks - the first time in my life. I didn't tell my right-wing friends, because certain propaganda machines funded by anti-tax billionaires, were rising in influence, and my "friends" were spewing a huge amount of unfiltered, uninformed vacuous rhetoric about how people on welfare and unemployment are only interested in scamming the system.

To put it in perspective: At that time, if I wanted to keep healthcare insurance for my family without Cobra, it would have cost me $1500 a month. My unemployment was about $2000 a month. Do the math, and determine for yourself if long-working family folks like me are really choosing to go or stay on unemployment just to "scam the system."

Hopefully you can see why I appreciated my former employer extending our Cobra benefits (bringing the payment down to just over $500). I also hope you can understand why I stopped voting for a candidates that promise "family values," but whose voting records prove that their only real agenda is protecting the assets of the wealthiest families in the world. I guess they define "family values" differently than I do.

God blessed me with two great consulting jobs in 2010. For one of them, I taught ten people in Bangalore how to use Robohelp over the phone, and oversaw a successful 1000+ - page document conversion project. For another, I documented a web interface utility that the company liked so much, that they found another purpose for it and moved me onto another project.

In early 2011, I found a full-time technical writing job near my house - the first time since 1987 that I worked less than 32 miles from home. So things are actually looking up. A year from now, my last child will be out of college. Two years from now I'll be eligible to start taking Social Security if I want to, which gives me more freedom to choose what I want to be doing for the next several years of my life than I have ever had.

Of course, when you think that way, you're making assumptions. Several close friends have not been nearly as blessed as I've been so far. In fact one of my best writing friends from my first consulting phase died of cancer only a few years after we worked together. Another close friend of the family has just died of cancer as well. So if I don't get all the opportunities that I can't help "looking forward to," I really can't complain - I've already had more opportunities than most, and many more opportunities than some.

Conclusion

What about all of those "gotta love 'em" stories I told? Am I really upset about folks mis-judging me or taking unfair advantage or some such ten, twenty, or thirty years ago? No. I related those stories because I know a lot of other folks can relate. Hopefully, some of the accounts will be cathartic, some will raise a smile, and some will help prepare younger folks for when the same sort of thing happens to them.

In fact I'd be glad to see any of the folks in my stories again. Life has beat us all down over the years. Sadly a number of folks I've included in this memoir have suffered great hardship since our paths last crossed. You might say "So they got theirs." I'd say, "There but for the grace of God go I." And if my compassion for other people doesn't oughtweigh every grudge in my life, that's my fault, not their's.

Now it sounds like I'm writing about life, not technical writing. But when you've done something like this for thirty-two years, the lines get fuzzy.

Whether you're at the start of your career, in the middle, or at the end, I'll be glad to hear from you, especially if you have a "great moment in technical writing" - or several - to report.

Looking forward to your suggestions, additions, criticisms, and anything else you care to send me, I remain,

Paul Race

Breakthrough Communications

P.S. Enjoy your hobbies. And be sure to enjoy any time you have with your family in the coming weeks.






























































































Note: Breakthrough Communications™, Family Garden Trains™, Garden Train Store™, Big Christmas Trains™, BIG Indoor Trains™, BIG Train Store™, and Trains-N-Towns™ are trademarks of Breakthrough Communications (www.btcomm.com). All information, data, text, and illustrations on this web site are Copyright (c) 1995, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 by Paul D. Race. Reuse or republication without prior written permission is specifically forbidden.


For more information, please contact us. Or visit one of our supported web pages:
Breakthrough Communications
Professional
Communications
Family Garden Trains
Outdoor Trains,
Large Scale Trains
BIG Indoor Trains
O Gauge and On30 trains,
Holiday Villages, more
BIG Christmas Trains
Trains for Trees,
Trains for Towns
Family Christmas
Online
- Christmas Articles,
Music, Stories,
and Craft Resources