The Birth of Modern Technical Writing

Yes, people have written instructions for centuries. But technical writing as a profession didn’t emerge until:

Those two trends emerged at a time and place where mechanical business machines reigned supreme and seem to have an infinite future – at a city with a long history of for such innovations as heavier-than-air flight, in a company whose hybrid tube-and-mechanical computers had recently helped the Allies win World War II by breaking the code of the infamous German Enigma machine. NCR, in Dayton, Ohio.

Surprised? So are most people who were born after, say 1955. By the time you had your first real job, mismanagement had nearly caused the collapse of that company, and, except for a few heroic attempts at a comeback, it has been shrinking ever since. But one trend the company pioneered during that transition continues until this day – technical writing as a profession.

The Rise of the Machines

NCR, which is currently a Georgia-based shadow of its former Dayton-based industry-leader self, started many innovations that other companies have since been credited with. For example, NCR invented the world’s first solid-state business computer; then upper management decided it had no future and stopped funding it, leaving IBM to pick up the slack. So it’s no surprise that the company that pretty much invented modern technical writing gets none of the credit for that innovation either.

For most of the twentieth century, NCR sold mechanical cash registers. To say they were complex would be an understatement. They were also designed to be adapted to the needs of foreign countries, including things like currencies with three decimal places and weird sales tax formulas. By the end of World War II, NCR had even figured out how to use hybrid mechanical and tube-based computers to do things like calculate rates of radioactive decay and break the code of the German’s Enigma machines, so there seemed to be no limit to what their business machines could accomplish.

Of course machines that complex could misfire or break down in ways no one could possibly have anticipated. So NCR’s repair forces were constantly being brought to Dayton to be updated and retrained, first at a log-cabin-based “campground” in Oakwood, Ohio and later on at a college-style campus built on that site and at a dorm-equipped campus near Miamisburg, Ohio.

Field Engineers and Purple Wires

Repairmen were not only trained to fix broken machines; they were also taught to troubleshoot errors that no one had encountered before. A communications network – indeed, a subculture – emerged to communicate new solutions around the world. So it was no stretch when NCR started calling their cash register repairmen “field engineers.”

As an example of the subculture, when a field engineer solved a problem by changing the wiring in a business machine, they used a purple wire, so any future worker would realize that the machine departed from the blueprints at that point. They would document the repair and send their documentation back to Dayton, where their supervisors would print up the documentation changes and send them out everywhere those machines were sold (as many as 88 different countries).

In the meantime, any new business machines of that model would include the modification, purple wire and all. That way, any field engineer who had to work on one before the new documentation came out would realize that the machine would not match his blueprints. Once the documentation was updated, the wire that had been purple was changed to conform to the standard wiring color code.

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

Field Engineers as Writers

As solid-state machines began taking over roles that “mechanicals” had “owned” before, the company realized that the need for distributing well-written updates to their field engineers would become more critical than ever. They formed a “Technical Writing” department and started calling their field-engineers-cum-writers “technical writers.” At first, however, they saw no need to train these technologically savy folks to write coherently.

As an interesting footnote to this part of the history, for years after this transition, certain old-timers would refer to emergency updates to any kind of equipment as a “purple wire.” This included things like software updates, in which no wire was involved at all. I only know this because several of these guys were nearing the end of their careers as I was beginning mine, and I heard plenty of “war stories,” believe me.

Field Engineers as Managers of Writers

For years, the manager of all these new “technical writers” was a former field engineer himself. We’ll call him “Norm.” By the time I was hired (1980), “Norm” 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, “Norm” had learned somewhere that it was bad form 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 “Norm” sent his bulletins to writers, and they often talked about writers. Worse yet, “Norm” 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 “Norm” was talking about himself, you, or some third party.

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 were hiring 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 former field engineer who thought stuffy, convoluted writing sounded “more professional” than straightforward text, so bad writing was still being rewarded in some circles.

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 who 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 to train the rest of the technical writers and to write a “how to write” reference handbook. That was Charles “Ted” Busaw who was writing books like Practical Writing; Composition for the Business and Technical World as early as 1973. Ted also worked with writers Gerald J. Alred, and Walter E. Oliu on several series of technical writing manuals, many of which are still required reading in university courses on technical and business writing today.

Ted and his cowriters customized one of their projects into the NCR Handbook of Effective Writing to address common problems that Ted was encountering while working with the FEs-turned-writers. I enjoyed it largely because it was full of real-world examples Ted had culled from his experiences at NCR. For example, in the section on misplaced modifiers, Ted included the what-not-to-do example, “Rolling around in the bottom of the drawer, I found the missing ball bearings.”

Ted also trained writers and writing managers through a series of in-house programs. By the time I hired on, Ted was less hands-on. I was eventually coached by a writer who had been coached by a writer who had been coached by Ted, and I learned more practical advice from her (third-hand from Ted) than I had learned in my entire college career. 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. Then, in 1979, upper management decided to break up all the writing groups. Sadly, this had occurred by the time I was hired on, so I didn’t get the benefit of Ted’s hard work for the first couple years I was an employee.

Where I Come In

Enter me, in 1980, hired to work for Dale “Mick” Rittenhouse, a former field engineer who reported to another former field engineer. That manager reported to a former cash register sales manager who was managing software development projects because the cash registers had gone away and he had no qualifications to speak of, but he still had powerful golfing buddies.

Most of my coworkers had BAs, though not all in English. At the time, I had a BA in English, a writing-intensive degree, to be sure. But none of my university professors had ever helped me improve my writing since I had graduated from Miamisburg High School, where Mrs. Robinson had drilled principles into our heads that I had coasted on for the next four years.

Mick and Joe 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. There were few standards beyond template requirements and not using the term “execute” to describe starting a program. (NCR 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.”)

Click here to go to Technical Writing in the Stone Age.

Click here to return to the Introduction.