Parkson's Law

One of my favorites when it comes to productivity laws
Roman Lamsal - 9/27/2021

There are many rules defined by smart people to describe organizations’ behaviours. One that I frequently experience myself a lot AND has an enjoyable backstory is Parkinson’s Law and it goes like this:

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

Parkinson first published this sentence in The Economist in 1955. He observed that, albeit the actual workload in Colonial Offices in the British Empire was declining, the number of employees was increasing.

What Parkinson’s Law tells us about our work

Most of us do not work at a Colonial Office of the British Empire - why should Parkinson’s Law matter?

The more time we give ourself with a task, the more time it takes to complete it. This is especially true for self imposed deadlines like the end of a sprint (in agile contexts), deadlines for your papers to submit or, most importantly, for meetings.

After learning and loving Parkinson’s Law (and annoying my wife with it), I searched for ways to improve productivity. Not by saving time but by cutting time needed. Sounds as simple as it gets, right?


It was more than satisfying to see “cutting the time needed” work it’s magic when applied to meetings. Instead of the usual 60 minute meeting, I always try to be gone after 30 minutes.

You are the one inviting? Set the meeting to 30 minutes.

You are being invited? Try your best to make it quick - discuss what matters, find a solution, leave once the meeting’s purpose is met. More often than not, I find myself earning a lot of agreeing nods when asking “are we done, can we end this?”. Especially in tech, where people might lack the courage to speak up for themselves.

Not everything can be discussed thoroughly in 60 minutes and sometimes the answer to the above question would be “no”. This is not necessarily bad, some things are just more complex than others.

Development tasks & socializing

Another field of my workday benefiting from Parkinson’s Law is separating focused development from interaction with others (pair/mob programming being the exception, as it encompasses both).

I get a lot of emails and chat messages from my colleagues, inside and outside of my actual product team, as I am often involved in activities across multiple teams. Parkinson’s really helped me out here again.

As an abbreviation of the Pomodoro Technique I try to focused on one thing for a specific interval with the intent to actually finish it in that time frame. Now that’s actually pretty hard to get right and the risk of just doing insane bullshit to finish the job on time is real. But with a little discipline it so often magically happens that you really finish what you were doing in exactly the time frame you were giving yourself. Remember:

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