Kelsey Berteaux, Undergraduate Scholarship Winner
I became a technical editor entirely by accident.
Before I was ever interested in English and editing, I worked in IT. I loved working in IT. The job was fast-paced, engaging, and often intense, but it was a blast.
That was why, even after I chose to study English language and editing, I decided to keep working in my IT job even though it didn’t seem to connect with my new career aspirations. Or so I thought.
Editing, it turns out, is needed everywhere.
Once I started looking, I couldn’t believe that I hadn’t noticed the communication crisis that my IT department was in. Everything, from emails to posted notices, was in trouble. However, by far, the worst culprit of them all was at the center of collaborative cross-departmental efforts: an online collection of articles called the Knowledge Base, “KB” for short. The purpose of the KB was to document knowledge of the systems as well as how to use and troubleshoot them. This was supposed to be a time-saving measure—instead of talking to an engineer every time something broke, we could query the database and see if anyone else had run into the problem before. We could read the product design and service articles to hazard a best guess, or, barring that, we could look up who to contact based on the information we did have. The idea of the KB was elegant; its execution, however, was not.
The system persisted for several years, slowly accruing a modge podge of articles written by engineers, student technicians, managerial staff, and others. Nearly none of these persons had significant formal training in writing, and no effort to coordinate the articles had occurred. By the time I was hired at my IT job, the KB had been in disarray for years. The prevailing attitude was that anything was better than nothing. By then, the KB was composed of thousands of articles, and it was considered too large and too broken to warrant attempts at regulating.
Editorial opportunities—like the KB—are all around, if you look.
I worked with the KB’s contents and quirks for a year before I realized that standardizing the articles would greatly assist those using the database. I also hoped that if measures of standardization were successful in the KB, they could be applied to all IT communications. However, by that time, everything in the KB was a mess. We needed a document setting out how to handle common formatting, spelling, and grammatical problems. We needed a style guide.
The IT department was supposed to be following the Chicago Manual of Style, but there was little in it that could help the IT department with its specific problems—for example, almost nothing in the CMS addressed electronic communiqué, which was where our chief problems were occurring. We needed something that explained when HTML was acceptable, how to handle instances of written code, how to format a graphic, what the difference was between “a KB” and “the KB,” and dozens of other IT-specific difficulties.
Because I had been working in the IT department for more than a year already, I had a good grasp on what needed to be changed. At the end of the first KB pass, the style document I was developing was seventeen pages long, with more than thirty unique items addressed, including: standardized spelling for various IT tools; sections on how to write clearly without resorting to long sentences and technical jargon; how to format online articles, including what fonts to use, how to space paragraphs, when to use boldface type, and other concerns; a proposed color code for text; how to format screen shots and explanatory notes; and how to distinguish a server name from other text. Initial reviews of the supplementary style guide were positive, and essential.
The next goal for this project is to condense the information to fit on the front and back of one page, thereby making a sort of quick reference sheet that all IT employees can have at their desks. This measure should also encourage the writing-shy IT professionals to actually use the guide because they can skim the page before they write.
Certainly, when I was hired to work in the IT department, I never thought I would be editing for them. Even when I started work on the KB project, I didn’t envision the end product that the department could utilize best. Adapting is the name of the game—creating opportunities and seizing them.
I say I was an accidental technical editor. When I started out, I thought that I came into my niche job backwards. I realize now that I really didn’t. The technical training necessarily came first, and then once I had the training to edit, the two naturally married together. For me, it was perfect. I look forward to many long years exploring the quirks and vagaries that technical editing offers those audacious enough to pursue it. In editing, as in life, things always change; roll with it!