An article has been ready for two weeks. Three people have read it, all three left comments, two of the comments contradict each other, and nobody has said it can go out.
Nothing is broken. Everyone did their job. The process simply has no point at which somebody decides, so it does not end.
The fix is one rule and it is the highest-value change most small teams can make: one named person, decided in advance, says an article can be published. Everyone else advises.
Why a committee cannot approve
Not because the people are difficult. Because of what approval structurally is.
Approval is a decision, and a decision is a single act. Three people cannot perform a single act. What three people can do is express three views, and three views require somebody to resolve them, which means you still need a decider. You have just added a stage without adding a decision.
Three specific things go wrong.
Nobody is accountable. If an article that should not have gone out goes out, and three people approved it, nobody approved it.
Nobody is unblocked. Every reviewer waits to see whether anyone else objects, which is a queue with no front.
The bar drifts upward. Any of three people can hold something, so the standard becomes the union of three people’s standards, which is stricter than any of them intended and stricter than anybody agreed to.
The observable symptom is always the same: articles that are nearly ready, for a long time.
What the approver actually does
Narrower than people assume, and the narrowness is the point.
The approver answers one question: can this be published? Yes or no. Not “is it perfect”, not “would I have written it this way”, not “is there anything else worth adding”.
That question has a specific standard behind it, and it is worth agreeing the standard once: is it accurate, does it do the job the brief set, and does it meet the site’s basic requirements? Anything beyond that is an improvement rather than a blocker, and improvements are not what approval is for.
Approval is not review. Review says what should change. Approval says it can go. A process that merges the two without noticing is the one that stalls, because the reviewer’s instinct is to keep improving and the approver’s job is to stop.
Approval is a decision, not a document. A message saying “yes, publish it” is approval. A round of comments is not.
Choosing the approver
Four criteria, and the third is the one people get wrong.
They are close enough to the content to judge it. Not necessarily the most senior person. Seniority is not the qualification; knowing what the site is for is.
They can be reached. An approver who is unavailable for days is a bottleneck rather than a decider, and the process will route around them, informally and inconsistently.
They are willing to say no, and to say yes. The second is harder. An approver who cannot let something imperfect go out is not an approver, they are a second editor, and the process will stall on them.
They are the same person each time, for a given kind of content. Different approvers for different content types is fine and often correct. A rotating approver for the same content type is not, because the standard changes with the rota.
The disagreement, which is the real question
The objection to a single approver is always the same: what if they are wrong?
Sometimes they will be. The question is what that costs compared with the alternative, and the honest answer is that it costs less.
A wrong published article is fixable. You edit it, or you take it down. The cost is bounded and it is usually small.
A workflow that cannot decide is not fixable by trying harder. It costs everything that never ships, and that cost is invisible because unpublished work leaves no trace.
The way to handle disagreement is to move it off the article and into the standard:
Disagree before, not during. If somebody thinks the article should not exist, or should be different in kind, that belongs at the decide and brief stages where changing it is cheap.
Escalate rarely and explicitly. There should be a named person the approver escalates to, for the small number of cases that genuinely warrant it. “Rarely” is the operative word: an escalation route used weekly is a second approver wearing a disguise.
Change the standard, not the decision. If the same disagreement recurs, the standard is wrong. Fix it once, in writing, rather than relitigating each article.
What everyone else does
Advises, and that is a real contribution rather than a consolation prize.
Reviewers say what should change, specifically, before approval. Their input is genuinely valuable and it is input.
Subject experts flag accuracy problems, and an accuracy flag should always block. That is not a competing approval, it is information the approver needs.
Everyone else has opinions, which are welcome and are not a gate.
The distinction that has to be explicit: comments are advice unless the approver adopts them. If that is not stated, every comment becomes a soft veto and you are back where you started.
The bottleneck version
The other failure mode. One approver, and they are the constraint.
Three fixes, in order of preference.
Narrow the standard. Most approver bottlenecks are approvers doing review as well. If they are rewriting rather than deciding, the fix is upstream: someone else reviews, and they approve.
Split by content type. Different approvers for different kinds of content, each of them single for their type. This is not a committee; it is several single approvers with clear boundaries.
Introduce a default. Approval within a stated period or it goes. This works when the content is low-risk and it fails badly when it is not, so use it deliberately rather than as a general rule.
What does not work is adding a second approver in parallel. That is the original problem with more people in it.
Where this sits in the process
Approval is one stage among several, and it only functions if the stages around it are doing their jobs.
If briefs are vague, the approver receives articles that are wrong in kind and has to reject work that is already finished, which is expensive and demoralising and looks like an approver problem. A stalling approval stage is very often a briefing problem.
If the approver’s decision cannot actually be acted on, because publishing requires somebody else, then approval is not the last gate and the process has an unowned step after it. Whether that is your situation is answerable in an hour: can a non-developer actually publish on this? is the test, and if publishing needs a technical person, that handoff sits after every approval you will ever make.
One thing this article deliberately does not cover: who should have the technical ability to publish. Deciding the approval right and configuring permissions are different questions with different owners, and this page is about the first only.
Writing it down
Four lines, once, somewhere everyone can see:
- Who approves what, by name and by content type.
- What the standard is. Accurate, meets the brief, meets the site’s requirements.
- What blocks regardless of the approver. Accuracy, usually, and anything legal.
- Who the approver escalates to, and how rarely.
That is the entire policy. If it takes longer than four lines you have written a process for a larger organisation than yours, which is the same mistake as adding stages you will not perform. The broader case for keeping a small team’s process small, and the arithmetic behind why extra stages cost so much, is the argument this cluster is built on, and it is worth having settled before you design anything: when not to migrate a CMS makes the same point about platform decisions, that the cost of a change is dominated by what it multiplies rather than by what it adds.
The short version
- One named person decides whether an article can be published. Everyone else advises.
- A committee cannot approve, because approval is a single act and three people can only produce three views.
- The approver answers one question: can this go out. Not is it perfect.
- Review says what should change; approval says it can go. Merging them is the stall.
- Same person each time for a given content type. Different types can have different approvers.
- Handle disagreement by fixing the standard, not by relitigating articles.
- A stalling approval stage is often a briefing problem upstream.
