The worst is when a big issue is taking too long, some higher up wants it broken out into smaller tasks so they can be closed independently/faster. Eventually the issue becomes a fractal of issues assigned to multiple people and progress comes to a halt.
Sometimes things take time, and can't be delegated.
I think the wisdom that headcount doesn't make a product faster has managed to reach some people, but somehow not the wisdom of don't burn out your people. Like no matter how much you talk about burnout, there is no adequate valve in play that enforces this as a true incentive. The very closest business people to having the worker perspective are "technical" startup founders (IE those founders doing the kind of work they may later measure their employees about), who take youth and energy into their passion project and by the time they burn out they have underlings, money, and power, or more often have simply failed out. In the former case they no longer need to be very productive in a labor-y sense that often and will remember a success story that was for them personally about unsustainable and generally unscalable hard work. In the latter case, they either have the support network to recover from their failure and maybe even try again. Those who fail to ever create a successful business are not taken seriously by businesses. Business people and investors who have not been technical founders are even less likely to "get" this on an experiential level, and may well get by on burning people out over and over, with each instance being excused as inevitable churn, conflict of personality, or generally speaking the fault of the employee. Since financiers care more about the short term and the appearance of "growth" rather than the long-term sustainability of the business, let alone the fates of the workers, burnout and slowing projects to a halt due to prioritizing being busy is an externality at best. As we can see basically all over the economy, the investor incentive barely can be said to align with that of the business, let alone its workers
> Sometimes things take time, and can't be delegated
This is something I keep saying to our team, but we have some members who want to keep breaking things into more and more tickets. Their argument is it allows more bits to be worked on in parallel but I point out that it means context must be rediscovered by multiple people. Sometimes it’s okay for one ticket to be a large-ish do-it ticket and we don’t need a design+breakdown for every aspect of a feature.
Sometimes things take time, and can't be delegated.