by Paula Robertson, STC Associate Fellow
Have you ever wished for a “quick-and-dirty” way to impart all of your editing expertise to a recipient of your edits without having to explain and comment and rewrite and suggest and explain some more, back and forth, in written edits? If only there was a way for your thought process and rationale to be magically conveyed along with your detailed words, rewrites, and deletions. (Why isn’t it obvious to them anyway? Alas, but our education systems didn’t train us to write clearly.)
You might say editors are just wired differently from writers. Rather, writers have different goals than editors do. But isn’t there some easy way for us to come together of one mind toward the common purpose of clearly communicating to our mutual target audience? I believe the answer is Yes. Yes, there is.
I am an editor for a company that produces grade-school curriculum in the STEM subjects. I see the spectrum of our content products, which are developed and written by a sizable team of highly educated, creative-thinking, intelligent, education professionals. But frankly, their writing sucks*. I say that in the nicest, broadest sense, because they must be doing something right—considering the popularity of our curriculum. And it’s not fair to judge all writers with the same liberal assessment.
It’s not that they’re snobbish about their writing skills; they know that they could use some help with their wordiness and word choice. Writing is not their core competency. One of the team leads recently approached me with, “I wonder if it might be instructive for you to lead a conversation to talk about Word Choice and Conciseness as ideas we could apply to help reduce the amount of text in our courses.” I doubt that she meant that sentence to be self-exemplifying, but it proved her point. And it sang my song.
After almost five years of editing many of the same people’s writing, it’s discouraging to find the same types of errors again and again. Based on my training in technical communication, I expect writers to treat every edit they receive from me as a learning opportunity that has implications beyond that one piece of prose. I anticipate that they will notice repetitive kinds of edits and intuit that they might have a problem in that area, and what’s more, that they will do something about it. Instead, they seem to treat every edit as brand new. I struggle to find evidence of growth.
So when this team lead approached me, I took the opportunity to suggest an idea that had been floating around in my brain for a while. What if the writers could be an interactive part of my edits? What if they could virtually sit on my shoulder as I’m doing an edit and get inside my head to hear the conversation I have with myself to justify what I’m doing? What if I did a “live” edit to an audience of my colleagues?
The lead and my manager loved the idea. What had been only a hunch was set to become a reality. But what was I thinking?! I had never done anything like this before. This could be a risky endeavor. What if I choked in front of my peers? What if I made a fool of myself? More importantly, what if I couldn’t deliver a valuable experience? What if it was all a big letdown and nothing was gained?
I guessed we would all find out. I was committed. And I embraced the opportunity. To make it authentic, I suggested that I not be given the content to edit until on the spot. I would not have a chance to preview the text to get an idea of what I would be in for. No idea of the complexity or wordiness of the selected content. I also had no input into what they chose for me to edit. I would be working without a net.
A date and time were set, and the session invitation was sent to all the writers on the specific development teams and then some, plus the VPs and Senior VP. Because we all work remotely, the meeting would be conducted through Zoom. I would review the content with our default, literary level of edit.
I only had slight jitters when the time came. They gave me two documents to review for a total of six pages. It was content from one of our engineering courses. We kicked off the meeting and I set a couple of ground rules. Not knowing how long it would take me to get through the content, I didn’t want to get bogged down in questions, but I didn’t want to discourage questions either. I wanted attendees to have their questions answered in real time. That was kind of the point of this whole exercise. I wanted them to understand the edits in context. But if something started to go astray, we would come back to it later.
As I shared a Word doc on my screen, I read the text out loud and stopped wherever something caught my attention. I made changes with revision marks as I went and described my thought process. I looked up terms whenever I suspected a misspelling or words used incorrectly. I even pointed out the grammar checker in Word, which can be helpful with wordiness. I worked quickly to make best use of the time and to be authentic to the way I work.
The six pages of content, which one of the writers had volunteered, turned out to be just the right length and complexity for this one-hour session. I was disappointed that the content did not include a good example of passive voice, so I could demonstrate how to recognize and take care of that; I suspect that the team lead was disappointed as well. We only scratched the surface of things to look for in an edit, which was not surprising. But as a first try, it turned out to be painless for all involved. It set a good precedent.
For a seat-of-the-pants exercise, it went very well. I counted 30 people in attendance. From the feedback, it sounded like I covered a number of basic things that they didn’t know (or hadn’t retained from my edits) and I worked in some reminders about our house style.
The Senior VP messaged me right afterward: “Paula, thank you for leading us through this exercise. I found it helpful to see the editing process through your eyes and it did generate good questions from our writers. I look forward to exploring additional opportunities like this to support our developments. Thank you!”
Other comments included:
“… I really appreciated the experience! Thanks for taking the time to walk us through your work”
“It was a really valuable use of time”
“[This] was valuable for teams to engage in, and would love for us to continue doing things like it”
“We found it very helpful and were taking notes”
At the lead’s request, I followed up the session with a handout of examples I’d already been working on—examples I gleaned while working on more complex engineering content—of passive voice and wordiness. They included before-and-after edit versions with word counts to show how using active voice cuts down on wordiness to begin with.
I’m calling this experience a success! I hope it gives you some ideas for how you can engage your writer audience more personally in your editing standards and process. You can demonstrate edits as you apply them. The next time I do this type of exercise, I’ll pick the content, to be sure I have some juicy text weighted in wordiness and passive voice to wave my wand over.
* Schriver, K. A. (2007). If you’re so smart, why does your writing suck? (presentation). STC Summit 2007 Proceedings. Fairfax, VA: Society for Technical Communication.
What a great idea! I’ll probably try to do the same on my next editing contract. That is, IF the writers/subject matter experts will make time for the exercise.
This sounds like a great experience that will sensitize at least some of your writers and could cut down on some of the problems you have to catch in your edits.
I had luck with another kind of live edit for messages and UI content in an agile setting, what’s often called “UX writing”. My live editing approach evolved after I found that, despite detailed edits for developers with explanations for why I was making certain changes, I kept seeing the same problems. I also saw that not all my suggestions were implemented. So I started meeting with a developer or a small team working on a feature and review their UI and messages with them. That way we could get agreement to simplify terms and to ensure the technical accuracy of the edit as we went along. There were times when these “edits” even ended up with simplified code as one of the developers saw a streamlined way to accomplish something. But most of all, the developers saw patterns emerging from my explanations, and they began to adopt some of them. I also had success doing this one-on-one with technical writers, and it took no more time than my solo edit.
I completely agree with your method. It is always best if the editor can be involved in the content development as an equal partner. But some cultures are not conducive to that. Thanks for your response.