Reflections of a Technical Editor

This post is part of a series of case studies by and for in-house editors. The focus of this series is on the personal experiences and various roles of in-house editors. If you’re interested in writing a post for this series, please email the Member Services Committee. 

A few years ago, I took a course in information design. Many students taking the course were aspiring editors, but definitely not technical editors. They all thought that technical editing was boring, soul-destroying and lonely.

At the time, I was editing financial texts for a large bank. I never thought I’d end up there, but I liked my job. Sure, it wasn’t exactly my dream — I was a mere cog in a corporate wheel after all — but I got to spend my days working with writers and words.

Besides a high tolerance for corporate jargon, what skills do technical editors need?

Research skills (or cultivating a bizarre search history)

Fact checking is usually reserved for the copyediting stage in publishing jobs, but in technical editing there aren’t usually distinct editing stages.

As a technical editor, I’ve researched terminology on topics like bed-wetting and investment rules. I’ve scoured dictionaries and style guides for guidance on hyphenation. Besides the standard language resources, I use internal resources (in the hopes of understanding 5G technology) and industry resources like product websites and technical specifications (in the hopes of getting product names right; see “AirPods” and “Galaxy Buds”).

People skills (or choosing a hill to die on)

The expression “You’re editing the person, not the words” is just as true in technical editing as in book editing. You might edit texts that were written by technical writers, subject matter experts, lawyers, or even a stray VP or two.

When you’re editing people who have to write for their job, they may have some … quirks. For example, they don’t use contractions. Ever. Or they think you can’t end a sentence with a preposition. And they definitely didn’t get the memo about the singular “they.”

This is where you have to rely on your people skills, or rather, your prioritizing skills. What must you edit so your readers get the message? How long will the information be published — for a week or forever?

It’s not worth your time to quibble over wording that won’t make a difference to the audience’s understanding of information. I used to shudder over the use of “onboarding” as a verb. These days I edit training texts and I see “onboarding” everywhere. I’ve learned to let that one go. I choose my hills wisely.

Technical skills (or learning to love learning)

It might seem obvious, but a willingness to learn new systems is a must. Technical editors work with many systems and software. In my first technical editor job, I got a crash course in HTML and content management systems. Later I worked on a team migrating an intranet to SharePoint. If I ever have to edit procedures for systems, I’ll put that beginner experience to good use. A technical editor never knows when something they’ve worked on in the past will become useful again.

Other skills (or all the other stuff)

Technical editors end up developing lots of non-editing skills. It’s important to keep track of those other skills, especially if you’re looking for new work or doing a performance review.

Ever completely redesign a text? Or rewrite headings or create keywords to optimize search results? Dabbled in user research? Transcribed videos? Your “other duties as required” can be varied, and you might even make a career out of it.

Technical editing isn’t for everyone. But I can’t say that I’m bored, and my soul seems fine. And there’s a whole community of editors out there to keep me company.

___

The Editors’ Weekly is the official blog of Editors Canada. Contact us.