Parkinson's law and the action with no finish line
Give a person a week to write a one-page memo and the memo will take a week. Give the same person an hour and, somehow, it takes an hour. The memo did not get worse. The deadline just got honest.
In 1955, Cyril Northcote Parkinson published an essay in The Economist about the British civil service. It opened with a line that has outlived the essay: work expands so as to fill the time available for its completion. He meant it as satire, a dry observation about how administrative staff multiply regardless of how much there is to administer. Seventy years later it's quoted mostly by people who are about to tell you to shorten your meetings.
The meeting advice is fine. But the more interesting place the law lives is a lot closer to home: your own list of actions, where the time available is usually "whenever" and the finish line is usually "it feels done."
An action with no edge expands in every direction
Take "write the proposal." How long does it take? Nobody knows, including the person who wrote the line. It can be a forty-minute job or a three-day agonising one, and the only thing that decides which is how much room the day offers. A wide-open afternoon gets a wide-open proposal, with a competitor analysis nobody asked for and a typography change at 4 p.m.
This isn't laziness, and it isn't perfectionism exactly. It's what happens when an action has no edge. There's no size, no stopping point, no moment when you're allowed to say "that's it." So the work does what water does with a bigger container.
We've written before about writing an action you'll actually do, and most of that is about the start: a verb, an object, a first move. Parkinson is the other end. A good action also says where it stops.
Three ways to give an action an edge
None of these need software. They just need you to be slightly rude to your own optimism.
Cap the time before you start, not after. Write the budget into the action. "Draft proposal, 90 minutes, rough is fine." Deciding in advance is the whole trick, because once you're mid-draft every extra paragraph looks like a bargain. If you want the calendar version, our guide to time blocking covers how to protect the slot.
Name the finished state. "Done" should be a thing you could show someone. A page that exists, an email that's sent, a number that's in the sheet. If you can't describe it, you can't recognise it, and you'll keep polishing past it. The same idea scales up in a definition of done for small teams.
Shrink it until it fits one sitting. If the honest estimate is three days, it isn't one action. It's a few of them, and each can have its own edge. Splitting big projects into actions is the practical version of this.
The counterargument: some work should take longer
Fair, and worth conceding properly. Parkinson's law is a tendency, not a physical constant. A hard problem does not get solved faster because you wrote "45 minutes" next to it, and a deadline set too tight produces rushed work that comes back as rework. Nobody should timebox a diagnosis, a negotiation or a first draft of something genuinely new into submission.
The useful move there is to cap the effort, not the outcome. "Spend two hours on the approach, then decide whether to continue" is a legitimate action. It admits the work might be bigger, and it still forces a checkpoint where you look up and ask. That's different from an open door that nobody notices is open.
Why the estimate is the weak link
There's a catch. A budget is only as good as the guess behind it, and we're famously poor at guessing; the planning fallacy has that covered. The fix is not a better guess. It's a smaller commitment. If your 90 minutes turns out to be wrong, you find out in 90 minutes rather than on Thursday, which is a much cheaper time to learn it.
What this looks like on a board
On a four-column board, Mine is the place where the law does its quiet damage. Everything in it is supposedly yours to do, and with no edges, five cards in Mine can quietly mean five days. A cap on how many sit there at once, along the lines of personal work-in-progress limits, pairs well with a time budget on each one: fewer actions, each with a visible end.
Then use the weekly review as the audit. Look at what took twice its budget. That's not a verdict on you, it's data about which kinds of actions you chronically underestimate, and after a few weeks the pattern is usually embarrassingly consistent. Mine is anything with the word "quick" in it.
Try one this week. Pick the action you've been circling, write the time you're willing to spend on it directly into the title, and write what finished looks like. If it's done early, congratulations on beating a law that's older than most of your software. If it isn't, you'll know exactly where the edge was missing.