Technical reviews are an essential part of the documentation process, ensuring that content is accurate, clear, and useful for its intended audience. However, these reviews often come with their own set of challenges. Building on the general advice offered in “Strategies for interviewing subject matter experts” by Nicoletta A. Bleiel (tcworld magazine, April 2025), this article explores five specific challenges that technical communicators could face during technical reviews and suggests strategies for addressing them.
Challenge 1: The MIA Reviewer
Consider this challenge with lead engineer Bayne:
Bayne is the lead software engineer on your project and has the best breadth of knowledge about the project of anyone in the company. So, you anxiously await Bayne’s comments because they always provide helpful insights.
But you also anxiously await Bayne’s comments because there’s only a one-in-three chance you will receive them. Even though you have negotiated review dates with Bayne, adjusted schedules to accommodate Bayne’s availability, and sent a lot of reminders, Bayne fails to review two of the three drafts that you have sent.
In reality, some Subject Matter Experts (SMEs) don’t read the drafts sent to them, even if they’re supposed to. In some cases, they approve the draft without reviewing it, leaving you and your organization vulnerable to liability claims in case of undetected errors. In other cases, the SME ignores the deadline and efforts to solicit reviews from them, resulting in schedule delays. This type of review is what we call “MIA” – Missing in Action.
To address the MIA Reviewer, first consider the reasons behind their lack of engagement in reviewing the material. Admittedly, in some cases, the SME is simply lazy and just doesn’t feel like reviewing. In other cases, SMEs don’t see the value in the review process and choose not to participate, much less acknowledge this decision to opt out.
But most likely, the SME is simply overworked and does not have the time to closely read the draft. Consider Bayne from the scenario above. As the lead software engineer, he likely has numerous documents to review besides the documentation, including product specifications, marketing literature, approval memos, and so forth. He also has to lead a team, which involves extensive work.
So, how do you deal with the MIA Reviewer? If the SME signs off on your document without providing comments (or very few), ask your manager to send a follow-up note that (a) thanks the reviewer for their time (yes, it’s not likely that they spent any, but taking the positive path almost always yields benefits), (b) notes the few comments on the draft, and (c) says you appreciate this vote of confidence in the excellence of the draft. You assume that no technical errors will be found later and if they are, the SME and their manager are responsible for addressing the impact.
In the likely case of the overextended SME, consider adopting one or more of these strategies:
Advance planning
Set review dates well in advance and add them to the SME’s calendar. Even if the SME does not accept the calendar invitation, it appears on their calendar anyway as an unavoidable reminder.
Send early and frequent reminders
Remind reviewers of upcoming reviews through several communication channels at least one week and one day in advance of sending the review material. While the material is out for review, send reminders about when and how to return comments. Make sure that, at least one of those reminders, is sent the day before and another the morning of the review (only one if the reviewer is more reliable.) And have notes ready to send each day the review is late.
Send these reminders not only through email (which people ignore) but also through text messages and internal social media platforms (but not public ones that are not part of the workplace).
Although you want to avoid the fine line between reminding and stalking, research has shown that the person who requests the most attention is usually the one who gets it.
Provide only what is needed
Second and third reviews often focus on changes to specific passages rather than an entire draft. One way to effectively use the time of reviewers is to only provide those passages that require a close review, reducing reading time and focusing the reviewer’s attention on the highest value material.
Schedule a read-and-review meeting
Schedule an in-person meeting with the SME to conduct the review with you. Go through the draft section by section. This ensures a dedicated time for the review (which might otherwise pose part of the challenge to the SME) and that you correctly incorporate the comments while the SME is with you.
Challenge 2: The Mystery Reviewer
Consider this challenge with SME Tripp:
Tripp is a subject matter expert who oversees certain aspects of the application programming interface (API). You prepare documentation about the API, on which other software developers rely to create working applications that integrate with yours.
After the last review – the second of three drafts – Tripp had left only a few comments, just small clarifications here and there. You quickly incorporate those comments and think the draft is ready for its next review.
But when you go to lunch the next day, a friend of yours who works with Tripp casually mentions that Tripp is actually rewriting the code for several aspects of the API, which will require extensive changes to your work. Maybe the changes weren’t ready before, but you still feel that Tripp should have disclosed this to you.
You’re about to distribute the next draft to Tripp, but now you lack trust in Tripp’s ability to provide complete and accurate information to you. What can you do differently with this review?
Another challenge is when SMEs withhold information in their reviews. Sometimes, the reasons are benign. For example, the reviewer might be aware of proposed changes to the system but, because they are not yet confirmed, feels it premature to change the documentation. Or the changes might have been approved but the reviewer did not realize that they could affect your content. Or the reviewer was in a rush and accidentally forgot about the possible impact of the change on the content.
Less benign reasons involve the reviewer purposely omitting the information, possibly as part of a larger agenda but more likely due to some animosity towards you.
To address the Mystery Reviewer, consider adopting one or more of these strategies:
Get to the point
Ask targeted questions in a cover note to the draft or within the draft itself intended to elicit information about updates to the material. As one of the specific questions, ask which technical changes are under consideration but not yet fully approved.
Set up a meeting
Schedule a meeting following the return of the comments with the Mystery Reviewer and their manager to specifically make sure that the information provided was complete and to identify any likely changes that could affect the next draft of the content.
Test your content
Also, develop your ability to check the accuracy of your descriptions. For example, the Docs As Tests approach described by author Manny Silva in a book of the same name describes how technical communicators can test their content against the most current versions of software to immediately spot inconsistencies between the two.
Challenge 3: The Editor
Consider this challenge with lead engineer Wayne:
Wayne is a technical reviewer who takes his reviews seriously. He reads every word thoroughly and returns drafts with extensive comments. Wayne finds a number of technical issues that need to be addressed and often offers even more editorial comments, ranging from typographical errors to complete revisions of sections that reflect Wayne’s approach to technical writing.
Although you appreciate the fact that Wayne reads the drafts so closely, you find his editorial suggestions mildly annoying and, sometimes, very annoying. Although he occasionally finds a typographical error, the majority of his suggestions focus on writing in “Wayne style,” which reflects an outdated, developer-centric approach to technical communication.
Your responses to Wayne’s comments primarily argue about style.
As you prepare to send yet another draft to Wayne to review, you would like to find a way for him to focus on technical issues and refrain from making editorial ones. How do you do that?
Wayne is a self-perceived “Editor” who considers rewriting the content part of his role. Some of such Editors limit themselves to editorial comments. In their defense, they might lack clarity on their role as technical reviewers. But Wayne also provides useful technical comments alongside the extensive editorial ones.
To address the Editor, consider these strategies:
Send targeted, technical questions
With the cover letter to the review draft, include specific technical questions that guide the SME to focus on critical technical points without ever mentioning editorial ones. For emphasis, highlight the sections or paragraphs and place the technical questions beside them to focus attention.
Clarify responsibilities
In the cover letter, inform reviewers that the draft is also reviewed by either an editor or another technical communicator to ensure that it is editorially correct and consistent with the other content in your library.
Accept the unavoidable
Recognize that Editors cannot help themselves. It’s almost second nature. Some of their edits can be helpful, like major typos and grammatical errors, even though stylistic changes will often contradict the style guidelines of your organization.
Rather than stopping the Editor (which is like stopping humans from breathing), respond to specific editorial comments as follows: “Thank you for your comments. I will take them under advisement.”
Challenge 4: The Family Feud
Consider this challenge with reviewers Jayne and Jocelyn:
Jayne and Jocelyn reviewed the Frequently Asked Questions (FAQs) you had prepared for the new Human Resources policies and procedures. Jayne is an HR manager; Jocelyn is the lead HR policy specialist.
The two disagree on every point. If Jayne says something is blue, Jocelyn says it is green. The contradictions make an accurate revision nearly impossible.
Readers expect technical content to take a definitive stand, something that disagreements among reviewers prevent. Such disagreements usually emerge because the SMEs interact with the material from different perspectives. In the case above, manager Jayne might focus on treating similar cases with similar responses, while HR specialist Jocelyn works directly with employees and has a greater awareness of the variation in cases. Their different perspectives lead them to different feedback, which can be contradictory.
To address a Family Feud, consider these strategies:
Bring the parties together
At the beginning of the meeting, raise the differences and play the role of a neutral mediator, not taking sides.
- Start the meeting by noting where agreement exists and identifying specific disagreements that need to be resolved.
- If fewer than seven disagreements exist, address them individually.
- If more than seven disagreements exist, walk through the content from beginning to end, stopping at each point where a disagreement exists.
- When addressing points of disagreement, begin by explicitly stating your understanding of what each party has suggested and where the disagreement lies. Have the parties work through the issue until it is resolved before proceeding to the next issue.
Mediate
If the parties cannot meet together, then meet individually with them, focusing on points of disagreement. Get the first reviewer’s preferred wording for the correction, then show it to the second reviewer. If the revision is OK, use it. If not, ask the second reviewer to revise to their satisfaction and share that version with the first reviewer.
Challenge 5: The High-Speed Advocate
Consider the following challenge with product manager Laine:
Laine is the product manager at a medical device company. She wants to bring a product to market in record time and, to do that, Laine needs you to complete all the documentation in six weeks, even though company processes and government regulations require substantially more time. How do you respond to Laine’s request?
An initial glance suggests Laine has requested the impossible. But Laine’s request might involve more than what appears on the surface, so begin by probing why she has requested completing the documentation in six weeks. The issue could be that she just wants a draft of the content within six weeks, not ready-to-publish material. Or she hasn’t considered some important details like an emergency approval from a regulator. By asking why she’s in such a hurry, you might also learn that she lacks full awareness of the approval process. Most importantly, asking for the underlying reasons lets you learn more about Laine’s motivations before actually responding.
After learning about the reasons for the request, address the High-Speed Advocate by considering these strategies:
Resolve misunderstanding
If the issue emerges from a misunderstanding of the request – such as just needing drafts rather than finished materials – you can respond more knowledgeably.
If the issue emerges from the SME’s misunderstanding of the approval process, you can address the misunderstanding. When doing so, ask questions such as “Had you factored in regulatory approval into that time frame?” rather than saying “You didn’t think about regulatory approvals.” This allows the SME to save face if they have overlooked factors.
Focus on what’s possible
If the request is indeed valid but impossible to fill, focus on what you can provide in that time frame, but note which work will remain incomplete.
Closing thoughts
Central to resolving each of these challenges is clear, neutral communication that begins with an open mind, and asking the reviewer to elaborate on the situation. In some cases, the issue stems from a simple misunderstanding that you can help to clarify. In other cases, specific issues might cause the problem requiring specific tactics to address the challenge at hand while also preserving the long-term working relationship with the SME.
The series will continue with an article exploring the dual roles that many SMEs play in the design and development of technical content: the person who has the information that technical communicators need to share with their audiences and a member of the organization that is the client for the project – that is, the organization that commissioned the work. This requires a balancing act to address the SME’s role as technical expert and project client.