Each examines one law: where it came from, why it persists, and what to do about it.
Ask any program manager how long a project will take and you will get a number. Ask them where that number came from and the conversation gets quiet. The honest answer, more often than anyone admits, is that the number came first and the work plan was built to justify it. Cyril Northcote Parkinson saw this in 1955 and gave it a name that has outlived every methodology invented since.
The Law and Where It Came From
Parkinson’s Law states that work expands so as to fill the time available for its completion. Parkinson, a British naval historian, published the observation as a satirical essay in The Economist in November 1955, later expanded into the book Parkinson’s Law: The Pursuit of Progress (1958). His original evidence was bureaucratic: the British Admiralty grew its administrative staff by roughly 78 percent between 1914 and 1928 while the number of ships in commission fell by two thirds. The work did not grow. The organization grew, and the work expanded to keep it busy.
The essay was written as humor. It survives as diagnosis. Parkinson identified two engines behind the effect: officials want to multiply subordinates, not rivals, and officials make work for each other. Swap “officials” for “workstreams” and you have a reasonable description of most enterprise transformation programs.
Why It Persists in Engineering Organizations
Software work is unusually susceptible to Parkinson’s Law because software work is elastic. A feature can be done, done with tests, done with tests and documentation, done with tests, documentation, and a refactor of the module next to it. There is no natural stopping point. The stopping point is the deadline, and if the deadline is generous, the scope quietly grows to meet it.
Three mechanisms drive the expansion:
- Scope absorption. Slack time does not sit idle. It attracts nice-to-haves, edge cases, and speculative generality. The backlog senses vacuum and fills it.
- Coordination growth. Longer timelines justify larger teams, and larger teams generate their own internal work: syncs, status decks, alignment meetings. Parkinson’s Admiralty clerks writing memos to each other, reborn as recurring calendar invites.
- Risk theater. Generous timelines get consumed by activities that feel like risk reduction but function as delay: extended discovery phases, proof-of-concept cycles that prove what everyone already knew, review gates staffed by people with veto power and no accountability.
The AI era sharpens the problem rather than solving it. When agentic tooling compresses the mechanical work of coding, the elastic portions of the schedule, the meetings, the approvals, the waiting, become the dominant term. I have written elsewhere about the human-in-the-loop bottleneck, and Parkinson’s Law is its scheduling twin: automate the work and the remaining human coordination expands to fill the calendar the work used to occupy.
Case Study: The Nine-Month Migration That Was Estimated at Nine Months
The following is an anonymized composite drawn from patterns I have observed repeatedly in enterprise platform work.
A regional bank needed to migrate a customer notification service off a legacy message broker onto a managed event streaming platform. The engineering lead’s gut estimate was eleven weeks. The program office, applying standard contingency, socialized a nine-month timeline. Nine months is what leadership approved, so nine months is what the plan showed.
What happened next was textbook. With months of runway, the team decided the migration was an opportunity to also redesign the notification templating engine. A second squad was allocated, which required a shared design authority, which required biweekly architecture syncs. A vendor evaluation was added for an observability tool the platform team had already standardized on. By month five, the migration itself, the original eleven weeks of work, had not started. It began in month six under schedule pressure, was executed in ten weeks, and shipped two weeks late against the nine-month plan.
The post-mortem praised the team for landing “roughly on schedule.” Nobody asked why the schedule was nine months. The eleven-week estimate was never wrong. It was simply never tested, because the time available was nine months and the work expanded to fill it. The templating redesign, the artifact of all that slack, was quietly deprecated fourteen months later.
What To Do About It
You cannot repeal Parkinson’s Law. You can starve it of the thing it feeds on, which is unexamined time.
- Estimate work, then set timelines separately. Keep the engineering estimate and the committed date as two visible numbers. The gap between them is your contingency, and contingency should be held by a named owner, not smeared invisibly across the plan where scope can absorb it.
- Timebox aggressively at the increment level. A nine-month program made of two-week increments with demonstrable output resists expansion far better than a nine-month program with a midpoint review. Parkinson’s Law operates on whatever time unit you hand it. Hand it small ones.
- Make slack explicit and assign it. Slack is valuable. Unassigned slack is scope bait. If the plan has buffer, name what the buffer is for and who decides how it gets spent.
- Watch the coordination-to-construction ratio. When meeting hours grow faster than merged pull requests, the schedule is being eaten from the inside. This ratio is measurable and worth putting on a dashboard, with the caveat that any measure invites gaming, a subject this series reaches in Part 7.
- Re-estimate when capability changes. If agentic tooling cut your implementation time in half, your timelines should show it. Most organizations bank the productivity gain as slack, and Parkinson’s Law spends it for them.
The Architect’s Takeaway
Parkinson’s Law is not a claim that engineers are lazy. It is a claim that time behaves like storage: whatever capacity you provision will be consumed. The discipline is the same one we apply to infrastructure. Provision deliberately, monitor utilization, and treat unexplained growth as a signal, not a norm. The deadline is a design decision. Design it.
Next in the series: Hofstadter’s Law, or why the schedule slips even after you account for Parkinson.
The Laws We Ignore | Part 1 of 11
Next: Part 2: Hofstadter’s Law
