Parkinson’s Law

“Work expands so as to fill the time available for its completion.” — Cyril Northcote Parkinson, The Economist (1955)

The Claim

Tasks stretch to consume whatever time is allotted. A report that could be written in two days will take two weeks if two weeks are budgeted; it will take one hour if one hour is all that’s available. The bloat is not laziness — it is polishing, scope creep, reconsideration, coordination overhead, and re-reviewing work that was already good enough.

Parkinson’s Second Law (less cited)

Expenditure rises to meet income. A team granted a larger headcount budget will spend all of it. A project with a larger financial budget will spend all of it. Every resource becomes a ceiling that attracts use.

Why It Holds

Three compounding mechanisms:

1. No incentive to finish early. If the slot is two weeks, finishing in three days produces neither reward nor freedom (someone will assign more work). The optimal strategy is to use the full window.
2. Polish is infinite. There is always one more revision, one more review, one more edge case. Without a forcing function, the work cannot stop.
3. Meetings and coordination expand to fill calendars. The “open” hour in a schedule attracts a meeting. A “free” week attracts a project. The calendar has no concept of margin.

In This Wiki

• The opposing force to hofstadters-law. Hofstadter says projects take longer than you expect; Parkinson says they also expand to use the time you give them. Together they describe the estimation trap: if you budget too tight, you overrun; if you budget too loose, you overrun anyway, because the work expands. The remedy is deadline pressure plus explicit scope management.
• Explains goodharts-law failure modes. When the metric is “hours worked” or “time to complete,” Parkinson guarantees the metric gets gamed upward. The work fills the time; the time isn’t the work.
• Relates to brooks-law. Brooks says adding people to a late project makes it later, in part because every added person expands the communication graph. Parkinson’s Second Law is the budget-scale version: adding headcount expands the work to match.
• Relates to the ninety-ninety-rule. The last 10% of the code takes as long as the first 90% partly because Parkinson: with the bulk of the project done, the remaining time is freely available for polish, doubt, and minor rewrites.
• Complements narrow-bracketing. Small windows of time produce small scopes of work. Breaking a project into many small time-boxes limits the Parkinson expansion per box, even if the whole project still overruns.
• Connects to parkinson’s-second-law-less-cited (self) — in organisations, expenditure rises to meet income. Naval’s advice on keeping expenses low is Parkinson’s Second Law applied personally: if you earn more and spend more, you’ve achieved nothing. Only income-expense gap is real.
• Connects to leverage. Leverage (code, media, capital) breaks Parkinson because output is decoupled from time spent. A well-leveraged project’s constraint is idea-quality, not hours — and ideas don’t expand to fill time in the same way execution does.

Software-Engineering Manifestations

• Sprint bloat. A 2-week sprint produces exactly 2 weeks of work, regardless of the initial scope. The team commits to less if the sprint is shorter.
• Meeting culture. The meeting booked for an hour takes an hour. The meeting booked for thirty minutes finishes in thirty.
• Feature polish. The feature “done” on Tuesday will still be “being finalised” the following Monday if the release is Friday.
• Headcount growth. Every team that hires faster than it ships has Parkinson’s Second Law running unchecked.

Practical Defences

1. Shorter deadlines, not tighter ones. A two-day forcing function produces a different class of output than a two-week one.
2. Shrink the budget, not the ambition. Less time, less money, less headcount — same goal. Teams that hit the goal do so by cutting scope, which is usually the right answer.
3. Time-box aggressively. “We have two hours for this problem” produces a two-hour-sized solution. Often adequate.
4. Fix the calendar, not the person. Don’t blame the engineer who takes two weeks on a two-week project. Give them three days next time.

Parkinson as a Life Principle

Paul Graham’s writing on startups, Naval’s “keep expenses low,” and the general thesis that constraint drives creativity are all Parkinson-adjacent. Slack is expensive: unallocated time and money attract scope. The high-output operators are often the ones with aggressive forcing functions — short deadlines, lean budgets, small teams.

The dark mirror of this is obvious: unrelenting constraint also destroys people. Parkinson tells you slack will be wasted; it does not tell you slack is unnecessary. Good systems have intentional slack (margin for learning, rest, emergencies), not accidental slack (calendars nobody owns).

Sources

• source—laws-of-software-engineering — in the Planning cluster.
• C. Northcote Parkinson, “Parkinson’s Law,” The Economist (19 November 1955) — original essay.
• Parkinson, Parkinson’s Law: The Pursuit of Progress (1957) — book-length treatment.