[HN Gopher] Parkinson's Law: It's real, so use it
___________________________________________________________________
Parkinson's Law: It's real, so use it
Author : thunderbong
Score : 127 points
Date : 2024-12-12 09:48 UTC (13 hours ago)
(HTM) web link (theengineeringmanager.substack.com)
(TXT) w3m dump (theengineeringmanager.substack.com)
| Vampiero wrote:
| 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.
| yu3zhou4 wrote:
| 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
| Y_Y wrote:
| 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
| sitharus wrote:
| 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.
| Anawan wrote:
| Could you share some of your strategies?
|
| 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.
| jabroni_salad wrote:
| 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.
| Y_Y wrote:
| I've heard this referred to as "time blindness", which may
| help if you're looking for more information.
|
| I'd also be grateful if you could share some of your
| strategies.
| commandlinefan wrote:
| 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.
| 0x5f3759df-i wrote:
| 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.
| skrebbel wrote:
| 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.
| lifeisstillgood wrote:
| Love this
|
| >>> "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?
| skrebbel wrote:
| > 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.
| lifeisstillgood wrote:
| >>> extremely brutal destruction of capital.
|
| Hell yes.
|
| 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 :-)
| Buttons840 wrote:
| 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.)
| jpm_sd wrote:
| Unfortunately it doesn't scale at all, either to larger teams
| or to cross-disciplinary projects (e.g. hardware & software
| combined).
| skrebbel wrote:
| Got any experience to share in this regard? I can imagine
| plenty roadblocks but it's not immediately obvious to me that
| trust doesn't scale.
| jpm_sd wrote:
| 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.
| uludag wrote:
| 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."
| willvarfar wrote:
| 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 :)
| revskill wrote:
| 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.
| swah wrote:
| 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.
| dsego wrote:
| 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.
| ben_w wrote:
| > 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.
| skrebbel wrote:
| 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.
| nitwit005 wrote:
| 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.
| jonwinstanley wrote:
| 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.
| dsego wrote:
| The rewrite that never comes and you keep building on top of
| that week project for years to come.
| maccard wrote:
| 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.
| justlikereddit wrote:
| 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.
| k__ wrote:
| 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.
| John23832 wrote:
| 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.
| DarkNova6 wrote:
| 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.
| xuhu wrote:
| What's the sense in making companies more efficient, harder
| to disrupt and putting them in a position to create a
| monopoly as they become larger ?
| calderwoodra wrote:
| Because some things are only possible at a certain scale,
| like an effective state run healthcare system.
| nlitened wrote:
| Which state is an example of an effective state run
| healthcare system?
| paulryanrogers wrote:
| NHS before the conservatives gutted it?
| vixen99 wrote:
| 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.
| John23832 wrote:
| The Nordics.
| DarkNova6 wrote:
| In comparison to the Us? Literally every other state in
| the world. And I do mean "literally".
| DarkNova6 wrote:
| 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.
| John23832 wrote:
| Yes and no.
|
| 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.
| DarkNova6 wrote:
| 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.
| AnthonyMouse wrote:
| > 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.
| J_Shelby_J wrote:
| Adam smith said the same thing when he coined the term.
| Capitalism without government regulation of monopolies is
| impossible in the long term.
| anal_reactor wrote:
| 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.
| huijzer wrote:
| 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."
| svara wrote:
| 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.
| OccamsMirror wrote:
| > 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.
| huijzer wrote:
| > 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!
| HumanOstrich wrote:
| Did you just speak for the parent commenter and then
| disagree with yourself?
| hammock wrote:
| On a long enough timeline, Microsoft buys your company.
| It's a win-win
| skybrian wrote:
| 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.
| jkmcf wrote:
| As an original bouncer, and recent convert, I would
| emphatically state that Cursor's AI for coding is much
| better.
| jasonjmcghee wrote:
| I must be holding it wrong. It consistently gives me low
| quality code / changes. I try it about once a month for a
| handful of hours.
|
| The code somtimes runs, which is a large improvement over
| recent years, but generally doesn't do what it's supposed
| to do.
|
| And this is using claude 3.5, which works dramatically
| better for me in a chat session where i give it exactly
| what i want it to look at.
|
| I just haven't found a way to be productive with it yet.
|
| I've even tried the usual tricks of forcing it to write
| comments about what it's attempting to do throughout the
| code, but even then, fails.
| nitwit005 wrote:
| But, you're saying they did set deadlines, just that you feel
| they were "expanded". The article is suggesting setting a
| deadline is a fix by itself.
| chaboud wrote:
| 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.
| anal_reactor wrote:
| > 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.
| jrochkind1 wrote:
| 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.
| keithalewis wrote:
| 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.
| WorldMaker wrote:
| 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.
| Wololooo wrote:
| Yep.
|
| A corollary of this is the following paper
|
| https://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_....
|
| 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...
| cjs_ac wrote:
| Every system can be placed on a spectrum. One end of this
| spectrum is _perfect efficiency_. The other end is _perfect
| resilience_.
| gcanyon wrote:
| Geordi La Forge: Yeah, well, I told the Captain I'd have this
| analysis done in an hour.
|
| Scotty: How long will it really take?
|
| Geordi La Forge: An hour!
|
| Scotty: Oh, you didn't tell him how long it would 'really'
| take, did ya?
|
| Geordi La Forge: Well, of course I did.
|
| Scotty: Oh, laddie. You've got a lot to learn if you want
| people to think of you as a miracle worker.
| ozim wrote:
| Well inflating estimates has short lifespans and Scotty got
| away because Kirk was a meathead.
|
| I like Kirk was shoot first ask later unlike Picard but
| Picard was always "oh 1 hour - make it in 30 mins" or "1 hour
| - make it quick you have 15mins"
| quink wrote:
| 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.
|
| Kirk >>> Picard.
| ozim wrote:
| Well I watched only series so far. Not movies.
|
| For me it was looking like Kirk did knew he knows he
| doesn't know stuff so he was meathead with ability to
| defer and not control what he doesn't know.
|
| Picard was more like he knows everything and had to
| maintain this aura. But was on a different level of
| sophistication that I value much.
|
| Even though I love Kirk's gun blazing.
| ghaff wrote:
| 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.)
| Supermancho wrote:
| > 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
|
| ...you push people to only solve the actual problem.
|
| This is a very strange take to enshrine as advice. If you try
| to solve a 50$ problem for $5k you're out ~$5k and the next
| project will cost $7k
| swah wrote:
| 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.
| philmcp wrote:
| 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.
| CamouflagedKiwi wrote:
| By this argument, do you not then reduce it to a 3 day week,
| forcing them to work faster again? Then to 2 days?
| John23832 wrote:
| 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.
| tpoacher wrote:
| 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.
| antisthenes wrote:
| > 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.
| tpoacher wrote:
| Reminds me of the Dilbert quote:
|
| > I have infinite capacity for more work, as long as you are
| happy with the quality of the work approaching zero.
| commandlinefan wrote:
| "... unless, of course, somebody comes up with six minute
| abs, then you're in trouble, huh?"
| shahzaibmushtaq wrote:
| 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.
| anodari wrote:
| In theory, it works, but the issue is that creative work is
| inherently never finished.
| karles wrote:
| 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.
| exe34 wrote:
| > "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.
| geraldwhen wrote:
| 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.
| nis0s wrote:
| > 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.
| geraldwhen wrote:
| You can lead a horse to water, but that's it.
|
| And firing is politically impossible where I am. If someone
| chooses not to improve, or simply does not, there are no
| repercussions.
| noprocrasted wrote:
| > Why doesn't your team train people?
|
| 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.
| Falimonda wrote:
| 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.
| geraldwhen wrote:
| I'm saying among the X developers doing the work, the skill
| gap is so large that estimate must shift an order of
| magnitude.
| scioto wrote:
| 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.
| satisfice wrote:
| I use Parkinson's Law to get less done. Because productivity is a
| disease, not a virtue.
| bravetraveler wrote:
| Let me introduce you to my friends bikeshedding and sandbagging
| cushychicken wrote:
| 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.
| whatever1 wrote:
| 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.
| cubefox wrote:
| 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.
| techdmn wrote:
| 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.
| tpoacher wrote:
| 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.
| MichaelZuo wrote:
| This seems like a tautology.
|
| 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...
| tpoacher wrote:
| If anyone's interested, here's my comparison of productivity
| with the Ideal Gas law I've written about here before:
|
| https://news.ycombinator.com/item?id=30000296
|
| It gives a contrary perspective to this Parkinson's law
| interpretation, which I think is vastly oversimplified from the
| intent of the original quote.
| 0xFEE1DEAD wrote:
| 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.
| palata wrote:
| 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)".
| mcphage wrote:
| 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.
| WalterBright wrote:
| 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)
| B1FF_PSUVM wrote:
| 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.)
| JohnMakin wrote:
| 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.
| n4r9 wrote:
| You did 1 week sprints? With retros and planning sessions every
| week?
| JohnMakin wrote:
| Informally, yea. Wasn't usually a lot to go over when it was
| short cycles with that particular team.
| matt_s wrote:
| 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".
| aeternum wrote:
| 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.
| hcarvalhoalves wrote:
| My issue with this kind of piece: a lot of words like
| "sometimes", "often", "really", "exact", and zero data.
___________________________________________________________________
(page generated 2024-12-12 23:01 UTC)