3 ms·

I'm cofounder of https://talkjs.com https://talkjs.com, and I strongly disagree. We do not believe that Parkinson's Law universally holds, and in fact we do not

I'm cofounder of https://talkjs.com 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 2y ago
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 2y ago
  > 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 2y ago
    >>> 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 2y ago
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 2y ago
Unfortunately it doesn't scale at all, either to larger teams or to cross-disciplinary projects (e.g. hardware & software combined).
- skrebbel 2y ago
  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 2y ago
    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.
seneca 2y ago
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.
SoftTalker 2y ago
"ship it when it's better than what's live now" Sounds good but seems prone to debate over what "better" means.

lifeisstillgood 2y ago

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 2y ago
> 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 2y ago
  >>> 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 2y ago

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 2y ago

Unfortunately it doesn't scale at all, either to larger teams or to cross-disciplinary projects (e.g. hardware & software combined).

skrebbel 2y ago
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 2y ago
  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.

seneca 2y ago

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.

SoftTalker 2y ago

"ship it when it's better than what's live now" Sounds good but seems prone to debate over what "better" means.