Parkinson's law is the observation that work expands to fill the time available. The useful response isn't a brutal deadline. It's a stopping rule: a checkpoint, fixed before you start, that forces a done decision while scope and quality stay where you put them.

The famous phrasing — "work expands to fill the time available" — comes from Cyril Northcote Parkinson's 1955 essay in The Economist, later covered in a BBC Radio 4 programme on the law. Parkinson was describing bureaucracies, and he was funny about it. Treat it as a heuristic about how open-ended tasks behave, not a demonstrated law proving shorter deadlines always improve output. There's no neuroscience here and no promise of saved hours. The claim here is narrower: a stopping rule gives you a moment to look at your work, worth testing on your own repeatable tasks.

Why the deadline itself is the wrong lever

Because a deadline set without evidence just relocates the stress. If you tell yourself the status note ships in two hours when the honest job is four (illustrative, not measured), you don't get faster work; you get the same work plus anxiety, or a thin draft you quietly know isn't done. The failure mode this post targets is the opposite: low-stakes work that never ends because nothing says stop. Hypothetically, a 10-minute status update becomes a 40-minute session, the extra half hour going into sentences with no named reader.

So don't halve every deadline. Pick a bounded review checkpoint from your own prior time on similar tasks, your median rather than your best day, and keep the quality checklist unchanged. The experiment is whether the checkpoint changes finishing behavior, not whether you can compress work.

The worksheet

One repeatable, low-risk task. A hypothetical works fine: an internal project status note you send most weeks.

  1. Define the audience and the required facts. Who reads it, and what do they need to decide or do? For a status note: what shipped, what's blocked, what's next. Three facts, not vibes.
  2. State what done means before you start timing. A concrete list: every required fact present, links checked, no placeholder text. This is your quality checklist, and it stays frozen for the whole test.
  3. Set the checkpoint from your own history. If these notes usually take you around 30 minutes of actual work, put the checkpoint at 30 minutes. Not 15. You're testing a stop, not punishing yourself.
  4. At the checkpoint, record: what's finished, what's still missing, and actual work time beside elapsed time. Elapsed is clock time since you started; actual work time is time on this task, so actively checking a dependency counts, while waiting on a reply and any unrelated detour count toward elapsed only. The two needn't match. Then log any review or rework after sending.
  5. Compare similar tasks over several runs. Five status notes with checkpoints against your usual habit on comparable notes. That's a personal comparison, useful reflection, not a controlled study. If essentials were missing at the checkpoint, do that work and run the review now, then move the checkpoint out for next time.

The reusable checklist

Run it at every checkpoint, in this order:

  • Finish: Are all required facts present? Anything still missing, name it specifically.
  • Quality: Does the frozen checklist pass — links, numbers, no placeholders?
  • Review: Am I about to reread a paragraph for the fourth time? That's polishing, not progress. Log the elapsed-versus-work gap and stop, but only once Finish and Quality pass. If either fails, don't send short: do that work and re-run this list.

Two things are never candidates for a tighter checkpoint: safety, legal, or security review, and waiting on an external dependency. A stopping rule applies to your own drafting, not to what a sign-off or an API migration legitimately takes.

When extra polish earns its keep

Here's a decision rule: keep polishing only if you can say beforehand who benefits and what they'd do differently. A client-facing report where the reader is a decision-maker: polish the executive summary, it changes what they decide. An internal note nobody acts on: the fourth font tweak helps no one, and that's scope drift wearing a productivity costume. Scope drift on a status note looks like adding a section nobody asked for; useful polish looks like clarifying the one sentence your reader would otherwise misread.

Where this fits with the other time problems

Parkinson's law is about stopping, which makes it easy to confuse with two neighbors. The planning fallacy is about forecasting — correcting how you estimate durations before the work starts. A checkpoint is different: a decision point during the work. And time-blocking schedules when work happens; a stopping rule decides when it ends. If your estimates are the problem, fix the estimate. If your work simply never ends, the stopping rule is the lever.

The whole method fits on an index card: required facts, done definition, checkpoint from your own median, plus what finished, what didn't, actual work versus elapsed, and post-send rework. Try it on one low-risk task five times. You'll learn how you actually finish work. If your notes say the checkpoint just made you rushed, that's a real finding too: widen the checkpoint or drop the experiment. No law, not even a famous humorous one, gets to overrule what your own notes say.