Parkinson's law and software schedules

Deadlines change behavior even when nobody means to game the system. Give a team six weeks for work that could finish in three, and the calendar rarely comes back empty.

Work expands so as to fill the time available for its completion.

That sentence is how most of us meet Parkinson’s law. Cyril Northcote Parkinson published the essay under that title in The Economist on 19 November 1955, framed as a comment on the freshly published report of the Royal Commission on the Civil Service. The piece is satire about bureaucracy, not a controlled study of knowledge work. Parkinson’s argument is that headcount and internal process can grow without a matching increase in real output because officials prefer subordinates to peers and because mutual paperwork invents its own demand.

Software is not the British civil service, but the shape shows up often enough to be worth naming.

Padding and “just in case” estimates are sometimes an honest risk buffer. They are also an invitation. If the plan says four weeks and the gut says two, the extra time fills with refactors nobody asked for, another round of design polish, or scope that creeps in because the room still feels available.

A date on the roadmap is not the same thing as a bounded backlog. When “done” is vague, teams use the slack to negotiate scope with themselves. The work grows until it meets the date, not the requirement.

Parkinson’s second motor in the original essay is officials making work for each other. In product engineering that often looks like syncs, status layers, and review loops that expand to occupy whatever calendar remains once coding time is protected on paper only.

None of this implies that every long project is fake work. Some problems need the weeks. The useful move is to treat slack as a budget with an owner, same as headcount or dollars. Shrink the time box when the spec is tight, keep buffer when integration risk is real, and revisit the plan when the unknown surface area shows up instead of letting the schedule absorb it invisibly. How to estimate work like a senior software engineer is the longer playbook for turning guesses into something you can defend. The ninety-ninety rule is the blunt reminder that the tail of the work often carries most of the surprise. Hofstadter’s law is the recursive version of the same optimism.

Parkinson’s law is a warning about incentives and attention, not a license to strip every deadline down to heroics. Use it to ask why the calendar filled, not to pretend the work was always destined to be tiny.