The name of this blog, Technical Editors: Arbiters of Quality, reflects my strong belief that technical editing is a whole lot more than just marking up sentences for grammar and punctuation as per an agreed upon style guide. That is certainly a part of it, but it cannot be all of it. Ever. An arbiter is one who influences or one who has authority. So technical editors are the arbiters of quality in my ever-so-humble opinion. As technical editors we must assert our authority or consistently seek to influence our teams about the quality of the information.
I am lucky enough to work with Andrea Ames, who recently provided great motivation to our team about asserting ourselves as professionals, as experts in the information experience. She encouraged us to not be “just a technical writer” (or in my case, “just a technical editor”) and instead be an information developer (or, in my mind, an information quality architect). We should strive to be more, to define ourselves as problem solvers for our users. It’s not about how many topics or UI panels I edit, but instead it’s about how many user problems did I help solve today. I need to walk away from the box entirely (not just think outside of it). A recent rant by Rahel Bailie on The Content Wrangler blog talked about this focus on professionalism as well, and she went so far as to suggest technical writers call themselves proofreaders if all they were going to do was “correct some grammar and add some editing marks” (I’d say the same thing for technical editors, too, mind you!).
Technical editors need to focus on quality content. We need to help writers provide just the right amount of content, make sure it is structured well, and make sure to link that content to just the right content, and of course make sure that the content is accurate and useful. If that content has a typo or grammatical error (or two, or three) in its sentences, that’s okay. Our users need quality content first and foremost. I know, I know, I can hear my peers screaming at their computer screens right now, but we have to spend our most precious commodity (our time, our effort) on what matters most: content overall, not grammar and style. I’m not the first to propose this (Nadziejka, D. 1995. “Needed: A Revision of the Lowest Level of Editing.” Technical Communication, 42 (3): 278-283), but I do frequently support this position. In teaching the different levels and types of editing, we explore the various tradeoffs that technical editors must make to plan for and complete their editing tasks, and where they put their focus. But, I’ll save more of that for another post for another day. For now, think about walking away from the box and focusing on doing more.