Don W. Benesh
Background
My writing career developed from many years of writing training material (instructor guides, training schedules, handouts, etc.) after not being provided what I considered adequate material while working as a trainer. In addition to being a trainer, I spent some time as project manager, where I also wrote my own operating procedures, project plans, proposals, and business plans—for the same reason. By doing all this writing, I developed better than average skills as a writer, but only in support of my primary fields of interest—or so I thought.
During an interview about 10 years ago, the conversation migrated to training; when asked about the material I used, I mentioned I wrote my own—and I happened to have samples with me. The interviewer was more interested and impressed with my writing skills than my project management background. She suggested I look into technical writing opportunities and said she would be doing me a disservice hiring me as a project manager when I write “better than candidates coming into the office claiming to be a technical writer.” I thanked her, but had no idea what a technical writer was and didn’t want to appear uninformed by asking.
I searched “technical writing” on a few of the Internet job boards and discovered endless opportunities, but still had no idea what distinguished technical writing skills from all the writing I had done over the years. So I took a commercial technical writing course (about 150 hours) and became a Certified Technical Writer.
The course focused on technical writing best practices. By the end of the training, students developed a portfolio of help files, hardware and software user guides, and some Web development work. For me, the course wrapped up what I had been doing over the years into a neat package and a new career. WOW—I do that!
What I took away from the class was “best practices” for the work I had done previously, including parallel construction, consistency, and readability (not to mention the certificate and new portfolio). I was immediately hired as a trainer for a new company because I was also “a certified technical writer.” I had almost two years at that company as a senior trainer before the collapse of the dot-com boom forced layoffs.
New Career
With this background and experience I secured a new job where I was initially hired as a technical writer where I anticipated doing what might typically be expected of a technical writer—work with SMEs and write hardware, software, and network technical documents.
I was introduced around the office as the new technical writer (I discovered I was the only technical writer) and then given a completed manual. I was sent an e-mail with the soft copy of the manual and instructions to “sort of clean it up and fix anything that isn’t appropriate from a technical writer’s point of view.” When inquiring about a style guide, I was told (with a slight grin and chuckle), “that’s part of our problem, we don’t have one.” At the end of the first week, I had spent just over 30 hours on a manual of about 35 pages and figured that was all I could do. But my boss was extremely happy with the results. (Isn’t that all we really need to do … keep the boss happy?)
At the beginning of my second week I was given a stack (about 40 or so) of already written manuals and told to “clean them up.” Whoa, that’s a year’s worth of work! (Remember, I had just spent about 30 hours on one manual.) And “by the way, they are due in three weeks.” After about 200 hours they still needed work, but they were better. (Anyway, they were in on time—that was a hellish three weeks!)
By the third month I had more than 150 manuals cross my desk and accepted the fact that I would not be writing manuals, but editing—sometimes very substantially, when I had the time.
Over the next few months the company’s reputation for quality manuals grew—the client was most impressed—and senior management began to realize the need for the service I provided.
Building a Technical Publications Department
I believe my success as an editor was due to several factors: I was the only technical writer (nothing to discuss—what I said went); as a past project manager I was used to making decisions on the fly and moving on; and I started a technical writer’s tips bulletin.
From the manuals on my desk, I compiled a list of names (engineers/authors) and created a distribution list for my almost daily tips. Each tip addressed one topic with examples of what I have seen (incorrect) and what I want to see (correct). I also quoted sources—typically The Chicago Manual of Style, but also other references focused on technical writing, anything I could find to support what I wanted to see.
To encourage people to read these bulletins, I offered lunch to anyone who could find an error within the bulletin and regularly left an error to be discovered. I also have an odd sense of humor that I injected into the tips; such as, “Any questions? Yes, you in the back row … very good question!” then proceeding to provide an answer to my imaginary question. Judging by the comments I received, those on my distribution list enjoyed getting my tips and actually read them—and the manuals coming to my desk started improving.
After comments started coming back from our client about the improvement of our manuals, senior management began to take notice. I was asked what else could be done to improve the manuals. I suggested hiring a few more technical writers or sending all the authors to a technical writing course, or at least a workshop introducing them to technical writing best practices. A few days later I was asked if I could arrange such a workshop.
I contacted my technical writing mentor, who no longer taught the 20-week course but did provide on-site workshops—both a 1-day and 2-day outline. We contracted for a 2-day session and a few months later a 1-day session; we had about 12–16 people attend each workshop.
After the first year my boss was extremely impressed with my results, expressed with the comment: “Look at all you’ve done and you did it without stepping on any toes, or ticking anyone off. You are really well liked.”
Technical writers became an essential part of the project team. When the company secured two new projects, I was involved in hiring technical writers for the new projects. Later I recruited two temps for the project I was on; one was released after the 6-week contract, while the other was kept on permanently.
The first year I had one manager who pretty much left me to do what I knew needed to be done. After his promotion, I and the document controller (an administrative position responsible for distribution of all incoming and outgoing correspondence) were passed around to no fewer than six managers over the next 12–15 months. Finally, my last manager, upon leaving, recommended I take over the team I had pretty much created and virtually led—by this time, three technical writers and the document controller. The new project manager agreed and a new cost center was created—Technical Publications.
I stressed that documentation that goes to our client should get the same consideration as a four-color glossy sales brochure. I preached that there are two aspects to document quality: technical accuracy and literary presentation. While the engineers are responsible for technical accuracy, the technical publications team is responsible for literary presentation. Technical writers must keep in mind that our finished product is more than just a software or hardware specification; it represents and reflects the quality of the specifications.
After two years I finally had the time to actually write a manual (well, I was hired as a technical writer, wasn’t I?) and the original tech tip bulletins (about 75 tips) were compiled and became our style guide.
For almost six years, I have focused on setting a higher standard for our client documentation and the company in general. The first group of 40 manuals crossed my desk about 4 times, each time getting a little better. Comments from outside the office went from “great product, but lousy documentation” to “very impressive manuals…better than the other contractor” (an actual quote from one of our clients.)
Although I started out as a trainer and project manager, now I consider myself a technical writer/editor.