How to edit other people's content without pissing them off - Ingrid Towey

Editing other people’s documentation without triggering defensiveness comes down to one practical shift: treat edits as customer-focused improvements made in partnership, not as corrections delivered from above. Ingrid Towey, a senior technical editor and writer at Red Hat, frames the goal as keeping writers “happy” with the outcome—because trust and diplomacy determine whether feedback lands as help or as insult.

Towey ties that approach to a long detour from her earlier career as a technical writer and usability specialist in the early 1990s. After homeschooling her children for 15 years, she found she became a better writer and editor than before—largely because teaching writing forced her to be both effective and tactful. You can’t “throw edits over the wall” and hope they work; learners need context, patience, and guidance that respects their intent. From that experience, she crystallizes four principles for editing and peer review.

First, everyone is on the same side: the customer side. Instead of debating internal preferences, editors should align with what readers need to accomplish. Towey emphasizes how modern online readers behave—often scanning rather than reading. She cites research suggesting users may have only seconds before leaving, form an opinion in about 50 milliseconds, and read roughly 28% of a page. The implication is blunt: documentation must surface answers quickly and help readers find what they need. She also illustrates how audience understanding can overturn assumptions. A diagram designer animated a systems diagram to make it engaging, and many internal stakeholders loved it—until usability testing with systems administrators showed they wanted the whole picture at once, because they think model-first.

Second, editing is not an edict. Edits should be collaborative and reversible, not a power play. Towey argues that editors don’t need to fix every comma or impose every stylistic preference; the job is to improve usefulness. She also warns against making changes that can introduce technical errors—especially when editors lack domain knowledge.

Third, explain why the edit was made. Towey recommends backing up changes with objective authorities and evidence: readability tests (like Flesch-Kincaid grade level and Flesch Reading Ease), usability testing, and established writing standards. She walks through a real example where a dense, technical paragraph scored at a grade level around 24.7 and was rewritten into bullet-based, shorter sentences, improving readability to a grade-level score around 9.3.

Fourth, get help. Editing doesn’t have to be a solo act; peer review groups, co-op support, and structured meetings can distribute expertise and reduce blind spots. Towey offers meeting guidelines: focus on a few high-impact areas (like headings and customer focus), agree on writing principles in advance, use kind feedback (often framed as “positive feedback first”), appoint a meeting leader to prevent domination, and ensure quieter participants are heard. Ultimately, the edits that stick are the ones built on relationships—writers trust editors who show care, competence, and positive intent, and that trust makes feedback easier to accept and act on.