Review and Approval Workflows
How to work efficiently and sanely.
The Writers' Table — article 4B
A draft goes out for review. One reviewer responds immediately with six detailed comments. A second never responds. A third responds three weeks later with comments that contradict the first. You send a follow-up. You send another. Eventually you make a judgment call and publish, and two weeks later someone finds an error that reviewer two would have caught.
This is a workflow problem, and it’s yours. And like most workflow problems, it responds better to structure than to effort.
Some of that structure is obvious: named stages, clear assignments, real deadlines. But the delays that cost the most are not the ones a better follow-up email fixes.
The draft lifecycle
A draft passes through a predictable set of stages: initial draft, technical review, editorial review, legal or compliance review where applicable, final approval, publication. Most organizations run these informally, which means they run them whenever someone has time, which means they run them inconsistently.
Formalize the stages. You do not need a six-page process document. You need enough detail that everyone involved knows what each stage requires from them and when.
Then define what each reviewer is responsible for. Technical reviewers assess accuracy: is the information correct? They are not responsible for grammar, style, or structure. Editorial reviewers assess usability: can the target reader follow this? Legal reviewers assess risk.
At one integration platform I worked on, docs went out to a required reviewer list — product, support, and engineering, all three on every draft. That is more reviewers than I would normally recommend, and it worked anyway, because the three roles were looking for different things. Engineering checked whether the described behavior matched the build. Support checked whether it answered the tickets they were already getting. Product checked whether it described the feature we were actually shipping. Three reviewers with distinct assignments generate three kinds of feedback. Three reviewers with the same vague assignment generate an argument.
So when you send a draft, tell each reviewer what you need. “Please check for technical accuracy. I am not asking you to edit the prose” is a clear instruction.
The stall you cannot fix with follow-ups
The docs lived in their own repo, separate from the code. That separation is convenient for a lot of reasons, and it creates one specific problem: nothing forces the docs to move in step with the feature. A docs pull request can sit open indefinitely while the thing it documents changes underneath it.
That’s what happened. A draft of mine stalled for two weeks, and I spent a good part of that time doing what you do when a review stalls — following up, escalating, wondering which reviewer had dropped it. None of them had. The feature was not finished. The reviewers could not confirm behavior that did not exist yet, so they did the reasonable thing and said nothing.
No amount of deadline discipline fixes that. The draft was not late. It was in limbo.
I attended engineering standup and stayed in daily contact with the team. Standup is fifteen minutes and most of it does not concern you, but it tells you when a feature slipped, when an API response shape changed, and when something is close enough to real that a draft is worth writing. I stopped sending drafts into a queue and started sending them when engineering was ready to look at them, after considering current status and information.
That is the version of “send drafts that are closer to done” that works. It is usually stated as an editing problem — fix the structure before you send it, so reviewers are not doing your developmental work. True, and worth doing. But the more expensive version is sending a draft the reviewer is not yet able to evaluate. You cannot detect that from inside the docs repo. You detect it by being in the room where the build gets discussed.
If you are not in standup, get in. If you cannot get in, find the person who gatekeeps and convince them you need to be there.
The reviewer who never responds
Deadlines help. “I need your feedback by Friday” beats “please review when you have time,” which gives reviewers permission to push it to the bottom of the queue indefinitely. A specific date also creates a basis for follow-up: “Your feedback was due Friday. Can you get to it Monday?”
But deadlines only work if missing one has a consequence, and in most documentation workflows it has none. The writer waits. That is the whole consequence, and it falls entirely on the you.
Write down what happens when the date passes. The workable default is that silence is recorded as no objection: if a reviewer does not respond by the deadline and does not ask for an extension, the draft moves forward and the record shows they were given the opportunity. State this in the review request, not after you invoke it.
Two things make this defensible rather than reckless. First, the reviewer has to know the rule before the clock starts. Second, it has to be recorded — in the PR, in the ticket, somewhere durable — so that “nobody reviewed this” is answerable with a link. In a regulated environment you will need that record anyway.
Feedback that is not yours to take
Clear assignments reduce out-of-scope feedback. They don’t eliminate it. The technical reviewer will rewrite your prose. Someone will use the review to reopen a product decision that was settled a month ago.
Say no in the thread, in one line, and keep moving. “Good catch, but that is a product question — taking it to the PM separately, not blocking this draft.” “Style is my call here; flagging anything inaccurate is exactly what I need from you.” You’re not refusing the feedback. You are refusing to let it hold the draft hostage.
One convention that saves more time: the writer closes comment threads, not the commenter. If reviewers resolve their own comments, you lose the record of what changed and why, and you inherit the job of figuring out which threads were actually addressed.
Conflicting feedback
When two reviewers say opposite things, resolving it unilaterally creates problems downstream. Document the conflict instead: “Reviewer A says X, Reviewer B says Y. I need a resolution before I can finalize this section.” Send it to both, and to whoever owns the subject matter.
This moves the decision to the people who own it. It makes it a product call rather than a judgment call you make alone and defend later.
Put a deadline on the resolution the same way you put one on the review. Conflicting feedback should not become a reason for indefinite delay.
Final sign-off
Some organizations require formal sign-off before publication: legal or regulatory review, product approval, a manager’s signature. If yours does, build it into the timeline rather than treating it as an afterthought.
What kills timelines at this stage is discovering late that a required approver has never seen the draft. Do not send a document through ten reviewers and then hand it to a final approver cold. Loop approvers in early, even informally. “Here is the draft. Full review goes out Thursday, but I want you to see it now so the approval is not a surprise.”
One tooling note
Do not send drafts as email attachments. An emailed draft produces multiple downloaded copies on multiple machines, comments that cannot be merged, and a reconciliation problem that lands on you. A shared link such as in Google Docs, in Confluence, or in a pull request gives every reviewer the same document and keeps feedback in one place. An added benefit is that reviewers may see other SME comments and respond to them in the document.
The reviewer who edits a downloaded Word file and emails it back is the source of a disproportionate share of review-cycle pain in organizations that still work this way. Switching to a shared link does not fix every review problem, but it eliminates that one completely. If you are docs-as-code, the pull request is the review tool, and comments attach to specific lines, permanently, on the version being reviewed.
The tool matters less than picking one place for feedback and declining to accept it anywhere else. A reviewer who emails you notes instead of using the shared doc is not saving time. They are eating your time and creating more work for you.
Further reading
Google, Engineering Practices Documentation at google.github.io/eng-practices — the sections on reviewer standards and review speed are the clearest published argument for treating review latency as a team problem rather than an individual failing. Written for code, applies directly.
Write the Docs, Documentation Guide at writethedocs.org/guide — practitioner-maintained guidance on structuring review workflows for docs teams.
Docs Like Code, Anne Gentle— the pull-request-as-review-tool argument at length, including what changes when writers work in the same systems as engineers.
GitLab’s public handbook — an actual organization’s documented review and approval process, which is more useful than principles.
What You Can Do
Map the last documentation review you were part of. For each stage, write down the date it started and the date it ended.
Find the longest gap. Then answer one question about it: was the draft waiting on a reviewer, or waiting on the product?
If it was waiting on the product, the fix is not a better follow-up email. It is knowing sooner.
Next: Documentation Frameworks: A Field Guide — the Diátaxis framework and the four content types that make documentation usable. Most writers mix them up and wonder why users can’t find what they need.