I Need My Input! Getting People to Review Content

Home/Publications/Best Practices Newsletter/2007 – Best Practices Newsletter/I Need My Input! Getting People to Review Content


April 2007

I Need My Input! Getting People to Review Content

CIDMIconNewsletter Ken Jercha, Aquent

We have all experienced or observed many extremes of review participation. For some projects, ample feedback positively impacts the content. On some projects, the input is provided but the type or quality is lacking. Still other projects leave us feeling like we are shouting in a canyon, only to hear our own voices echoing back to us.

Many inputs are highly valued; others can be extremely annoying. But, as information managers and developers, we excel at getting input, evaluating the value, and determining the appropriate treatment. We assimilate, prioritize, disregard, rewrite, put into tables, add illustrations, throw out sections, restructure, and do what is right to meet users’ information needs. And, typically, we are wiling to take the good with the bad without complaining, because it is better to get input than to get little or no feedback.

What do you do when you can’t seem to get people to participate? Some information developers resort to entreating, embarrassing, harassing, escalating, and using numerous other techniques to get reviewers to participate. What if you can’t create enough pressure, leverage, or suction to get people to provide feedback? Let’s examine some possibilities.

Let’s start with the major premise that we all have the same information goals – high quality content in the hands of our users, delivered when and where they need it. Let’s also agree that it can be very tough to get to high quality finished content when reviewers provide little, no, or late input. The same issues apply for manuals, help systems, job aids, or training content. This article addresses the people part of the equation of reviewing information.

No More Dream Projects

There are dream projects where we are both audience and subject matter experts and don’t need much feedback. Those projects are decreasing in frequency – I have seen very few in the past couple years. As project lifecycles speed up; as we work increasingly across time-zones, cultural, and language barriers; we get less opportunity to work as experts. This development model increases our reliance on input from reviewers to produce the high quality deliverables to which we aspire.

I have worked in this business long enough to remember having stacks and stacks of reviewed copies arranged very neatly (at least at the start) on three tables, as I reconciled the comments of a dozen or more reviewers. How painstakingly precise I was in checking – page-by-page – the multiple inputs on a particular graphic, concept, or procedure. And, at 3:00 in the morning, with unknowable quantities of coffee (BL: before lattes), neatly stacking the completed work and placing it in boxes (naively expecting that the boxes would later authenticate my correct workmanship).

Undoubtedly, because of those experiences, I am eager for every edge I can get in making reviews happen more quickly and effectively for both the content developers and reviewers. For business reasons, it matters greatly to me that we need to be extremely efficient in our use of resources (people and tools). Even more, I take great satisfaction in knowing that there are now

  • tools that help developers and reviewers be more effective
  • processes that enable better collaboration
  • decisions and communication that drive efficiencies, and most importantly:
  • people who will enthusiastically participate when engaged in the right way

Flexible Personality Type

How do we strike the balance? How do we get enough quality into the content through effective reviewer participation without damaging those same relationships in the process? We have a variety of approaches at our disposal. Each somehow requires that we become organizational theory experts, project managers, and psychoanalysts. Depending on individual capacity for flexibility and determination; some of us have become role-playing geniuses. I have seen content developers of a variety of personality types go totally out of their personal norms to get reviewer participation.

One normally reclusive writer became an absolute warrior to get people to review. While typically very reserved, she seemed to take great pleasure in publicly excoriating anyone who missed a review handoff or gave incomplete input. At one point, she even attempted to put the company COO in her place. This woman rightly earned the nickname Rambo. Did she get results? Absolutely. Would I recommend her approach? Not generally – although there are times when it may be appropriate. It worked for Rambo: people stepped up in fear or did whatever they could to avoid her entirely. For the long term, I don’t think that her approach would be positively recognized in many businesses.

On another team, the writing lead was pretty challenging in a unique way. Joan had a winning personality; she encouraged and got good participation through positive means; and the content results were great (winning STC awards). But, somehow, people got through the project feeling like an exhausted army. The issues didn’t revolve around input – they were related to decision-making. As Joan received review inputs, she kept coming up with new ways to structure, illustrate, stylize, or change the content. This frustrated reviewers, writers, and illustrators as each review pass presented them with a significantly different document to review.

One fun fellow with whom I worked with was “to-the-point” Jim (I have cleaned this up). You always knew where you were with Jim. He wasn’t arrogant, rude, or judgmental. He was direct, honest, and specific. Not in a negative way. You knew that it was all about getting the best results with Jim. He knew his stuff. Jim’s strongest trait was getting the results quickly and effectively for all concerned. Jim engaged reviewers on an as needed basis: he didn’t want to waste their time or his unless they were key to getting the content right. I think the characteristic that people really respected most from Jim was his demonstration that he valued their time.

Another example is the training developer who was very facile in her approach. JRo was excellent (academically and by application) at the craft of training development. She had extensive experience with the target training audiences. And, she had subject matter expertise on par with many development engineers. Rather than being arrogant or territorial, JRo maintained a positive team-oriented approach to getting things done. She never let her knowledge or capabilities interfere with her ability to work with others. I saw JRo break through language and cultural barriers, helping a man who had poor command of the English language become a top-ranked instructor. I have seen her work with an egotistical service manager, who didn’t value what she was doing. She was able to get the feedback she needed to develop training of award-winning quality. Without subordination or self-deprecation, JRo adopted different approaches or roles to engage her participants.

On one end of the spectrum, Rambo’s success was due to her assurance that she was right; that to reach her goals, anyone she needed input from was subordinate; and that any failures of others should be treated in a negative manner. On the other end of the spectrum, JRo’s success was due to balancing her priorities with those of her extended teams, helping others achieve their goals, and striving for mutual success. She did it by being resourceful, creative, and flexible.

Every one of us has a unique personality and character. And, to go too far into a mode or style that is alien to us is likely to create internal personal conflict and the probability of failure. I do not recommend that everyone adopt the JRo persona or any specific approach. Instead, I recommend that we consider the reviewers’ perspective and priorities. By looking at their primary roles, organizational, or business constraints and their job approach, you can craft some pretty flexible review conditions that will yield excellent results. So, let’s explore some of the issues as seen from the reviewers’ viewpoint.

Reviewer’s Point of View

Nancy was a hardware engineer who also really knew the firmware on one of our products. Because of her knowledge, she was heavily used by her managers for a variety of leadership tasks. Nancy worked long hours, had a demanding home situation with a husband, three elementary school age kids, two dogs, and the list goes on. Because of her knowledge, she was really the best engineer for our reviews. Nancy was also very committed to the quality and usability of our content. At that time, we were implementing online review processes. We had a real problem. Nancy was heavily loaded, exhausted, and her eyes were tired from her online work. But, she was still motivated. Nancy told me “Ken, I really would like it if once my husband and I have the kids off to bed, I could just sit there, in my jammies, in front of the fire, with a glass of wine and a printout of the document and help system.” I didn’t offer to light the fire or pour the wine. But, I eagerly printed the content for her to take home and review. She provided some of the best input on that project.

One team of reviewers was swamped with final code development and literally did not have time to start reviewing until the submittal to QA. Since the situation meant that inputs could not come until the last four weeks of the project, I knew that it would really put some pressure on the writing team. Even major attempts at bribery (thank you Starbuck’s gift cards) failed to get more than spotty reviews. But the team knew that we were serious about getting their inputs and we were willing to bribe made them feel valued.

During this low input period, we discussed possible ways with the engineers to make the review process fly once they were free to review. We set up an online location for the documents, so that the engineers could pull them down for local review. We enabled online commenting in Acrobat Reader. We listed the names of reviewers for each document, and moved their names to a completed column once the engineer was finished. We set clearly defined cutoff dates, which we renegotiated as needed. We maintained a willingness to accept input in any format: pdf, print, fax, bug reports, emails, and desk walkthroughs – whatever they could do. We were determined, eager, and open. Both the engineering manager and writers on the team said that the review was the best and most thorough review ever conducted on the product. And, we got a huge amount of input. By reinforcing to the reviewers the value of their participation, while respecting their earlier workload, we got their participation and reviewers the value of their participation, while respecting their earlier workload, we got their participation and increased respect for our work.

On the same project, some service engineers were reluctant to review. They had a very different issue: motivation. They felt (rightly or wrongly) that their inputs were never integrated – so why bother reviewing? We dug deeper into this issue with the engineers and their manager. Bugs submitted by the service team had been ignored: review comments and emails seemed to go unanswered. Documents were infrequently updated, and not to the level the service engineers wanted. As a result, the service engineers would post-process the documents. They disassembled the manuals they received and put together new ones based on what they felt should be documented and inserted the corrected information.

What had precipitated this situation? The original writing staff had been very small, and their management had insisted on infrequent revisions to the documents to try to manage the workload of the staff. The writers were working heroically on a large set of documents. They were understaffed. The perception of the service organization was that the writers didn’t care enough to include their inputs and create documents that were of value to customers. That rift had existed for nearly three years.

We stopped, listened, and probed on this issue with the service engineers, and we re-engaged them. We had the fortunate circumstance of a period of nearly four months during which we could apply extra writers to the project. We convinced the service engineers that this was the opportunity to provide the inputs to get the documents to a higher level of completeness and accuracy. They were reluctant to participate at first. But, once the writers engaged with them, they were convinced. The writers reviewed concepts, walked through procedures, and iteratively reviewed sections and documents. We converted the service manager from detractor to advocate. He told his engineers to stop developing the customized documents based on the success of the process.

What is common to these examples is that we listened to what the reviewers had to say. We engaged them on their terms, with respect to and for their roles, goals, and priorities.

Communication is Key

There are whole projects, or some projects when for a period of time, priorities just don’t align with getting good review feedback. And, for some projects, you may not have the bandwidth to incorporate the inputs. It is important to recognize when these issues occur.

And, it is frequently (but, not always) important to communicate about them. There are times when communicating an input or resource problem would antagonize a bad situation. You need to read the business circumstances. The song, The Gambler, is apt: “Know when to hold-em, know when to fold-em, know when to walk away, know when to run.” Based on circumstances, you may need to communicate narrowly or broadly or not communicate. Or, just start looking for alternate employment.

But, in most circumstances, there are usually ways to get reviewer participation. Consider the concept of the stakeholder from the project management discipline. The stakeholder is someone who has something to win or lose based on the results of a project (or a part of a project). There are a number of possible stakeholders for information projects.

  • End User/Customer
  • Customer Service (Implementation) Engineer
  • Support/Call Center Engineer or Technician
  • Service and Support Manager
  • Marketing Engineer and Manager
  • Financial Manager
  • Development Engineer
  • Quality Engineer
  • Business Unit Manager

Each of the stakeholders has different responsibilities and roles. Some do not participate directly as reviewers. Instead, they may be vital in getting someone to review. Each stakeholder looks at information products differently. And, each has different job pressures. When someone does not participate in a review process, it is time to consider how each values information and what else is going on in his or her professional domain. In these instances, rather than applying general rules or a standardized email requesting participation, you need to consider what will change behavior.

For someone who seems unwilling to review, it may be a matter of timing – or – it may be that they don’t see a reason to participate. If it is a matter of timing, there could be several solutions: wait for a better time, engage their management to see if priorities can be shifted, or, look for an alternate source. For someone who doesn’t see a reason: education, bribery, or escalation could change their behavior.

As much as we need to consider audiences for the content we are creating, we need to consider the reviewers. It is a dimension that stymies many information developers. But, this is an increasingly important skill area in the information-development profession. The key to success is direction of skills that are already in the information development toolkit: research, openness, creativity, and extreme flexibility. The challenge is to hone and apply those skills to reviewers and other business participants. Successful information managers and developers have come a long way from the days of the typewriter. Those want to succeed in the future will need to excel in these and other collaboration disciplines. CIDMIconNewsletter

About the Author


Ken Jercha

Ken Jercha is a Senior Documentation Manager at Aquent, with over 20 years management experience in information development. Ken has directed documentation, training, usability, localization, and marketing communications programs spanning a number of computer and communication technologies. Ken’s team successes include: award winning content, simultaneous release of content in up to 32 languages, and up to 90% reuse of English and translated content. These goals were achieved using solid project management disciplines and breakthrough processes to shorten program lifecycles and reduce development costs.