“Parkinson’s Law: What It Is and How to Use It”

What is Parkinson’s Law, and where did it come from?

Parkinson’s Law is the observation that a task consumes the time allotted to it, regardless of how much time it actually needs. The line comes from an unsigned essay by the naval historian Cyril Northcote Parkinson, published in The Economist on 19 November 1955.

The opening sentence was “Work expands so as to fill the time available for its completion,” which Parkinson immediately called a commonplace observation. The rest of the essay was about something narrower: public administration growing regardless of the work to be done. He used the Admiralty and the Colonial Office as evidence, showing staff numbers rising while ships and colonies fell, and estimated bureaucratic growth at 5–7% a year “irrespective of any variation in the amount of work (if any) to be done.” The essay became a book in 1957.

So the famous sentence is a footnote to a joke about bureaucracy, and that matters twice. It is satire, not physics; treating it as an iron law produces bad decisions. But the behaviour is real enough to have been tested. A 1999 study by Brannon, Hershberger and Brock in *Psychonomic Bulletin & Review* demonstrated the personal version in a lab: participants given more time spent more time, without a corresponding improvement in the quality of their judgments. The extra time was absorbed, not invested.

Why does work expand to fill the time available?

Work expands through four mechanisms, and each has a different fix.

The quality ratchet. With no definition of done, every pass feels improvable. A deck can always get another round of font alignment. The task ends when time runs out, not when the work is good enough.

Self-interruption. A long window invites more switching. Open the report on Monday, close it, reopen on Wednesday, spend twelve minutes reloading context. Five sessions across ten days cost more attention than three sessions across two days.

Coordination overhead. Long timelines generate their own work: the check-in about the draft, the review of the check-in, the second reviewer added because there is time.

Deferred start. This is Goldratt’s student syndrome: people begin at the last responsible moment, so a longer deadline mostly moves the start date. The effort stays the same and the slack disappears into the beginning.

Together they explain a familiar pattern. A task with six hours of real cognitive work, spread across ten working days, does not consume six hours. It consumes six hours plus two hours of reloading, plus an hour of meetings about it, plus a week of low-grade background anxiety. The work did not expand because you were lazy. It expanded because time was the only boundary the task had.

How is Parkinson’s Law different from the planning fallacy?

They describe opposite errors, and a good plan needs both. Parkinson’s Law says your deadline is too loose; the planning fallacy says your estimate is too low. Fixing one without the other just moves the failure around.

The sequence is: establish a baseline from history, compress the calendar window relative to it, then protect the quality bar with a definition of done so the compression is absorbed by scope rather than by your evenings.

How do you design a deadline that actually holds?

A deadline changes behaviour only when it has five parts: an anchor, a compressed target, a consequence, a definition of done, and a checkpoint before the end.

The anchor is data, not intuition: the median of your last four or five runs at that task. The target is that median multiplied by 0.7 to 0.8. The consequence is what happens if the date slips — a client sees it late, a colleague is blocked. The definition of done is the sentence you would use if you had to hand the deliverable over in five minutes. The checkpoint is a review two-thirds of the way through, early enough to change course.

Example 1: the monthly client report. Say the last four reports took 5.5, 7, 6 and 6.5 hours of actual work. The median is 6.25 hours. Today the report occupies ten working days, because that is the gap between the data being ready and the client meeting.

The compressed design: a two-hour drafting block on day one, a ninety-minute review block on day two, and a hard 4 p.m. send. Elapsed time becomes two days instead of ten; the work stays around 6.5 hours. What you recover is not eight days of labour but eight days of the report sitting in the back of your mind, plus whatever meetings would have filled the space. Across eleven remaining cycles that is 88 working days of attention returned to other work, and the report does not get worse, because the definition of done was decided before the clock started.

What is the 70% rule, and when should you ignore it?

The 70% rule means scheduling about 70% of your honest baseline elapsed time and treating the remaining gap as the place where quality work happens. It is a heuristic for familiar, repeated tasks — the kind where you already know what done looks like.

The rule is often taught as “estimate how long it will take, then cut the estimate by 30%.” That is the wrong instruction. Cutting the *estimate* corrupts your forecasting and leaves you with a plan you know is false. Cutting the *elapsed window* changes behaviour while keeping the forecast honest: you still expect 6.5 hours of work, you simply refuse to give it ten days.

A more defensible version: compress to 75–80% for tasks you have done at least three times, and 85–90% for anything new, dependency-heavy, or reviewed by someone else. Fifty percent is usually not compression but denial.

Ignore the rule entirely for first attempts at unfamiliar work, tasks waiting on other people’s responses, regulated reviews with fixed timelines, and any exploratory phase where the point is to discover the question. Compressing discovery does not produce discovery faster; it produces a confident wrong answer.

How does timeboxing turn the law into a tool?

Timeboxing flips the law from a diagnosis into a mechanism. Instead of asking how long the work needs, you decide how long it gets, define the deliverable, and stop when the box closes.

Five rules make a timebox work rather than merely look organised:

1. One deliverable per box. “Work on the proposal” is not a deliverable. “Draft section 3 with the three cost scenarios” is.
2. A fixed end time, not a fixed start time. Starting at 9:00 is a hope; ending at 11:30 is a constraint.
3. A parking lot for out-of-scope ideas. Anything interesting but unplanned goes on a list, not into the box.
4. An extension rule. If you extend, you give something back — a section moved to next week, a slide dropped. Otherwise the box is decorative.
5. A visible record. Log actual time against estimate for a month. Without that, the 70% rule has no anchor.

Box sizes that map to real work: 25 minutes for admin and inbox triage, 50 minutes for meetings (which also creates the ten-minute buffer that makes back-to-backs survivable), 90 minutes for a deep block, one day for a diagnosis sprint, one week for an iteration.

What self-imposed constraints work in a normal week?

Self-imposed constraints are small structural rules that make expansion expensive. They work best when they are visible in a calendar or a task list, because a private intention is not a constraint — it is a preference.

• 25/50-minute meetings. A one-hour meeting is an hour because the slot is an hour. Shorten the default and most agendas still fit.
• Artificial early deadlines. Set the internal date 24–48 hours before the real one, so the real date becomes contingency rather than plan.
• Revision caps. Two review rounds per deliverable, stated in advance. A third round needs a named reason.
• One-in, one-out. Adding a commitment to the week requires removing one, which makes the cost of “yes” visible.
• A fixed shutdown. A hard stop at a stated hour, treated like a client meeting. Cal Newport calls the underlying practice fixed-schedule productivity: constrain the workday and let the constraint force prioritisation.

Example 2: the meeting arithmetic. Suppose you have eleven recurring one-hour meetings a week. Moving them to fifty minutes recovers 110 minutes a week, which is 84.6 hours across 46 working weeks — about two working weeks a year. That number is only real if the recovered ten minutes are not immediately refilled, which is exactly what the law predicts will happen by default. The buffer has to be protected deliberately, usually by booking it as a block called “no meeting.”

Where does Parkinson’s Law stop being useful?

Compression has a boundary, and crossing it converts a productivity gain into a quality debt.

Uncertain work. Research, debugging an unfamiliar system, a first draft of something genuinely new. Here the time is not padding; it is exploration. Compressing it produces anxiety and a wrong answer delivered confidently.

Quality-critical work. Legal review, medical documentation, financial reconciliation, safety checks. The cost of an error dominates the cost of the extra day. Compress the queue, not the check.

Work with external latency. Approvals, shipping, third-party reviews, hiring. Your window is not the constraint, and shortening your side of it just moves the wait.

How do you tell whether compression is working?

Measure four things over at least three iterations: cycle time from start to done, rework as a percentage of total effort, deadline hit rate, and the share of tasks that needed an extension. If cycle time drops and rework stays flat, the constraint is working. If rework climbs faster than cycle time falls, you moved the work rather than removed it.

Example 4: a three-sprint trial. A team shortens a standard five-day task to three days. Cycle time falls from 5.2 to 3.4 days, which looks like a clear win. Rework rises from 8% to 19%, which on a 40-hour task means 3.2 hours becomes 7.6 hours, and hit rate falls from 92% to 71%. On total effort the change is still slightly positive, but one task in four now misses — and a missed deadline in a dependency chain costs more than the hours it saves. The sensible read: three days is too tight for the quarter of the work involving external review, so the fix is a two-tier policy — three days for self-contained tasks, five for anything waiting on someone else.

What mistakes make people misuse Parkinson’s Law?

Fake deadlines that get moved. The first time you extend a self-imposed date, you teach yourself that your dates are theatre. If you must move it, pay for it by cutting scope.

Deadlines without scope. A shorter window only means something if something can be dropped. Without a stated definition of done, compression quietly becomes overtime.

Compressing everything equally, on other people, or as overwork. A blanket 30% cut makes creative work worse and data entry marginally faster, and used as pressure on a team it produces padded estimates. Fitting six hours into four is borrowing, not technique.

How does Doitify fit into a Parkinson’s Law practice?

Doitify is our product, so read this as disclosure rather than review. It is a workspace for projects, tasks, sub-tasks, checklists, owners, and due dates, with the planning layer included: Kanban boards, sprints and backlogs, roadmaps, calendars, Gantt charts, workload views, and work and performance reports.

What matters here is that the three things a compression practice needs — a window, a definition of done, and a record of actuals — live in one place. A task can carry a due date and an estimate, its checklist can act as the definition of done, and the work report can show estimate against actual across iterations, which is how you build the baseline the 70% rule depends on. Recurring tasks keep the monthly report from being re-planned each cycle, and a board with a work-in-progress limit makes “one in, one out” a rule rather than a Monday promise.

None of that substitutes for deciding to compress. A tool can show you that a task took 6.5 hours last month; only you can decide that this month it gets two days instead of ten.

Conclusion

Parkinson’s Law is not an argument for rushing. It is an argument for putting a boundary where there wasn’t one. The task that took ten days did not need ten days; it needed six hours and a stopping condition.

Start with one recurring deliverable. Find its honest median from your last four runs, cut the elapsed window to about 75% of the calendar time it occupies today, write the definition of done in one sentence, and put a review on the calendar two-thirds of the way through. Then measure what happened. If quality holds, compress the next task the same way. If rework climbs, relax the window for that category and keep the discipline everywhere else.

The constraint is the technique. Everything else — the app, the template, the timer — only makes the constraint visible enough to keep.

If this post on parkinson’s law was helpful, you might also enjoy Workplace Context Switching Statistics: The 2026 Data Guide and Time Tracking Project Management Tool.