Technical Writing

My technical writing, technically speaking, began in 1959 when I was in electrical engineering at Kansas State University, with a course creatively named Technical Writing. We didn’t actually do much writing. The instructor seemed far more concerned that we become close friends with Op Cit, and his pal Ibid. My real writing began with my first career job, at Bell Telephone Laboratory, in Whippany, New Jersey, working on the Nike Zeus anti-ICBM missile project.

One of the projects I was responsible for was to determine why radar communication was lost with so many of the Zeus missiles, shortly after launch. The report shown is the one I wrote presenting the analyses used, and all the math supporting them, as part of solving that mystery. I wrote the report in much the manner I had been taught in my Technical Writing course, and through the many lab reports that were a part of my EE curriculum. I was, and am, quite proud of that report. As luck would have it, I didn’t get to mention my old college friends, Op Cit and Ibid, as there were no references used in the analyses.

During my EE career, I wrote a goodly number of reports like my Zeus report. But I think I learned how to actually do technical writing when I began to be a part of, and later in charge of, writing proposals for radar contracts at Texas Instruments, in Dallas, Texas. After winning those jobs, we then had to prepare marketing material—brochures—to support our efforts to win contracts internationally.

My first real lesson on technical writing came not from my professor at Kansas State, but from a stern, no-nonsense editor lady who had been hired to chop a lot of technical flotsam out of a proposal we were preparing on a major Defense Department radar job. The proposal was word-limited. But engineers tended not to be. We ramble, and stuff in detail, and use lots of words foreign to most English-speaking people. After we had submitted our drafts, we had to sit down at a table, across from our editorial executioner. Just her and you, alone in an empty room. She would take each page of your draft, look you in the eye, and ask, “Why should I not tear this page out?” After a few seconds of stumbling over how important it is that the reader knows which transistor turns on which light bulb, she would rip out the page. And that’s when I learned how to do technical writing.

I’ve since learned that “technical” writing is not much different in principle from “non-technical” writing. In either case, you must relate to your reader. What is your message to your reader? What do you want to be most remembered, to seem most important, when the story is finished? Too much so-called technical writing appears to be an attempt to show the reader how much smarter the writer is than the reader is presumed to be. Technical writing should inform, not insult.

My real test as a technical writer came when I began writing text for sales brochures. It’s not my favorite kind of writing. I don’t like using buzz-words, and one-word sentences. But we were attempting to persuade someone to plunk down a lot of money to purchase a very technically complex product. We were proud of how technically complex our product was. But all the customer wanted to know was, “Will your product do what you say it will, what I want it to do, and do so reliably? Why should I buy yours, and not the other guy’s?” I had to remember my reader, and what my story to that reader was to be. In truth, those sales brochures differed only in detail and word-count from any of the novels I have written.

If you have a story to tell to a reader, if you need some "technical writing" and don't feel qualified, or motivated, to write it, let me help you solve your problem. I won't say I like technical writing as much as I've come to enjoy fiction, and non-technical non-fiction, but I've done a lot of it. I can help you out.