The Prudent Technical Writer

My father worked at many different jobs in his life. He wound up as a technical writer at Raytheon in the late 1960s and early 1970s, documenting the Hawk, Sparrow, and what became the Patriot missile systems. As it has transpired, I became a second-generation technical writer and spent a full, 40+ year working life almost exclusively in that field. I worked for ten companies with hundreds of writers, editors, artists, and production experts, and thousands of managers, developers, testers, product managers, and marketers. I know I wrote hundreds of full manuals and thousands of documents, because midway through I started keeping count. Whether owed to excellence or inertia, few can boast so much experience.

A lot changed during those 40 years. My first writing tool was a typewriter, and my first cubicle mate, an experienced writer, wrote his drafts out longhand, in pencil, on legal paper. The focus of documents was the text because the format was controlled by a production team and because anything non-textual was difficult and expensive to produce. The review, approval, and print production cycle took 13 weeks. For my last publication, I wrote it at home on a laptop; some colleagues worked half a world away and I never laid eyes on them; the source files were stored half a continent away; I was the writer, editor, artist, and production manager; the product manager complained when the review/approval/production cycle took more than a day; and the publication appeared simultaneously in application help, the company website as web pages, and print PDF. The scope of what we documented, how we documented it, the tools we used, and where we published, changed utterly.

But some principles that I was taught as an associate writer, and some things I learned along the way about working with information and people, remained true when I retired as a site manager for the writing team. Quite a few people have written textbooks on technical writing, but I haven’t seen one on how to be a technical writer—to do good work, to do it efficiently and effectively, and to be a good member of a work group. My plan here is to offer occasional series on things I’ve learned over the years that don’t appear in textbooks on technical writing but are still, in my opinion, valuable and important to know.

To declare my biases, almost everything I wrote as a technical writer was in the domain of computer software, and I wrote for end users, system administrators, operators, and architects. I will try to make my posts in this series as widely applicable as possible and to separate facts from my opinions. You can judge or yourself what, if anything, is useful and applicable. I’d love to hear your comments as well.