- I once had my boss at a new job sit me down, a couple of weeks into the job, and tell me "Matt, we have a pace that we work at, and we need you to work at that pace... If leadership gets the idea that we can deliver at a much faster pace, they'll expect it from us all the time." By the time I quit that job, I was able to finish my whole week's work before lunch on Monday. Then I'd just spend the rest of the time working on exploratory projects to stay sharp. So I've seen the utterly pathological version of Parkinson's law. However...
Shipping the wrong thing fast is just shipping the wrong thing, and it's a natural impact of trying to squeeze blood from a stone.
I often give something along the lines of this lecture:
You're trying to solve a $5M problem for $1M, so you're going to push people to make poor choices that don't actually address your problem, and it's going to end up costing $10M after they back up the train and re-lay the tracks. In many cases, the "shortcuts" that teams jump to end up being "longcuts" that drag the program out due to being insufficient to address all of the feature requirements, unplanned due to rushing, etc.
- I worked at a major cloud provider and saw this first hand.
When I started, I was really bothered by the fact that everything took so long. I had joined from a startup where there was time/financial pressure. Everything needed to be done now, and there was incentive to get it done.
The cloud provider was the complete opposite. Everything was slow. Things that should take a day took a week, things that took a week took a month. I rationalized it that there were more checks in place, more i's to dot, more t's to cross.
But in hindsight, it was the domino effect of Parkinson's law in play. The cloud provider had enough money to keep paying everyone in perpetuity; that removes financial constraints. Time constraints could be explained away. So things just got done whenever they got done. The knock on effect of this is that when you depended on other teams, they got around to their external responsibilities whenever, that then slows you if you depended on them.
The larger organization accounts for this by expanding timelines (because what else are directors/vp's/etc to do... they're powerless to actually implement), which are then just filed with more waste.
- Different people are motivated by different things. Some people are motivated by pressure. Some people are motivated by rewards. Some people are motivated by solving problems. The trouble is, if you blanket apply a strategy that some people find motivating, you risk under-motivating and even demotivating people who are motivated by different things.
Personally I am motivated by solving problems, which strongly implies shipping working solutions. I find artificial deadlines, theatrical recognition ceremonies or financial rewards that amount to a rounding error on my compensation to be demotivating. Everybody is different.
- I like this idea in theory. It seems to be empirically a good observation. I do take issue with the solution though.
Maybe it comes down to how you model the minds of those around you, but I notice a pattern in articles like this, that the solution seems to be presented as universal. In my experience, deadlines, especially self-imposed ones, are very effective for some (say 40%) of people, but they're not a panacea.
Wouldn't it be nice if there was some more general theory that explained Parkinson's law, and suggested various solutions that will work for various people?
> I love deadlines. I love the whooshing noise they make as they go by. - Douglas Adams
- I am not completely convinced. The biggest problem is that if you teach "Parkinson's Law is real" to managers, they will have a tendency to set unreasonable deadlines and it will hurt everybody.
Of course, saying "we don't really care, we can release in 10 years" is on the other end of the spectrum.
The thing is, it's absolutely not true that developers fundamentally don't care about their work being released. If they don't give a shit, I would argue that it's a company problem, not a lack of deadline. Because if you set extreme deadlines and your developers don't give a shit, they will just produce crap to meet the deadline.
Management is not about tricking your minions into working more. It's about making sure that your employees do give a shit. All the developers I know (myself included) are happier to provide a good product to clients than to never release anything or release crap. But if you put me in a situation where I don't give a shit anymore, and we end up in an adversarial scenario: I will manipulate my manager to protect myself. I will optimise for my own sanity (it includes keeping my job and not burning out). And I am pretty sure that managers don't like this idea, but I would complete TFA by saying: "manipulating your manager is real, so use it (if necessary)".
- I think this article misses the mark about deadlines.
The main problem with deadlines isn't that they're "poorly applied". It's that typically they reflect other people's priorities, which don't align with yours.
If the deadlines completely match your most efficient prioritisation scheme, then they will work, but you don't need the deadlines in the first place (unless you're lazy, but this is not what we're talking about; when we talk about Parkinson's law and inefficiencies we assume good-will from the outset). As soon as you introduce a deadline, you're basically introducing a change in the distribution of your work, which may lessen one particular item of work, but overall increases the Shannon entropy of your work distribution.
Consider the following. You have guests arriving in 1 hour. You need to clean (45 minutes) and cook (15 minutes preparation time, and 45 minutes roasting in the oven). If left to your own devices, you'll start with food preparation, and then use the baking time to clean. Bang, you've made the deadline.
The problem comes when your wife demands the house be cleaned first. Congrats. You've just made your guests wait 45 minutes for food.
Most externally imposed deadlines have the same effect. They ensure the 'cleaning' is done way faster, and completely disregard the spillover this causes. Typically because they may not even care about the other tasks in the first place; except in the sense that they care about the next deadline they set to you getting missed because you were dealing with previous spillover (which they don't care about).
Paradoxically, this makes people set stricter and stricter deadlines, in order to get people to work "faster". Which of course only causes more spillover and makes things grind to a halt instead.
- As a procrastinator, however, I can definitely say that the corollary is not true: work doesn’t shrink to fit available remaining time.
Therefore, setting arbitrary deadlines as advocated in this article is the worst possible idea. It will only lead to deathmarching your teams to project collapse, especially on long-winded endeavours.
To me, the best way to proceed is let the team define small increments, and work with your reports to debug the issues they have in building them. No deadline is needed for that, just fine-grained involvement, focus on the workflow, and frequent discussions to see if the most recent stuff in progress is still valuable.
The solution to expansion of work is cutting less-valuable tasks, setting deadlines is just the lazy answer for uninvolved or unskilled managers.
- The author misses something crucial - for this to work the the right environment must be established first. Without a supportive and healthy culture, tight deadlines can do more harm than good.
To succeed, teams need an environment where:
- Mistakes are seen as opportunities to learn, not as reasons for punishment. This fosters confidence and creativity.
- People feel recognized and valued, rather than being treated as just another cog in the machine.
- Management is transparent about goals and decisions, building trust and aligning the team's efforts with a shared vision.
Equally important:
After periods of intense deadlines teams need time to:
- Fix hasty decisions made under pressure.
- Reduce technical debt.
- Explore and experiment with new tools or technologies to improve their skills and boost morale.
Without this foundational culture implementing the author's ideas risks creating a toxic work environment.
Tight deadlines in the wrong setting can lead to:
- Extreme stress and burnout, resulting in slower progress or higher turnover.
- Decision paralysis, or as I like to call it "team freeze". Especially if people lack confidence in their abilities or fear making mistakes.
- Fragmented collaboration, where rushed individual contributions fail to integrate into a cohesive whole.
- Misaligned priorities, particularly if management operates from an "ivory tower" and imposes deadlines that seem arbitrary or disconnected from reality. This can create uncertainty. Worst case this may create rumors about financial instability, distracting teams from their work.
- A loss of individual potential, as workers who feel unrecognized are less likely to go above and beyond or contribute unique ideas.
Additionally, if deadlines become the norm without breaks teams lose their drive and motivation. The pressure of constantly sprinting leads to diminishing returns while unresolved technical debt creates long term pain points in the software. Over time this can result in teams feeling like they're digging themselves into a hole with no opportunity to climb out.
- I think people in this thread are imagining two different scenarios: a high-pressure environment with deadlines that are consistently 50% shorter than what’s actually needed throughout the year, leading to burnout... versus setting a desired completion date for your tasks as a personal challenge to keep things moving and avoid analysis paralysis. It’s more like a rally driver setting a target to stay focused and push forward.
- In some ways, the "5 day work week" is a deadline - things need to get done before Friday.
This "deadline" is a forcing function for output.
But do you know what's a better deadline?
The 4 day work week.
It may seem silly - but artificially making the workweek shorter, makes us work faster.
It's Parkinson's Law in action.
- One of the most impactfult things I ever picked up was to put a rough estimate on every task I'm doing and then plan my day/week according to it. In its essence, its just timeboxing. But I kept getting better at estimating the real effort necessary to complete a task which in turn made me a lot better at prioritizing.
An important side effect is that it changed the way I work: I focus on the outline first and use the remaining time in my timebox to gradually refine my result. At the end of the timebox, I have the best working result I could achieve within my estimate.
The combination of timeboxing, better prioritizing, and outlining / starting with an end-to-end prototype did wonders for my productivity and stress levels.
- I had a somewhat repugnant second-level boss whose philosophy was to give people a little more work than they thought they could do to get the best performance out of them, and I believe he was right since, at least for me, I worked harder to make the earlier deadline and/or did more than I thought I could. He must have known Parkinson's.
That only went so far, since piling yet more work onto someone who made an earlier deadline may get them to the point where they don't perform.
Which is why I appreciated a not-for-profit company where they'd actually ask me if I needed more time, since quality was of utmost importance. At that point at that company I knew the codebase, so I'd consistently over-estimate and deliver early, since there was still a chance of hidden impacts/requirements.
- Deadlines are hard to talk about when you have radically differently skilled developers.
Sure, it may take some on the team a half hour to do some work, but for others, it will take two weeks.
You hope that over time everyone improves, but that’s just not what happens in reality with bad eggs.
- One very useful outcome of setting relentless deadlines is forcing engineers, who are rather prone to overengineering and analysis paralysis, to just do 'good enough' and unblock themselves.
Its a mental trick to get them to focus on outcomes instead of the journey. Far better to let them mutter darkly about perceived 'technical debt' that is incurred delivering business value than to actually let them try and do things their way :D
This doesn't absolve management of picking the right problems to solve etc, nor absolve engineers of solving those problems in a competent manner.
But what it does is make good engineers work on the right thing, because lots of engineers have a tendency to not see the business wood for the trees and go off solving the wrong problems if self-organising.
Of course it is not nice to be an engineer and see how, as a generalisation, we can all be manipulated like this :)
- The article is absurd. If work doesn't have a deadline, creating arbitrary ones for the sake of having a deadline doesn't make the output have higher quality, less risk, etc. It just means you "hit a deadline". Its frustrating even more so when you end up shipping features that a year later you find out were never used, but you "hit the deadline" so its a "success".
- I'm cofounder of https://talkjs.com, and I strongly disagree. We do not believe that Parkinson's Law universally holds, and in fact we do not use deadlines at all. If I'm not mistaken, the standard lore goes as follows:
1. Work is awful and people hate doing the work they get assigned
2. Therefore, people will try their best to do as little of it as possible
3. Thus, if there's no deadline, or the deadline is very lenient, then people will mess around to fill the time -> Parkinson's Law!
Turns out that if you stop the military carrot & stick model of work, and instead try to actually be a place where people want to do great work, then this dynamic changes completely. We do it like this:
1. Make sure every employee does some amount of customer support. This makes everybody feel that real people are facing real problems that need real solutions, fast.
2. Give people a lot of freedom in what they work on, in what order, so long as it fits broad company objectives. If a customer reports a bug and it "nerd snipes" you completely, go for it!
3. Teach people scoping and iterative delivery. Stuff like "ship it when it's better than what's live now" (vs "ship it when it's perfect"). Many engineers like to polish things forever until it's perfect (this is the less cynical interpretation of Parkinson's law) but you can just coach people in this, takes a few months max.
I can honestly say that our dev team is the most productive team I've ever been a part of, and we do this without deadlines, without yelling managers who turn your estimations into promises, without overtime, and anything else like that. Parkinson's Law doesn't need to hold. It's a consequence of a shitty low-trust working culture.
Admittedly I've no idea whether our approach scales to larger companies - we're 15 people. Also we hire explicitly for people who are able to handle this kind of freedom. But it works excellently for us.
- While I appreciate reasonable deadlines; I hate people enforcing absurd ones.
I need to get this stuff done until tomorrow and then it will lie on your desk for 2 weeks?
No thanks.
- Conversely, a very tight deadline might well mean that the project/feature gets shipped - but corners will have inevitably been be cut and the chances of a major rewrite of the feature in the future will have been increased.
So it's important to get the balance right.
- > "A canonical example of this is sending round a survey that can be filled in whenever versus one that needs to be filled in by tomorrow:"
in my experience, setting a short deadline just means a handful of people will reply, the interviewer will extend the deadline and now in the future everybody knows the deadline will be extended anyway, so they don't bother taking your false emergency very seriously.
- I saw a great one slide corollary to this from a government program manager meeting once - basically, shorter time to first prototype drastically decreases overall program cost.
I think a lot of this has to do with giving the customer less time in which to change their mind.
Tangentially related to op - but, an interesting tangent nonetheless.
- Author might want to read peopleware, which had an entire chapter claiming that Parkinson's law does_not_ work for software projects.
The key take away is that Parkinson's law works on small tasks that don't fit into normal workflow. The author's examples are actually all this! The author gave the example of the due date for the survey. That's a 5-10 minute task. This is where the law applies. It means a task, as in, less than an hour of work, will get done on the due date. It does NOT mean that a project, a multi-person, multi-week thing, will get done on the deadline. So all the author's examples are correct, but then the author extrapolates to projects, and that's where everything falls apart.
- Cool but the only way I can stick to self-imposed deadlines is with medication. No amount of self-help and work philosophy can fix what's broken on a hardware level.
- There's a quote which I wish I knew the source, to the effect of "To accomplish great things, take smart people, and give them not quite enough time". Basically forcing them to come up with something clever to accomplish your goal in less time than expected.
- My issue with this kind of piece: a lot of words like "sometimes", "often", "really", "exact", and zero data.
- >Projects that don't have deadlines imposed on them, even if they are self-imposed, will take a lot longer than they need to, and may suffer from feature creep and scope bloat.
Another way to say this is;
>Projects that don't have deadlines imposed on them, will take longer, and may benefit from feature advancements and leave you with increased scope with the finished product.
Using words like creep and bloat to describe what is effectively a better solution to a problem is short-sighted and can lead to a false saving, as jobs that are rushed generally need to be re-done at a later date.
- C Northcote Parkinson wrote more books on how economics works. They're well worth reading.
https://www.amazon.com/Parkinsons-Law-C-Northcote-Parkinson/...
https://www.amazon.com/Law-Profits-Cyril-Northcote-Parkinson...
In-Laws & Outlaws (not on Amazon)
- I was once given this ridiculously short deadline to provide a full project. "We're going to be Agile and run this through Agile processes." I hadn't met the stakeholders yet (I would in fact not meet them at all) or even seen requirements. "How soon can you show me something?" I eventually had to pull out the "How fast does ten percent of a Porche run?" question.
Nobody ever wants a prototype. They think they do, the prototype mysteriously has to have all of its features and so on. And then they'll attempt to shove it into production right then and there.
I finished it by the deadline, despite having the flu and a blowing a non-trivial portion of the allowed time on a work trip that wasn't even relevant to my job, one I hadn't wanted to go on.
And then it sat on a shelf, unlooked at by anyone, for seven months. A lot of goodwill was burned up on that move. Fake deadlines mean to me that the person setting the deadlines does not understand urgency, when anything is actually needed, how to prioritize, or anything. It's a big sign that says I Am Not a Good Manager.
- Interesting to put this besides Hofstadter's law, which looks to be also real, which states "It always takes longer than you expect, even when you take into account Hofstadter's Law."
I don't think these need to be reconciled though as they are about different things: one is about imposing psychological threats to induce action and the other is about the inherent incapacity for humans to reason temporally concerning complex tasks.
One problem that arises though is that when tasks can't be sufficiently estimated, how do you reliably impose said psychological threats which don't turn into casual "oops, software's hard and is hard to estimate, hopefully better luck next time."
- Opportunity to say that other Parkinson's papers, and especially shorts and opinions that can be found in a book are both scientifically interesting and hilarious. A marvelous one is about importance of people and their physical trajectories in cocktail parties. A wonderful mix of social and economical sciences.
- Once I had a paid game project from a third party (who was a friend of my friend) who actually had the client. Either they gave me a 2-month deadline or I gave them one to complete the project, I don't remember it correctly.
I knew I could deliver it in 2 weeks or less, so I got busy doing other projects.
Long story short, client ran away because I didn't communicate with the third party the whole time through my friend (who I kept it in the dark) and delivered the first playable version not according to the exact requirements (how could I because it was not the final version).
I never heard/read about Parkinson's law at that time, I now understand I was just filling my available time with other stuff.
- It can work if you care about deadlines.
If you add daily deadlines to the daily meetings and hang daily motivational posters on the walls you risk blunting any and all responses to the daily managerial background noise.
- Huh. My Iron Triangle says "Fast | Good | Cheap - Pick two."
In all seriousness, I have found it is much better for me to push back on deadlines, especially those that are nothing short of arbitrary and imposed by middle/upper managers who have no understanding of the actual work involved. My results and reputation speak for themselves though and I can demonstrate that, historically speaking, I tend to produce higher quality output when I am given a blank check on time.
I would be a liar if I did not also admit that requires a healthy amount of discipline on my part and it took me years to develop that. I learned early on that the faster I complete my work, the more work I end up doing while my rewards do not increase, so moving fast is not a good strategy, to me. In fact, I work with a lot of people who have the "move fast and break things" mentality; not only are they arrogant bores that seem to only have a cursory understanding of their craft, but they leave insane messes that the rest of us have to clean up when they finally burn out.
So yeah, I'll stick with picking two
- In my experience this isn't as real as people think. More often than not, more resources increase scope which increases time.
Cutting all three too often results in things being delivered faster.
- I love parkinson's law because it was one of the first things I learned pretty soon out of college in a hybrid role as developer/PM in an extremely small startup, that was tasked with implementing "scrum" (Didn't yet know what that was outside of a few SE courses I had taken). I realized very quickly that no matter what I set sprint cycle length to be, about the same amount of work got done and at about the same quality. We started at 3 weeks and ended up at 1.
- I'm not a big fan of productivity tips, but I often read about Parkinson's Law, and it works.
Not setting deadlines means a paused journey—small projects take too long and eventually feel stagnant.
The first time I read about Parkinson's Law, I set extremely strict deadlines, which didn't work. Later, I switched to flexible deadlines, and I started working with a relaxed mind. As a result, I always get things done before the deadline.
- You can push only for so long before you burn out your team.
Sure they can skip meals, work crazy hours to meet your arbitrary tight deadlines. But this is a time ticking bomb.
- One thing that needs to be added is that this is all very true for each individual project, but once you start stacking project on top of project done a little bit fast, the cut corners can compound. So you have to make sure that some of those tight deadlines are for things that keep your systems maintainable.
deleted
- I use Parkinson’s Law to get less done. Because productivity is a disease, not a virtue.
- Most university students who have to finish assignments know that deadlines are indeed a blessing. Motivating yourself without a deadline is a rare gift that most of us do not possess.
- Let me introduce you to my friends bikeshedding and sandbagging
- have teams plan, execute, and report on what they've done weekly, writing up their progress in an update that is shared widely in a place that anyone can see
Isn’t that what a work ticket system does? Jira board or Kanban etc
- In theory, it works, but the issue is that creative work is inherently never finished.
- I've been burnt crispy by too many deadlines that didn't matter.
- This is PM propaganda. Deadlines help people is a huge double speak management fallacy. It may not be wrong in some contexts, but it’s very far from what I would call generally applicable advice.
I worked on a project in the defense industry where management gave us arbitrary deadlines with the expectation that bugs could be solved in 1-2 days. To solve any bugs in our system required a rearchitecting that would require two months, there was no way around that. The only thing you could employ otherwise were workarounds that would give you side effects. We got arbitrary deadlines put on us, but no go ahead to commit to real solutions. Implementing workarounds, then fixing the bugs caused by those workarounds in circles for a year. We passed most deadlines without consequence, and discovered all of them were fake. Rather than understand the problem we were solving and execute to real solutions, we were micromanaged by schedule people, and this wasted a lot of engineering time and taxpayer dollars. This was a consequence of the defense industry culture. It’s very top-down and hierarchical. Orders flow down without feedback. If there’s knowledge at the bottom, it’s never integrated.
> Putting challenging timeboxes on projects in a healthy environment can lead to serious innovation and creativity.
The author does concede that deadlines can be bad in toxic environments, but does not offer objective criteria for what is a healthy or toxic environment.
What’s missing from these Parkinson’s laws articles are what is actually happening in the time that is filled. We often hear criticisms of gold plating but that misses the point. The fact is that with any technical implementation, there is risk. What fills the time are risk mitigations. Things like if my api returns an error code, can I make my program fail gracefully. These things improve quality, they improve user experience, they are not understood or acknowledged by PMs and are completely ignored by schedule focused staff.
Risk is not modeled in the Iron Triangle plot in the article. Risk is not understood, or recognized by PMs. As a result, ICs are 100% responsible for managing it.
What makes a toxic environment? When PMs fail to take responsibility over their project. Whenever you’re having a conversation about schedule and deadlines, it’s not going to be informed unless you’re understanding your risk tolerance. Otherwise ICs are left guessing what’s actually necessary, and you get people who think throwing on arbitrary deadlines motivates people. It will waste your customers time and money.