Technical Writing in the Stone Age
Back when I entered the world of Technical Writing (in 1980), 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.
Getting Grounded in the Corporate Communications Culture
For most of the 1970s, NCR had 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 the industry they were supporting.
Consequently, 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 Banking-related projects as needed. I started in Foreign Exchange/EFT (which is why I understood certain parts of the movie Jumping Jack Flash better than some of my contemporaries).
The Retail division had its own writing team, as did the group that handled manufacturing, healthcare, and several miscellaneous software products (I’ll call them “Manufacturing” because I have forgotten their meaningless acronym).
Initially, all three writing groups were in the same building, so we got the chance to get to know each other, to consult on common problems, and to build on the “tribal knowledge” that had been established in the 1960s and early 1970s. We would discuss hot topics in technical writing, post funny writing mishaps on a bulletin board, and hang home-made posters in our offices like “Eschew Obsfucation” and “Lack of planning on your part does not necessarily constitute an emergency on my part.”
A number of us belonged – off and on – to “STC,” the Society for Technical Communication, and we would pass around the newsletters. At the time, the regional chapter was dominated by employees of a Cincinnati database company, so going to STC meetings was a lot like attending someone else’s high school reunion. There was also a lot of emphasis on trying to get the membership to agree to professional standards. STC members also strove to get “Technical Communicator” recognized by nonwriters as a profession in its own right, and not just a necessary evil, as many companies saw us. (Sadly, STC is still pushing that rock up the hill. Because so many companies still perceive technical writing as a clerical function or worse, every time there’s a recession, they lay off the technical writers, causing a glut in the market. And that results in highly qualified, previously well-paid professional writers fighting over jobs that pay half of what they were making before, once again lowering the bar for company expectations of what we were really “worth.” In many parts of the country, even the salaries of COBOL programmers have kept up with inflation better than the salaries of qualified technical writers. And don’t even mention “career paths.”)
Breaking up is Hard to Do
Back to NCR in the early 1980s. About a year after I came onboard, the groups were physically split up so that Retail was in one building, Financial was in another and Manufacturing was in another. We still consulted across vocational lines occasionally, but the culture of world-class technical writing began to erode as the AVPs over the various divisions started setting priorities for the technical writing teams that had nothing to do with quality.
Then, between 1982 and 1983, our department (Financial) was reorganized so that each application development project had its own writer(s). The “down-side” to this kind of organization is 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 assigned directly to development managers wind up not being given time to do their “real job” and working at tasks that they find boring and frustrating.
The “long-term” downside was that, as more and more writers were assimilated into the individual development groups, departing old-timers were replaced by new hires who never had the benefit of Ted’s training and who would do whatever their immediate manager wanted, regardless of corporate standards. In short, NCR lost its commitment to world-class documentation. Eventually most divisions of that company had lost even a basic understanding of what that was.
By then “Norm” had retired, and the fellow who had taken his place (I’ll call him “Phil”) discovered that he had gone from about sixty direct reports to six. “Phil” valiantly attempted to prove his group was still important by specifying software requirements and documentation standards that nobody used, and by funding internal “research” projects that never benefited anyone who was actually writing for a living.
That said, one of the “breakouts” actually helped me – I found myself reporting to a coworker who had been trained to write when Ted’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 the 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.
And that’s where Technical Writing in the Bronze Age comes in. I’ll post the link as soon as I have the next chapter online.
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.
Click here to return to the Introduction to Great Moments in Technical Writing.