Technical editors have a sense of humor. At least, this technical editor does. Did you hear the one about the teacher who asked a student to name two pronouns, and the student replied, “Who, me?”
I enjoy a good joke. I’m also serious about editing. I wince when someone says “on accident.” I get into heated debates about the Oxford comma. And I sigh when I get unfinished work to edit because I know I’ll have to edit it all over again.
In the publishing industry, the editorial process follows a strict progression:
Stage 1: Developmental/substantive editing focuses on the overall content: What is it? Does it make sense? Is it in the right order? This stage includes revision, which takes a larger view of the content as a whole, as well as line editing, which takes a paragraph-by-paragraph approach.
Stage 2: Copy editing is all about grammar, consistency, style and fact-checking. Now is the time to argue about comma placement and identify dangling modifiers. Content does not enter the copy editing stage until it has been officially “delivered and accepted” by the editor.
Stage 3: Proofreading occurs when the text is in layout. This is the last chance to catch any mistakes. During the proofreading stage, only “printer errors,” or layout errors, are freebies. Any other changes, such as adding words or moving content, are called “author alterations.” Those get pricey. That’s because by this point, the only changes should be to correct errors.
The unwritten rule to the above is that the draft content is complete before it enters the editorial process. Call that “Stage 0: Drafting.”
In publishing, following the process is key. By the time content gets to copy editing, there should be no further developmental changes. When it gets to proofreading, we shouldn’t be arguing about the Oxford comma. The process has a clear beginning, middle and ending. It’s linear. In project management, a linear approach is called Waterfall.
When I began working on proposal teams as a technical editor, I expected a Waterfall approach to content development: draft the content, then start the editing process with developmental editing, move onto copy editing and finish with proofreading. This was my process, and it would never change. You can’t teach an old editor new tricks. (Don’t get me started on “these ones.”)
What I learned was many proposal managers use a different project management approach to leading proposal response teams: Agile, which is iterative and team-based. Perhaps most important, Agile emphasizes rapid delivery.
As a technical editor, I found the idea of the Agile approach to be an anathema. My initial reaction to Agile went something like this:
- Iterative: “Break down content into chunks? That doesn’t work! Editors begin at the beginning, work through the content methodically and end at the ending!”
- Team-based: “Editing is a solo process!”
- Rapid-delivery: “You want me to break out into hives, don’t you?” (Go on — ask an editor how many pages they can edit in an hour. I’d be shocked if the immediate answer isn’t, “It depends.”)
This was a conundrum. My Waterfall editorial approach collided with the Agile content development approach favored by proposal managers.
At first, I simply got used to rework. I would edit what I was given, and then as more content came in, I would edit that as well as go back to redo what I had previously edited, starting with Stage 1 (developmental editing), working through Stage 2 (copy editing) and finishing with Stage 3 (proofreading), all the while lamenting that Stage 0 (drafting) hadn’t been completed previously.
It wasn’t until I worked on a different type of project that I got to see Agile in action — and that opened my eyes to proposal possibilities.
The project manager held a kickoff meeting with about a dozen people from different teams and departments attending. He shared his vision, which included five phases. He then broke the team into distinct groups: each with a group lead, and each group tackling one of the five phases. I was assigned to a sixth group, not attached to one of the identified phases, and appointed the “design solution team lead.” The project manager told us we would meet again in two weeks to share results.
I had no idea what I was supposed to do. How could I have my team work on a solution at the same time others were working on their distinct phases? I was a technical editor. I was used to a sequential, Waterfall process, which clearly wouldn’t work in this case.
After a bit of floundering, I called the project manager and asked for help.
The project manager was receptive and explained how tackling phases simultaneously would allow us to benefit from lessons learned in almost real time, so we could incorporate changes along the way. He encouraged me to continue to ask questions, which led to numerous calls and quick email exchanges over the course of the project.
Working on the project, both as a group lead and as someone new to Agile, helped me expand my perspective from defaulting to a sequential order of tasks to tackling via iterations. I also saw the benefit of being adaptable: We changed the deliverable over the course of the project to better fulfill the project’s purpose.
In the end, the project deliverable was well received. I came away from the process with a better understanding of how getting feedback in smaller chunks of a project — or a proposal — can provide valuable information that can be directly applied not just to those chunks but to new content still in development.
What lessons can technical editors learn from taking an Agile approach to proposal development?
- Editing doesn’t have to be linear. We can be flexible and polish as we go. While this may mean rework, it also means that sections of the proposal will be ready for review at a moment’s notice.
- Editing doesn’t have to be siloed. We can collaborate with the proposal manager and the subject-matter experts to break down the content development schedule into manageable chunks.
- Being adaptable means being more responsive — to the RFP and to the proposal team. It also can help build stronger relationships among team members.
I’m equally grateful for my experience on the project team as for the opportunity to think about editorial approaches other than Waterfall. I guess you can teach an old editor new tricks.
Now I just have to remind others that it’s not “10 items or less.” It’s “10 items or fewer.”
Jackie Kessler, CF APMP, is the marketing communications manager for NYSTEC. She has more than 20 years’ experience in corporate communication and content strategy. A Certified Professional Technical Communicator (CPTC), she has served as proposal manager and technical editor on numerous successful, multimillion-dollar proposals.
Great article! As a former technical editor, now Proposal Manager who often takes on editing for smaller projects, this really resonated with me. At first, I was frustrated by constant “rework” but I also learned a very important lesson: Never marry your work. It will inevitably change in some way. As long as it contributes to the final product’s success, it is worth it.
P.S. YES, it is “fewer.”