You give a designer a week to do a landing page that should take two days. It arrives on Friday afternoon. Nobody was idle. The designer was busy all week: three concepts instead of one, extra rounds of polish, a few hours on another client's urgent request, a rethink on Wednesday. The work filled the week because the week was there.
That's Parkinson's law, from a 1955 essay by C. Northcote Parkinson: work expands to fill the time available for its completion. It was written as satire about the civil service, but anyone who has run a small team recognises it.
For a service business it's not a curiosity. It's where margin goes. A fixed-price project quoted at 80 hours that fills its six-week timeline at 120 hours has lost a third of its profit, and nobody did anything obviously wrong.
How it shows up in small agencies
It rarely looks like slacking. More often it looks like this:
- Gold-plating. The task was done on Tuesday, but there's time, so it gets another pass. And another.
- Late starts. The deadline is next Friday, so the work starts on Wednesday, after other things that felt more urgent.
- Waiting without saying. Someone needs a decision, doesn't ask, and works on something else until the deadline forces it.
- Scope drift. With time to spare, people add things nobody asked for, which then need reviewing, which takes more time.
- Meetings at full length. A 60-minute meeting with 20 minutes of agenda takes 60 minutes.
The common factor is that nobody is checking progress between the start and the deadline. When the only checkpoint is the due date, the due date is when the work finishes.
Spotting it in your numbers
You can see Parkinson's law in your data if you log time against tasks with estimates. Look for this pattern:
| Task | Estimate | Due in | Actual | Finished |
|---|---|---|---|---|
| Landing page design | 12 h | 5 days | 19 h | Day 5 |
| Pricing page design | 8 h | 2 days | 9 h | Day 2 |
| Email templates | 10 h | 10 days | 22 h | Day 10 |
Tasks with tight timelines land close to estimate. Tasks with loose timelines run long and finish exactly on the due date. If your actual hours correlate with how much calendar time a task was given, rather than with how big it was, that's the signature.
In Suprwork, Projects & Time compares estimates with hours logged, person by person, which makes this pattern easy to see across a few weeks of work.
Five fixes
Tighter deadlines is the obvious answer, and on its own it's a poor one. Squeeze a timeline arbitrarily and you get rushed work, rework and resentment. These work better.
1. Make tasks small
A task estimated at two days or less has little room to expand. A task estimated at "two weeks" has lots. Break work so no single ticket is bigger than about two days.
Before: "Design website" — due in 3 weeks
After:
Home page wireframe — 4 h — due Mon
Home page visual design — 8 h — due Wed
Product page wireframe — 3 h — due Thu
...
Same total. Many more checkpoints. Each one is a moment when expansion gets noticed.
2. Estimate in hours, schedule in days
"Due Friday" tells someone how much calendar time they have. "Six hours, due Friday" tells them how much effort the work deserves. The second gives a reference point; if it's at ten hours on Wednesday, the person knows it's running long without anyone telling them.
Ask people to estimate their own tasks. Estimates people set themselves are more likely to be taken seriously than ones handed down, and comparing them with actuals over time teaches everyone, including you, how long things really take. There's more on this in why creative estimates are always wrong.
3. Define "done" before starting
Much of the expansion is polishing. If "done" is clear, there's nothing to polish towards:
Done when:
- One concept, not three
- Desktop and mobile
- Uses existing brand components
- Sent to client for review (not perfected first)
The last line matters. Getting work in front of the client earlier, for feedback, beats spending two extra days perfecting it in private and then revising anyway.
4. Make progress visible daily
The most effective fix is the simplest: a daily note of what each person plans to do and what got done. When the plan says "finish landing page" on Tuesday, Wednesday and Thursday, you know something's wrong on Wednesday, not Friday.
This doesn't mean asking each person for status. It means a short written update at a set time, every day, that you read. (Here's how to set that up without chasing anyone.) In Suprwork, Check-ins collects a morning plan and an end-of-day check-out from each person and gives you one summary, which makes a plan that keeps rolling over easy to spot.
5. Set intermediate checkpoints
For anything longer than a few days, agree a midpoint review:
By Wednesday lunchtime, share whatever you have, even if it's rough.
A midpoint review catches wrong directions early, stops gold-plating, and creates a natural second deadline in the middle of the timeline. Rough work shared early is almost always cheaper than polished work shared late.
The other side: leave real slack where it belongs
Parkinson's law doesn't mean every timeline should be squeezed to the minimum. Some slack is necessary. Client feedback takes days. Bugs appear. People get sick.
The trick is to keep the slack at the project level, not in each task. Estimate each task tightly and honestly, then add a buffer to the overall project timeline you give the client. When individual tasks have no padding, they don't expand. When the project has a buffer, the inevitable surprises don't blow the deadline.
| Approach | Task estimates | Project buffer | Result |
|---|---|---|---|
| Padding everywhere | +50% on each | None | Every task expands to fill its padding |
| Tight everywhere | Honest | None | Any surprise makes the project late |
| Tight tasks, buffered project | Honest | +20% at the end | Tasks stay small, surprises absorbed |
When it's not Parkinson's law
Sometimes work runs long for reasons that have nothing to do with available time: the brief was vague, the client keeps changing direction, the person is overloaded across four projects, or the estimate was simply wrong. Before you conclude that someone is stretching work, check whether those apply. If a project is running over for those reasons, spotting it early matters more than the cause.
This week
Pick one project that's running long. Look at its open tasks and split anything bigger than two days into smaller pieces, each with an hour estimate and its own due date. Ask the team for a daily plan and check-out on that project for two weeks. Compare how the hours land against the previous fortnight.