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.
Basically stating the fact that people fail to see the value in reinvestment of time and resources for improvement. Being Idle is not a failure but a way to think and be ready if a period of higher intensity comes. And it is healthy to have sometimes more time for a menial task.
People get so crazy about the idea of optimization, but fail to account for severe issues that arise when time is always occupied by something, which seems to happen more and more these days...
> 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.
Work/life balance is a part of the compensation package. If you suddenly start expecting your employees to work harder, the most talented ones will simply jump ship, because from their perspective, if they're already forced to spend long hours on complex projects, why not at least do it for lots of money. So the only people who stay will be hard-working ones, but less skilled. Meanwhile, in a healthy company, you need a mix of people willing to do demanding, yet simple work, and those who rescue a dumpster fire of a project and then take five coffee breaks.
On the other hand, if you expect your employees to produce every week only what they can do in an afternoon and no more, many of the most talented ones will also jump ship, because they are motivated by accomplishing high-quality work.
It may have less to do with talent than motivation. Motivations people can have at work (and many can and do have a combination in different proportions) can include: making as much money as possible; doing as little work as possible; producing as high-quality work (in their own opinion) as possible; recognition from others for contribution; social relationships and/or being liked; learning new things and developing new skills; being challenged; not being challenged; being part of a collaborative team working well together or being left alone to work independently; etc.
But I think few "most talented" people would last very long at workplace GP described, where doing more than a half-day's worth of work in a week was restrained.
Intrinsic motivation can be better than extrinsic motivation. Google won a lot of fans and dedicated employees with its original version of 20% time that encouraged people to find stuff they were highly motivated to want to work on and could do so relatively safely in the company's sandbox. It is possible this sort "everything the company needs you to do can be done in one afternoon each week" could be an incredible "80% time" company. There are lots of people that would find "80% of my time at the company is my own" to be quite motivating.
Of course, certainly not in the example scenario above where one layer of management is effectively lying to another layer. That's not a healthy "80% time" when it involves duplicity and covert play acting.
But if you were feeling crazy enough to try to build an overt "80% time" company you likely wouldn't have a hard time finding some of the "most talented" people.
That's certainly how Xerox PARC is described in some of the tales of their classic discoveries/inventions/Demos.
Certain decades of Bell Labs, too, have that glimmer of a bunch of the smartest people allowed to explore stuff they cared about with only the oversight from fellow technical people.
I've even heard Microsoft Research can still sometimes feel a bit like that, though with all the pressures of academia like grant finding and patent applications and other such hustles.
This. Motivation is the key to getting employees to produce over a period of time. Give the good ones the maximum amount of ownership they can handle and they will set an example for everyone else. Grow the talent over time.
Fire the whinny shit-talkers as soon as possible. They drag everyone down.
> if you expect your employees to produce every week only what they can do in an afternoon and no more
... then they will have time to fix problems that arrive randomly, rework the parts of their work they got wrong on the first try, and study and train to stay sharp to do the next piece of work. Ironically, all of those will make them produce their next piece of work faster, making this one "problem" worse and worse.
But I left the real benefit to the end... those people will have enough time to think about how they can work into improving something on their workplace. You know, the people that actually do the work, how they can apply the work they know about, because they do it, instead of people that know nothing about it being specialized in thinking how to apply other people's work.
The GP saw a good manager trying to keep his people safe from a dysfunctional organization. The dysfunctional organization is a read flag, for sure, but it doesn't automatically mean the environment is a bad one.
Good software shops leave a good amount of "slack" time for their engineers. It's how you handle shit hitting the fan without burnout.
I currently work on a team that has been basically solving multiple crises per year for years now. In the blips where we've returned to normalcy, we didn't push hard. Because we knew that was time to recover because another crisis was definitely coming.
The crises were external / due to leadership being aggressive without our input..so at that point, all you can do is execute. And part of executing is resting.
Sandbagging is a superpower within reason under many circumstances. Most people would much prefer to get a quality promised deliverable on time or a bit early even if it's a bit longer than they would have preferred in an ideal world. (And, if they really do want to pull something in, you sigh and say you'll do your best but no promises.) If something really has a hard aggressive deadline, OK maybe.
But usually it's a case of it will probably take me this long to do a task. But there are some unknowables and someone I might have to lean on could have a sick kid for a couple days. Generally, everyone is happier if you underpromise and overdeliver including you.
An engineering manager I used to work with would drive me crazy because he had this idea of 90% schedules he got from somewhere. Which basically meant there was a 90% chance of meeting the schedule if nothing went wrong. (Which naturally mostly never happened.)
Sandbagging can also lead to nothing ever being worth doing.
Of course, it is shocking how many projects are started without anyone knowing anything other than the end date.
In my view, if the project is of such marginal value that a precise estimate is needed, don't even start the project - instead, find something more valuable to work on.
Maybe that's true of major projects, especially when there are maybe unknown unknowns. (And maybe not.) But there are a ton of deliverables that should be fairly predictable that come with people who have downstream dependencies on them. (Promotion, launch plans, etc.) When something is late it can cause a lot of scrambling and wasted time/money.
[And just to add, I'm mostly speaking to work I'm creating and delivering--for the most part individually. And to the degree that I'm depending on client reviews, etc. that's in the contract.]
The 90% schedule is not a bad idea, but you need to look at it via metrics - what percentage are you actually meeting that schedule? If you are not doing so 9 out of 10 times, you are at a 20% schedule or a 10% schedule.
No, it’s because Kirk respected Scotty and gave him leeway.
Picard is the meathead, if anyone, and actually watching all the episodes in detail and figuring out their characters you’ll realise that Kirk is twice the scholar and then some Picard pretended to be, especially accounting for the movies and later series. Kelvin timeline doesn’t count, of course.
I would say that it's practically a worse situation. They aren't just ignorant, but willfully so because of a lack of measurable consequences for most. Even worse when there is market capture.
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.
Relatedly, I think many people overestimate how hard it is to compete with the big players. People think that because they earn billions, they are unbeatable. But this is untrue! Scrappy, creative people who just go for it can often beat the big players. As a recent example, look at Cursor AI. Microsoft was in the PERFECT place to come up with Cursor. Microsoft had the most AI knowledge via their own teams and via OpenAI. They have enormous data centers for AI compute. They had the most used code editor (Visual Studio Code). And still Cursor came in and made a better product!
Jeff Bezos said "your margin is my opportunity". I think we can say the same for bureaucracies. Whenever there is a bureaucracy, think "your bureaucracy is my opportunity."
> And still Cursor came in and made a better product!
On a long enough timeline Microsoft wins this battle. I don't think you appreciate the inertia of market dominance and a massive existing user base. They can simply copy features and push them to millions of developers overnight. More likely, Cursor either gets acquired or becomes a niche alternative while VSCode maintains its dominance.
Competing with established players when you have zero moat is always tough and I don't think Cursor are even close to winning their category yet. Bureaucracies exist in large companies precisely because they've grown successful enough to need them. While they do create inefficiencies, they also enable consistent execution at massive scale - something startups often underestimate until they try to grow beyond their initial niche. It may be slow, but they win by outlasting, outspending or buying you.
However if you simply mean that Cursor can carve a niche quick enough to become an attractive acquisition target then I might concede that fact.
It seems like it ought to be reasonably restrictive to install some new AI tool on dev machines.
* they don’t know who’s behind it, what’ll it output?
* they don’t know the business model. Is will it be used to exfiltrate code from the company, aka train on the company’s codebase? Other text files you open?
I’m not at all saying I think Cursor is doing that—training on customer data would be a completely unethical business practice, bordering on malware, usually companies whose names get bounced around here are not so bad. But, the hypothetical host company doesn’t know anything about them, so it is prudent to require some checking.
I don't even use copilot (yet) because the process of reviewing it through all the different obstacles (security, legal, budget) is on it's 24th month or something. I think many people in traditional industry can relate.
This basically describes Slack vs Teams as a case study. Teams launches, Slack says "good luck with that," MS basically gives Teams away for free and gains market share, then SAP acquires Slack.
> On a long enough timeline Microsoft wins this battle. I don't think you appreciate the inertia of market dominance and a massive existing user base.
So Cursor shouldn't even have tried? It is pointless what they have achieved? That's what you're saying?
I disagree. Having people who know about your product and have a positive experience with your product can be very sticky. Coca Cola is a famous example. Also look at AWS. Microsoft has many of the benefits you said. Microsoft has scale, many existing relationships with customers, own much of the related software, and many more benefits. Still, AWS has a 31% market share while Azure has only a 20% market share. The gap becomes more narrow each year, but it's still not closed. There is definitely a huge benefit to grabbing market share by having a superior product. Even while you only temporarily have that.
You also talk about the economies of scale, but that was my point. Even while Microsoft had all the economies of scale, still Cursor came in and took a large part of the market!
Theory of the firm states that the corporation will get as large as coordination costs allow, but the other way to view that is that large corporations need to compensate for their increased coordination costs in some way.
Empirically, they can often do that successfully, as evidenced by the fact that large cloud providers are, indeed, large.
But you correctly point out that over time this almost guarantees opportunities for firms with lower coordination costs.
Is Cursor really better? I tried it briefly but bounced off. I’m convinced that AI-assisted search and replace would be quite nice sometimes, but not enough to switch.
Then again, I don’t use most features in Cody, either. Basic AI code completion seems good enough for me and the fancier shortcuts don’t stick.
I have mixed experiences with the "chat" portion of Cursor AI. The "composer" has been much, much better, albeit on greenfield projects. I haven't explored it too much with existing monoliths, but I suspect it might not fair as well.
I'm currently using it to build an iOS mobile game, using Swift. I've never coded in Swift, or used SpriteKit, but it's going surprising well. When it does produce invalid code, I just copy the error directly out of xCode into Cursor Composer and 9 times out of 10, it fixes the issue first try.
I've used it on different languages, but the rust it produces, even if it runs, is often full of bad decisions. Choosing improper data structures, cloning everything, etc. Curious what the quality is on the scale of "running swift" to "good swift".
I don't think so. The amount of features something like Google cloud has + experience is not cheap to just build.
Plenty of companies try in Germany the schwarz group aka Lidl and the German Telekom too.
Also normal companies are not fast. It takes time for them to learn about something new, understanding it and then implementing it before they finally can us it.
If Ms tells you they will do it in 1-2 years everyone is fine with that. And GitHub announced GitHub spark. Google has this already.
In a bigger organization you're further away from the actual mission of the organization, which eliminates the internal motivation to perform well, even in the absence of a measurable reward. For example, I'll always go above and beyond when doing something together with a close friend of mine, but I give zero fucks about my big corporation.
I believe that this is a problem with western societies at large.
The tempting efficiency of infant capitalism was its decentralized and small scale structure. You can’t govern a country top-down, and letting the people at the bottom do their own work is most efficient.
But now some companies are larger than most countries and we are back to where we started… but without transparency and democratic regulations.
I think we need better ways to deal with large systems and complexity.
There's the Chinese saying "Heaven is high, and the emperor is far away". The idea being that low level bureaucrats are actually the ones running the show. Effectively, that's where China and the CCP sit today.
However, that has similar issues to the ones I described above. Top down mandates, the low level feigns to appease them, but marginal progress is actually made. Instead of expanding the timelines as I spoke about, in the CCP(/Soviet) case, the actual accomplishments are made up to keep "going forward". Think of all the ineffective building done to meet bullshit quotas in the China currently. It harkens back to the Soviet era.
I completely agree. But the intend I wanted to capture was that if you have complete transparency over your own system, can act independently and are not bound by top-down mandates, this is where you have the highest efficiency.
This is identical to the idea of small scale teams working on systems they completely understand and own. This is where you have the most productive teams and it is the same in terms of bureaucracy. And the job of an architect is not to create "a beautiful system", but to lower the complexity of the overall system.
I think the topic of complexity and large systems is one of the defining ones of our time. Similar to entropy, you start with a low-state system where you can generate energy from putting entropy into the system. But with a higher state of entropy, your energy gains decrease.
We act like you can just pure more and more onto the same pile, but eventually, everything stagnates. And only collapse can create a blank slate.
It seems like the real problem is finding a way to address that.
We've seen this play out over and over. Take something like building and zoning codes. They start out doing something worthwhile, like requiring fire exits. But soon you have a bureaucracy micromanaging everything, imposing minimum parking requirements even on a building sitting on top of a subway stop, imposing minimum lot sizes or density restrictions, requiring unnecessarily costly or labor-intensive construction methods at the behest of device makers or trade unions, etc.
What you need is a mechanism, something like checks and balances or a challenge process that allows any rule to be repealed if it doesn't still have enough votes to pass in every branch, to inhibit that process of ossification and corruption and clear out the cruft accumulated by its past operation.
The problem isn't so much that you need to throw sand in the gears. We've eroded some of the checks there used to be (e.g. moving to US Senators having statewide elections instead of being elected by state legislatures) and maybe we should put them back, but in general the system of checks and balances works kind of okay.
The issue is that it's not perfect, and it's never going to be perfect, so you're occasionally going to have things get past the gauntlet and make it into law when they shouldn't. And over time those things accumulate.
So what you need is a functioning process for clearing out the cruft even once it's already there. Something like, make it much easier to repeal rules than enact them.
> What you need is a mechanism, something like checks and balances or a challenge process that allows any rule to be repealed if it doesn't still have enough votes to pass in every branch, to inhibit that process of ossification and corruption and clear out the cruft accumulated by its past operation.
I agree in the sense that some way of "caretaking" is absolutely necessary. Like in a badly maintained IT-system, many managers think you can just keep piling stuff ontop of the old system and you can just happily going forward forever. But of course that is a terrible misunderstanding.
In an IT-system, you either restart from scratch or start a refactor. I think these are the only options here either. This needs talent and money, something the public services have been massively drained of. You can't make a system more lean and efficient by cutting costs, you mot make investments. If you involve Civil Servants, they will tell you exactly what kind of issues they are facing each day processing official documents.
Ideally, you'd start a digital transformation of public services and also streamline the legal cruft at the same time. But the problem is that much of this "cruft" is there on purpose because somebody profits. Such as the impossible Zoning Rules in California to prohibit any additional housing space... because that would make housing more affordable and lower their prices.
That's not my point. My point is that overhead increases and efficiency decreases the larger your system is. And companies at the size of states are just as inefficient.
Ergo, the idea that the market handles their duties more efficiently is a lie. It has nothing to do with corporate vs state owned enterprise, but a matter of complexity.
True but also the sheer number of people now trying to use it. Other factors include the difficulty of getting an appointment with the first call GP (once known as the family doctor) and the utter madness of many A&E departments. They do a great job but can't cope. 12-hour waits are not unknown. I see no reason to expect a turnaround with the Labour Government.
It would seem building better systems is not enough. We must strive to maintain, continuously improve, and scale them to meet demand.
Sadly culture in the US is diluted into believing that profit motive is a silver bullet that fixes all problems. And many are raised in religions that teach one to deny critical thinking, embrace appeals to authority, and love confirmation bias.
I work in a large law firm and see similar outcomes, coming from a similar fast paced background.
I’ve drawn a different conclusion as to “why” though. Law firms are inherently risk averse. As such things do take time to dot the i’s, and that is more important than the time or financials.
I look at it through the project management lens of the three constraints: Quality, Time and Cost.
The law firm (and potentially your cloud provider) has prioritised Quality. Either Time or Cost take a hit.
High quality + quick = costly.
High quality + low cost = a long time.
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.
but those are orthogonal. and yes, everyone is different. i am also motivated by solving problems. but i also believe in the premise of the article that deadlines can help push me forward. personally i like deadlines to be set according to the value of the project, which can be its budget or some other externally motivated limitation.
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
One of the things I learnt about ADHD from my recent diagnosis is how it disrupts your perception of time compared to people without it. To me it doesn’t matter if there’s a deadline, my brain just does not perceive time in a way that makes it matter.
Of course I have strategies to manage this, and medication helps somewhat. But if I set a deadline for myself I’m never going to keep it.
My girlfriend has ADHD and she mostly only can get things done when there are deadlines outside of her control (e.g. cleaning up when we have visitors).
When she wants to do something just for her it can take ages, if it gets done at all.
I would like to help her with this but I don't really know where to start.
For 'time blindness' my personal solution is that I have a miband that vibrates periodically. I think most smartwatches have such a function.
I am an inattentive type who skated thru behavioral checks by being the quiet kid who never causes problems. What this really means is I am doing ranked competitive daydreaming and sometimes need to be reminded to exist.
In some cases, time pressure can focus me and get me to a solution faster, but I then need downtime to recharge. I don't think I've worked in that sort of environment since working in food service or at a movie theater.
Deadlines often just stress me because I can't effectively reason about the intervening time.
Partly because in practice, there's one group of people _setting_ deadlines and a completely different set of people responsible for them. I don't know how one moves into the deadline-setting ruling class, but it definitely isn't diligent work, careful attention to detail and achieving demonstrable results.
And even if you’re the one setting deadlines, if the powers that be are punishing people over any missed deadlines you’ll quickly learn to set deadlines to at least 3x the amount of time you think something will take.
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.
By definition most people are unable to grasp the true priorities of everyone else sitting around the table after adjusting for all confounding variables such as the correct time order.
Edit: And certainly not within say a half hour meeting once per week.
Because they’re all roughly equivalently intelligent.
i.e. In say a committe of ten, it’s very atypical for there to be 1 literal genius, as the committee chairman, and 9 unsophisticated and easily predictable members around the table.
Such that the chairman can correctly predict this or that, for any of the 9 other members…
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.
First, author recommends challenging but feasible deadlines, not "arbitrary" deadlines.
Second, the "small increments" approach you describe is quite compatible with the approach of having workers give a status update every Friday. Requires determining what can be accomplished in a week, so you have something tangible to report on Friday.
Yeah, one man’s "challenging but feasible" becomes the next man’s "arbitrary".
The difference between small increments and giving a status updates every week is that if your task needs multiple status updates, it’s not small increments.
Also small increments mean a piece of work that can measurably be evaluated as done. A status update is not a "done" status.
If someone fails to deliver a small increment, you find out soon, and the team can re-assess, and it doesn’t carry the stigma of missing a deadline.
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.
I think actually it's not about faster, it's about more efficient. Looking at the rate of improvement here of recent decades, we should've had a 4 day work week long ago. It should even have allowed more people to not work at all and help to make their local community e.g. more human.
Instead the wealth accumulates in places unreachable for 99% of us.
Got to be worth a try. At some point you'd probably find there was a minimum amount of time to actually do the work in (that is, Parkinson's law would break down), but it's certainly past 3 days.
No. You can only reduce a timeline to the point where it cant be effectively reached. A timeline that is guaranteed to be missed is no longer a timeline. It's an arbitrary point in time with no real meaning in relation to the work at hand.
I get the point you're trying to make, but in the fictitious scenario you're making, if everything, I mean absolutely everything, is done in 4 days and you're just spending the 5th doing nothing, this isn't Parkinson's law at play, this is just inefficiency.
The idea that something that could be done in 5 could also be done in 4 is less about 'wasting time', but about 'aggressive prioritisation' (which may or may not involve corner cutting).
And even in the case where there is no corner cutting, I think it's a mistake to think that the work going into prioritisation has no cost or overhead, or that this is scalable for months to come.
At a personal level, I find that if I push myself to finish something "more efficiently" because of a deadline (most of which are typically arbitrary rather than organic), this has a backlash effect on my ability to do things efficiently in the projects after. I would imagine a similar risk exists at the organizational level.
> but in the fictitious scenario you're making, if everything, I mean absolutely everything, is done in 4 days and you're just spending the 5th doing nothing, this isn't Parkinson's law at play, this is just inefficiency.
"Absolutely everything" can never be done, because you have things like unknown unknowns. Things that reveal themselves further on in the project and are almost impossible to anticipate.
Alternatively, things like "improving documentation" can also be done nearly in perpetuity. There are always more use cases, caveats and scenarios to describe or examples or onboarding materials to refine for future newcomers.
These are the less-critical things that should be done on a Friday at the pace of the person who is performing them.
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.
The solution is to let developers lead the conversation about estimates instead of management pulling deadlines out of thin air.
If the developers can't agree on an estimate it typically means that the requirements are unclear or misunderstood, or some of the developers are better equipped for the work.
> Sure, it may take some on the team a half hour to do some work, but for others, it will take two weeks.
That seems like an egregious difference, and I don’t think should be mentioned in such an off hand manner. Why doesn’t your team train people?
FYI, training doesn’t need to be hands-on, I think it’s often better to give employees education/training budgets. Technical team leads should be able to identify someone’s gaps, and make recommendations.
Or maybe it’s better to let someone go instead of wasting their time in a no-growth environment.
It's not a matter of training, it's a matter of lack of rewards and mismatched incentives. The reward for good work is generally more work and a "token" raise at best that is never proportional with the value you added.
The market has converged on a baseline of what is typically expected out of a given role. Now sure, we can argue (and I personally agree) that said baseline has become absolutely terrible, but we shouldn't blame the people for that.
If your objective is to be an employee and engineering is purely a means to an end (to earn a salary as said employee), then delivering the baseline and getting the baseline salary is all you need to do. Any effort beyond that is a waste of time that can rather be spent on hobbies/family/etc because it will not be adequately rewarded.
It only makes sense to go beyond the baseline if you want to learn and have a plausible way to monetize that extra experience (outside of this current job). If you want to build your own product, do consulting, etc.
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 :)
There is also the opposite. It works well for some time, then after a hundred or so sprints with deadlines and no down time, engineers pick up and leave. When there is no time to rework and address some tech debt, suddenly features take longer to develop and UAT becomes a game of whac-a-mole. If at least the management could also focus on delivering real tangible value, mercilessly cull all the nice-to-haves that introduce too much complexity, and prioritize work that will help bring out a stable and polished experience (albeit with less bells and whistles) instead of pushing new half baked features to satisfy the self imposed OKRs and stroking their vanity to move up the ladder.
The reality is mostly against that benefit though. I've seen so many bad decisions to be made in a short timeline to keep up with the deadlines, which leads the project to be dead soon later. There's always a deep balance to be tracked on.
I understand the parent comment like this: "they gave me 30 days so they must be wanting the X solution" vs "I have to finish this today so its ok to do Y instead". The latter works better most of the time because you can do a second, third iteration of the solution with real feedback.
You can also just coach engineers to ship iteratively directly, rather than treat them as hopeless basket cases and use deadlines as a workaround. I mean stuff like, teach them to ship when it's better (and not when it's perfect), how to break work down in tiny parts, etc. These are learnable skills. The fact that few people graduate from college with these skills doesn't mean they can't be taught in a straightforward way.
> about perceived 'technical debt' that is incurred delivering business value than to actually let them try and do things their way :D
Aye.
Some day I will write a detailed account of the worst code I've ever worked with. 1000 lines of spaghetti inside a single if-block; 20,000 blank comments; a whole pantheon of god classes; etc.
And yet, it was a very successful *product*. Much more so than the carefully engineered and architected codebase in an ISO 9001 (or was it 9000?) employer.
"""It was the best of code, it was the worst of code; it was the age of delivery, it was the age of technical debt; it was the epoch of rapid prototyping, it was the epoch of unmaintainable legacy; it was the season of boundless innovation, it was the season of endless refactoring; it was the spring of shipping features, it was the winter of debugging nightmares.""" etc.
Always doing "just good enough" logically results in a product that's barely good enough. Customers may find a competing product that's better than barely good enough.
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.
>>> "ship it when it's better than what's live now"
Is a fantastic rule - as it is almost always measurable (even things like engineering quality can be measured (a little)) and so justifiable.
Also your last line (Deadlines are poverty) suggests that it’s a term you use a lot in your company - want to expand?
> Also your last line (Deadlines are poverty) suggests that it’s a term you use a lot in your company - want to expand?
Nah, I just invented it to make the comment feel more edgy. Your question made me realize that that's the only reason it was in there, so I edited it out. I mean I do believe that deadlines are poverty but the comment is sufficiently controversial without it.
Basically, I think the idea of hiring highly intelligent and creative people, and then forcing them to work on assigned tasks on sticky notes given to them by "product managers", is an extremely brutal destruction of capital. Sucking the joy out of creative engineers seems like a very costly idea to me, and I'm not convinced that the project management benefits of doing so exceed that cost. Just see how fast and well and enthusiastic people can code when doing eg open source projects, or hackathons, or entire browsers (Ladybird), and so on. I think as a leader you should want to channel that joy and enthusiasm for your company's (and your people's) benefit. If you give people a lot of trust and freedom, and build a culture of eagerness to ship, you can get that. Deadlines then are an extreme buzzkill and I firmly believe it makes people less productive in the long term, particularly because they'll just do worse work and that compounds quickly.
This chimes with my own experience and attempts to build sane work environments wherever I can.
I think software has a very unusual relationship to the “explore exploit” concept - in that most manual / labour intensive businesses probably work ok with 20% explore - but with software once the explore is done the exploit is a marginal cost - so one should tune software business to be very high explore ratios (lean processes etc).
In other words hire great people and let them experiment.
My general schtick is that software is a form of literacy - and if you hire an illiterate person to for example write your autobiography, the process they would have to come up with would look not dissimilar to most Agile projects.
Or perhaps another way of looking at it - Linus Torvalds accepts patches that have made their way through several layers of “lieutenants” - why shouldn’t the CEO of corporate X be the owner of the codebase that runs the corporation ?
In the end all the discussion should be about the code - if it is not about the code you are discussing the wrong thing.
Anyway - completely agree with your points and your … passion? It’s in the right direction and good luck to your business :-)
Fwiw I agree with most of what you said, but as a business owner I can't let this one slide:
> In the end all the discussion should be about the code - if it is not about the code you are discussing the wrong thing.
The code is important, but in the end it's all about the customer. For us, if it's not about the customer (in the end), you're discussing the wrong thing. This is a key part of our "ship fast and incrementally" ethos - how can you tell whether something is better than what's in production now? By explaining how it impacts the customer.
Yes - of course. I think as a peon in a vast multi national there is too much “other” - PowerPoints, project plans not connected at either end to real customers or real code. I want to at least connect one end :-)
This works in a small organization, and is probably the best way to run one. I've been part of multiple teams like this. Everyone is high agency, genuinely interested, and making decisions that are (at least intended to be) best for the whole.
As another poster said, this just doesn't scale. You eventually hire someone who doesn't care as much, or just sees it as a job, or has worse judgement.
Being able to run this way is almost a paradise, and it's a lot of why startups can out compete big players.
The time in my career where I worked hardest, and with little stress, was on a team that was kind of forgotten and so we were just doing our own thing without deadlines. We decided what we thought was best and started working towards it with a lot of energy and enthusiasm. The team went about a year without any deadlines and very little management of any form, and yet the team was happy and working. Then we lost some political battles and all got fired--but my point is, I've seen that people will work with enthusiasm on things they care about even without pressure.
I think the problem in my situation (above) was that we were disconnected from what was important. You solve this by ensuring everyone is directly connected with the customers. It sounds nice and I hope it continues to work for you and your company.
(It's a shame that this post has net-downvotes currently.)
In a larger organization, you inevitably have a more hierarchical management structure, as well as multiple projects going in parallel. Prioritization and scope creep become significantly more difficult to manage. Only a small and specialized group of people talk directly to customers, which breaks the feedback loop you're talking about. And it's much easier for an individual engineer to go down an unproductive technical rabbit hole.
Many product categories are not well matched to the rapid iterative development style you are describing for your server side chat system, due to the significant costs involved in updating products that are already deployed.
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.
This is a failure as a developer. A full rewrite is almost never a good idea. You should be fixing things as you go, and making things better. It’s your job to spread the load and say “I need X days to do some extra work because Y isn’t working properly”, and stand your ground. I worked on a project that had hard deadlines every 2 weeks and shipped an unreliable amount of cruft. Even we had time to say “no, sorry”.
Besides if the project succeeds for years then joy might have made the right choice cutting corners.
> "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.
That’s an unspoken truth that some therapists don’t want to admit. Some will push you to the limit, while detracting from medication, even when it’s necessary, because as you said, no amount of software will modify (enough) the hardware
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.
>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.
1. Project that takes longer has higher chances not to be finished.
2. Feature creep is a thing and it’s a valid concern. In planning you don’t usually do a potential benefit analysis, you do risk analysis, because additional wins are nice to have, yet you are interested in project success more. So focusing on risk rather than benefits here too makes sense.
My favorite is the Plans and Plants essay - perfect headquarters are followed by the demise of the organization. (Been there, too - took about two years.)
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.
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.
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.
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.
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.
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
That's why you should probably never expect "perfect" from the finished product but rather a "iteration x" instead.
The articles adresses scope creep. You were asked for a drawing, but ended up with a cartoon "because they process just took me down that road". The deadline is helpful is limiting what the first/second/x'th iteration can be expected to do.
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.
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.