4 ms·
Avoiding burnout and optimising for long-term performance is one side of this coin. Even if you pretend that your team can sustain 100% effort in the long term
by pdpi 3y ago
Avoiding burnout and optimising for long-term performance is one side of this coin.
Even if you pretend that your team can sustain 100% effort in the long term, and are willing to disregard the effects of working that way on their lives, there is no such thing as 110% effort, so a steady state of 100% effort means you don't have the spare capacity to push hard on specific short-term goals when there is a need for it. Or, put differently, you have a much more limited ability to react quickly to sudden shifts in the market.
- unsupp0rted 3y agoThere is such a thing as 110% effort. It's the amount of effort that temporarily or permanently injures the person making it.
- speed_spread 3y agoThere is also a lower threshold over which no permanent injury occurs (yet) but which makes workers borrow upon finite reserves of endurance which eventually (soon) need to be replenished with interest. So if you even it out over time workers are actually less productive. This is known in the gaming industry as the crunch mode, and it's what I would consider "over 100%". Permanent damage occurs if you accumulate too much interest. Both thresholds vary per individual - known as stress resistance. IMO, any mention of it as a quality in interview is a big no-no.
- HelloNurse 3y agoBut the payroll savings compared to hiring 10-20% more people are much more solid and measurable.
- smaudet 3y agoTo be fair there are diminishing returns to additional hires, typically hiring one additional developer produces maximum 20% additional throughput, often lower after onboarding/hiring too green. You might have to double or triple team size to get 20-30% increase. So I see the temptation to "get more done with less" although the reality is you actually drop throughput in the long term.
- HelloNurse 3y agoBeing sarcastic is my fault, but understanding the opposite of what the article intends is your fault. I was talking about hiring to increase slack, not to increase throughput.