Skip to main content
October 14, 2013

How the “we-meeting” kills good tech comm

Does this sound familiar?

One reason for lack of accountability is the we-meeting. You know the one: “We need a new process for handling customer service issues.” Lots of discussion follows, but no clear direction is given, nor is any responsibility taken.

Bruce Clarke (The View from HR column) referencing consultant Kathleen Kelly

Having worked on many content strategy projects, I can confirm the “we-meeting” is a huge problem for tech comm professionals—particularly when it comes to getting subject matter experts to review technical content.

Photo of ax

Flickr: Martin Cathrae

A solid technical review can be the difference between technical content that merely rehashes the patently obvious (“Press the Print button to print.” Oh really?) and content that gives users depth, context, and useful examples. A technical review must be a collaboration between the SME and writer. Unfortunately, some SMEs (and a handful of tech writers) often see reviews as cursory obligations that should get as little attention as possible. That attitude is deadly for useful content.

What’s the cure for these useless, superficial review cycles? Accountability, which can take many forms, including:

  • Using workflow tools to assign and track content reviews. For example, software companies already use bug tracking tools, so consider using the bug tracker to track review comments, too. Component content management systems often offer collaborative review tools and include ticketing systems, tracking mechanisms, so on.
  • Building in reviews as part of the development process. Scheduling reviews not only sets aside crucial time for reviews, but it also sends the message, “Reviews are an official part of the process.”
  • Specifying what’s in and out of bounds for technical reviews. For example, nitpicks over formatting should be outlawed. If formatted content is what’s being reviewed, technical reviewers should not be requesting changes to line spacing, formatting, and so on, particularly when that formatting is merely aesthetic. (A bad line break in a code sample that could cause errors is another story, though.) If you’re working in an XML-based environment, you may have some options to present review content in a vanilla, formatting-neutral manner that stops useless formatting feedback in its tracks.
  • Instituting consequences for reviews that are late or do not meet criteria. Management has to step up and do icky management things when reviews don’t occur when they are supposed to. If reviewers and content creators aren’t giving reviews time and care, they are failing to meet their obligations as employees.

Codifying review cycles and their objectives is not fun. But you’ve got to do it to get “we-meetings” out of your tech comm.