Laws of PM Teams Parkinson's Law

Parkinson's Law

Work Fills the Time

Work expands to fill the time available — so generous deadlines mostly buy you polish on the wrong things.

Why PMs should care

Give a team six weeks, they'll use six weeks. Give them four, they'll probably ship in four — with less over-polishing, fewer edge cases covered that nobody would have hit anyway, and often a better outcome for the user.

When extra time is granted, it tends to go toward refactoring bits that weren't broken, covering scenarios that represent 0.3% of usage, and having a second opinion on every decision.

Shape Up uses Parkinson's Law on purpose with its 6-week 'appetite' and explicit scope-cutting — you commit to a time budget, and the team trims features to fit instead of extending the timeline.

The PM skill: set deadlines that are slightly uncomfortable, defend scope cuts when the deadline bites, and resist the temptation to be generous with time 'just in case'. Generous time budgets mostly buy more polish on the wrong things.

Example in product work

A 'simple copy change' on an email template gets scoped and estimated. Engineering says two weeks — 'we want to refactor the template engine while we're in there, and the translations will need a round trip with legal'. The PM agrees.

Two weeks later: the copy has changed, the template engine has been half-refactored, three other emails have been 'improved' while the team was in the neighbourhood, and one of them has a subtle regression that'll need a hotfix next sprint.

Counterfactual: same change scoped to two days with no refactor. The same two engineers would have finished it in two days. The extra time mostly bought rewrites nobody asked for and one bug the original scope wouldn't have introduced.

What to do when you see it

Sources & further reading

Back to all 59 laws