Approval doesn't cost ten minutes. It costs eleven days.

The expensive part of a human approval step is not the reading. It is the waiting. We have argued that reviewing a machine-written post takes about ten minutes a week, and we stand by that figure. The number that actually breaks a publishing schedule is a different one: how long a finished post sits between ready and live.

Workload and latency are separate costs, and only one of them gets counted

Ten minutes of work can carry an eleven-day wait, and nothing about the ten minutes explains the eleven days. The work is small. The queue is not, because it runs against exactly one person's week.

Do the arithmetic on a blog that publishes weekly with one approver who reads on Friday afternoons. A post finished on Monday waits four days by design, and that is the healthy case, with nobody ill, nobody travelling and nothing urgent landing on Thursday. Now take that approver out for a fortnight in July. The schedule does not slip by two weeks and then resume. It slips, and then everything arrives at once, which is precisely the burst pattern we have argued is worse than a slower steady rhythm.

Teams measure the ten minutes because minutes are what a manager knows how to count. Almost nobody measures the elapsed hours between "this was ready" and "this was live". That second number is the one that predicts whether the blog is still running next spring.

One default for every post is why the default gets ignored

We have said before that an approval step needs a stated default: what happens when nobody answers by the cutoff. That advice is right and it is not sufficient, because most teams try to pick one default for the whole blog, and neither available option survives contact with a real week.

Set the default to hold, and the blog stops the first time somebody takes annual leave. People notice, decide the rule is unreasonable, and start overriding it. Set the default to publish, and sooner or later a post goes live restating a price that changed in March. People notice that too, and the rule is suspended pending a review that never concludes. Either way you end up back where you started, which is a queue with no default at all and a nervous person guarding it.

The error is upstream of the choice. A single default has to be simultaneously safe enough for pricing claims and relaxed enough for commentary, and no such setting exists.

Sort the queue by risk, not by seniority

Two classes are enough. A post that makes a checkable claim about your product, your pricing, your customers or an unreleased plan blocks until a named human says yes. Everything else publishes on schedule unless somebody stops it. The classification is made when the subject is chosen, not after the prose exists, so it costs nothing at the moment it matters.

Most teams gate everything because gating feels like the responsible default, and underneath that feeling is usually a worry about machine authorship itself. That worry is misplaced. Google's spam policies describe scaled content abuse in terms of producing many pages that provide little value in order to manipulate rankings, and its guidance on helpful content is about whether a page serves the reader — not about who or what typed it. A blanket gate on every post buys anxiety relief rather than safety, and it charges eleven days for it.

What blanket gating does buy is protection against the genuinely dangerous posts, and those exist. We are not arguing that the blocking class should be empty. We are arguing that it should be small enough that one person's absence does not stop the other four fifths of the blog.

Move the decision earlier and it stops being a queue

The deepest fix is to approve the plan rather than the prose. A month of subjects, reviewed in one sitting before anything is written, converts twelve separate blocking decisions into one — and it puts the human judgment where it changes the output most, which is upstream, at the brief.

Once the subjects are agreed, the approval that remains is a check on execution rather than a check on intent, and execution checks are the kind you can safely make asynchronous. The practical version before a holiday is unglamorous and works: sit down for twenty minutes, approve the run of subjects that will publish while you are away, and nominate one deputy for the blocking class only.

What this changes

Start measuring the wrong thing on purpose. Not minutes spent approving, but hours elapsed between finished and live, tracked for a month. The number is usually embarrassing, and it is the only one that moves the publishing schedule.

Then state the default, split the queue in two, and put the human decision at the brief. None of this removes the approver. It removes the dependency on the approver being at their desk this afternoon, which was never the same thing as editorial control, and only ever looked like it.