Editor: Mike Pope Company: Google # of years in editing: 30+ years
Tell us a little about yourself, including how you got started as an editor?
I didn't formally train to be an editor; I got into it sideways by already being in the software business. I've been in technical writing and editing since 1985, and I've swapped back and forth between being a technical writer and technical editor since then. In my last couple of jobs I've been a full-time editor.
What is your area of focus and why did you select this niche?
My whole career I've been in the software industry. I started in tech support and training, but then moved into documentation. It's been such a great field for me that I've never considered moving to a different domain.
Walk us through a typical workday. How do you manage your time?
I generally have several articles going concurrently. For example, today I'm finishing the developmental editing for one document and copyediting three others.
I'll allocate blocks of time for heads-down editing so that I can make progress on stuff that's in the queue. But then there are also all the meetings, emails, and other work-related activity that I just have to deal with as it arises.
What is your favorite thing about being an editor?
The variety. I might be reading about machine learning in the morning and about databases in the afternoon. Tomorrow I might read about computer security or about how to create a successful software-development culture. I learn so much in this work.
What is your biggest challenge and how do you work through this?
We produce a great volume of information, and it's not possible for us to scrutinize everything at a level that we'd like to. So we constantly have to balance our time and our level of editing against the realities of keeping the pipeline moving.
We address this in a couple of ways. One is to prioritize what we can do with the time we have; for example, getting our branding right is more important than whether there's too much passive in a doc. We're also teaching non-editors some editing skills so they can help themselves or one another without having to rely only on us.
What are you currently working on?
The usual editing, of course; I have about a half-dozen articles in my queue. I'm also writing a blog post to describe some changes to our documentation system. This afternoon I'm helping lead a session for new writers on how to use our tools, and finishing up a presentation to teach our author-engineers what the draft-edit-review-publish process looks like.
What advice do you have for someone who is just starting their career as an editor?
Technical editing is like any editing—you need to understand language mechanics and you have to have skills for interacting with writers. It helps to have some knowledge of the domain that your authors write about, but you don't have to be an expert. (And you will definitely learn as you go!) Our working environment tends to be dynamic, so flexibility is essential.
One difference is our readers: they usually don't want to be reading our text! They'd rather be completing the task that they were stuck on when they turned to the documentation. We therefore need to constantly focus on "reducing friction"—making information easy to find and easy to understand. A skill that a technical editor should cultivate is to learn to ask "What would help *me* learn this information?" and help guide the the author toward answering that question.