Live data from Hacker News

There’s no glory in overworking, it’s just imminent burnout

medium.com

31–40 of 59 posts

Re: There’s no glory in overworking, it’s just imminent burnout

#31
post #27
post #12

Earlier quoted context omitted.

When I was younger I used to work a lot of extra hours because I enjoyed the work. Now not so much, but still get enthused about things from time to time and find myself still at work at 8:00pm not even aware of what time it is.

Which is great and awesome. I was the same way. But what unfortunately happens is your output and productivity from this becomes the norm/standard. Everyone above needs to know they can't and shouldn't calculate not expect this amount of output. Consider it a temporary bonus and never rely or make plans assuming it. That's the difficult thing for everyone above to do. They want to appear to be the hero and they don't…

I just started a new gig at a place that enforces a 35-hour work week. I get just as much done as I did working 40+ hours, but I'm way happier and just generally more relaxed. It's really amazing what walking out of the office at 11:30 every Friday will do for your mental health.

Re: There’s no glory in overworking, it’s just imminent burnout

#32

In the menagerie of death marches I've been a party to throughout my ~20yr career. Every single one of them was predicated on a team that was, in aggregate, a low-performing team, so we were all having to work so much to make up for the lack of ability and/or preparedness of others, and those others were having to work so much to compensate for not being particularly​ good at their jobs, and taking on way more respon…

In my opinion, these problems and situations should always be put down to failures of management and leadership. Even if the team is low-performing, why did management give an unrealistic deadline for something to be finished by a low-performing team? Why are they putting together low-performing teams in the first place? Is it because high-performing people take one look at the putzes in charge and get a new job? Going the route of looking into the hearts of team members without looking outside the team is a bad idea.

Re: There’s no glory in overworking, it’s just imminent burnout

#33
I agree, overwork is bad. But this part struck me:

"Clarity struck me at a management meeting when a colleague asked my opinion on a project. I shrugged lightly and said it didn’t matter to me, my team would be able to support whatever decision that was made. It was a somber, sobering realization: I didn’t care."

Now maybe this was one of those internal realizations, which is totally legit. But not having an opinion is okay too. I almost feel like part of the friction in tech is that everyone must always have a strong opinion all the time, even when it is unrelated to their work. Overall, I wish I had more times where people said "either of those sound fine, they both get the job done." Usually people who are "passionate" are actually prescribing details they have little insight into, vs the person who's doing the actual work / designing.

Re: There’s no glory in overworking, it’s just imminent burnout

#35
I think I have been feeling the same way the author felt during employment at the company. The scary part is leaving only to find it succeeds after I have left. But the main thing is that in startups we just want a place to belong, a chance to be a part of a bigger thing. With this obsession comes the tendency to do anything to achieve that goal.

Re: There’s no glory in overworking, it’s just imminent burnout

#36

In the menagerie of death marches I've been a party to throughout my ~20yr career. Every single one of them was predicated on a team that was, in aggregate, a low-performing team, so we were all having to work so much to make up for the lack of ability and/or preparedness of others, and those others were having to work so much to compensate for not being particularly​ good at their jobs, and taking on way more respon…

Not always so simple though, a lot of places have a pattern of overwork that goes a bit more like this.

Someone somewhere up the chain overpromises on something without consulting the people that will do the work. Then the team is forced to burn the midnight oil to do that, because they are a talented group, who like the work and don't want the company to look bad, they manage to actually hit the date or miss it just by a little bit, by working themselves nearly to death.

Management, who thought the date would never be hit, based on the engineer complaints at the outset, is effusive in their praise for the team, buys them lunch or some other banal expression of thanks/recognition for their sacrifice, and now feeling justified in their estimation "skills" because they were bailed out by the engineers, proceed to do it again, and again ... after behaving for a little bit, or letting the engineers set dates for less important projects.

Re: There’s no glory in overworking, it’s just imminent burnout

#38

In the menagerie of death marches I've been a party to throughout my ~20yr career. Every single one of them was predicated on a team that was, in aggregate, a low-performing team, so we were all having to work so much to make up for the lack of ability and/or preparedness of others, and those others were having to work so much to compensate for not being particularly​ good at their jobs, and taking on way more respon…

In my opinion, these problems and situations should always be put down to failures of management and leadership. Even if the team is low-performing, why did management give an unrealistic deadline for something to be finished by a low-performing team? Why are they putting together low-performing teams in the first place? Is it because high-performing people take one look at the putzes in charge and get a new job? Goi…

I agree with the general sentiment here. Every time I've ever had to let anyone go I always preface with something along the lines of, "First of all, this situation started out as a failure of management."

However, if you're not in the management tier, and you don't have reason to believe management will get any better at hiring and aligning people, and you subsequently end up being in way over your head (even though the situation is ultimately someone else's originating problem). You're not helping yourself or anybody else by just sticking with the situation and pointing the finger upward. If you extricate yourself from it, then you get to give a useful signal to the hiring manager that they didn't do a very good job hiring, and you get to find a hiring manager who is good at hiring.

Re: There’s no glory in overworking, it’s just imminent burnout

#39

In the menagerie of death marches I've been a party to throughout my ~20yr career. Every single one of them was predicated on a team that was, in aggregate, a low-performing team, so we were all having to work so much to make up for the lack of ability and/or preparedness of others, and those others were having to work so much to compensate for not being particularly​ good at their jobs, and taking on way more respon…

Not always so simple though, a lot of places have a pattern of overwork that goes a bit more like this. Someone somewhere up the chain overpromises on something without consulting the people that will do the work. Then the team is forced to burn the midnight oil to do that, because they are a talented group, who like the work and don't want the company to look bad, they manage to actually hit the date or miss it just…

That would fall under the category of "Management" (in the narrative you've supplied here) being in over their head.

Re: There’s no glory in overworking, it’s just imminent burnout

#40
Some death marches are out of desperation and some are for show to investors or boards. Desperation marches usually come from undemocratic process from the start. When engineers are treated as vassals it hides the true costs of the project. When you're trying to get to an MVP it takes compromise and listening to engineers. Do the design before you hire engineers don't interate on code and design at the same time. Get your design process complete, find out about current best practices so you can evaluate framework choices. Separate out the design process from engineering, the tools are available to get your ideas down solid before you spend a lot on engineering.
Post reply on HN