Live data from Hacker News

Preventing Burnout: A Manager's Toolkit

about.gitlab.com

91–100 of 205 posts

Re: Preventing Burnout: A Manager's Toolkit

#91

All the "strategies" (really just tips) follow the same pattern of either tunneling on overwork as a cause, treating symptoms or pathos. >Sid and Michelle emphasized that the earlier a manager can identify burnout the better. Honestly, at the point of identification, you're likely too late. Especially for something as insidious as burnout, which can last for years and not show any symptoms before it is beyond the poi…

Anecdote time. As I’ve moved into larger companies and am shackled by OKRs, I am enjoying my work a lot less and feel under more pressure than ever but am getting less useful work done. It feels like a lack of trust and assumes the organization is run very efficiently and fairly—which I don’t think any company can truly claim. People just seem to adjust by gaming these systems instead of putting useful effort into th…

> As I’ve moved into larger companies and am shackled by OKRs

Try moving into a large company _without_ OKRs. How much redundancy do you need to buy to achieve your service reliability goals? Well, you can decide on any goal you want but management now has the right to declare the decision wrong post-hoc:

Got an outage? Should have spent more Didn't have an outage? Why are we wasting all this money?

And of course, by avoiding any public commitment like an OKR, they are somehow absolved of accountability in the matter.

Re: Preventing Burnout: A Manager's Toolkit

#92
One thing as a manager I was passionate about was monitoring the team stress. Some team members work better under pressure, others don't and it's a balancing act. For instance, I've had co-workers that need the constant pressure to accomplish their goals and they can go on like that for years. The act of accomplishing something is worth the stress.

Personally, I don't really get burned out. I have limitations on hours I can work, but happily work 80 hrs a week. I work 6 days a week, sleep 6 hrs a night, and effectively have two full-time jobs. If for some reason the stress lets up, I just pick up more work.

One of the things I've enjoyed recently is https://www.read.ai/ it lets you track interactions between co-workers. As I'm fully remote and often in meetings. When I see someone start getting stressed to the point it negatively impacts interactions we can talk it out, do a "game day", etc to improve the situation.

Anyway, I think it's important to note that "preventing burnout" is extremely relative and most people handle it wildly differently.

Re: Preventing Burnout: A Manager's Toolkit

#93

I'm pretty sure we will see an appetite for transition to the 4 day work week. Most people will find some paycut (10-20%) acceptable in exchange for increasing their free time by 50% (2 day weekend -> 3 day weekend). Most companies will find the 10-20% reduction in a very large expense (payroll) attractive in the current tightening economic conditions. I would be surprised if there was any productivity loss as a resu…

I think we're very close to it if not there already. Additionally, the prevalence of long Covid will likely force some companies to re-examine previously sacrosanct employment structures such as the 5 day work week or nothing.

Re: Preventing Burnout: A Manager's Toolkit

#94

All the "strategies" (really just tips) follow the same pattern of either tunneling on overwork as a cause, treating symptoms or pathos. >Sid and Michelle emphasized that the earlier a manager can identify burnout the better. Honestly, at the point of identification, you're likely too late. Especially for something as insidious as burnout, which can last for years and not show any symptoms before it is beyond the poi…

> So stop putting them under a lot of pressure. The second tip hints at this, but it only seems to be a reactionary measure. Maybe all this goalsetting, OKRs and such is exactly the problem with the industry, always having to feel pressured to an extreme by metrics and stats which effectively mean nothing, when most people just want to put in an honest day's work and progress. You nailed it. The entire article can be…

> Give me work to do and leave me alone to do it. That'll solve a lot of the burn-out.

Yeah but this really translates to asking management to actually do their job, and letting you do yours. Any hint at this attitude will get you in a world of trouble.

Re: Preventing Burnout: A Manager's Toolkit

#95
My main sources of burnout these days are: 1. useless information overload, and 2. lack of focus time. And it's rare that I've actually met a manager who could even see this as a problem.

My main way to deal with this: just ignore 99% of my incoming notifications. The only notifications I need are "SLA is broken". Everything else should just be low priority async systems, and honestly, email worked pretty well for this but everyone just loves using Slack or a similar tool now.

And the entire business loves to work against you too...

Most of my managers have just loved throwing juniors into the mix with no structure on how they'll be mentored - just let the senior engineers figure it out. Ergo, I now have to periodically check Slack and review notifications again just to make sure none of the juniors reached out.

Oh, and don't forget the other random people who grabbed your name from delivering a bug fix six months ago and just want to check on a thing "real quick" or ask a "small" question.

Modern office communication is a clusterfuck, and probably contributes more to stress and reduces productivity more than any other aspect of work. And trying to remedy this as an individual contributor is usually unsustainable. It's a management problem, and sadly, this "management toolkit" gleefully avoids this.

Re: Preventing Burnout: A Manager's Toolkit

#96
post #64

Earlier quoted context omitted.

Wouldn't that be a "boreout" instead of "burnout"?

That is probably a better fit, yes. Not perfect, since I was still intellectually stimulated by trying to improve the environment and processes, but every attempt inevitably hit a roadblock. I identify most with the 2nd and 3rd categories in [1] However I think it's more valuable for me to keep using the term burnout, especially in situations like this. To a manager, burnout and boreout look the same. Ideally you cou…

In this case, I think you wanted more opportunities and career growth and that wasn't possible in that role. I've been there before. I don't think this is burnout, you just outgrew your role, and there was no reason to stick around.

Re: Preventing Burnout: A Manager's Toolkit

#97
post #24
post #12

“Working at a startup is demanding. GitLab team members are often under a lot of pressure.” Isn’t being a $7.5B publicly-traded company the definition of not a startup?

This is HN while not everyone's subscribes to everything pg says there is a lot of agreement on what constitutes a startup and differentiates it from other more conventional businesses. PG says a startup is any company who looks at growth as their primary measure. A business is any company who looks at the bottom line as their primary measure. So it depends on the definition you wish to subscribe to. There isn't a un…

Seems silly though. The term "growth company" seems a lot more authentic. Of course these labels are not black/white, but it's a useful distinction. There are simply different dynamics at a growth company vs. a startup.

Re: Preventing Burnout: A Manager's Toolkit

#98

All the "strategies" (really just tips) follow the same pattern of either tunneling on overwork as a cause, treating symptoms or pathos. >Sid and Michelle emphasized that the earlier a manager can identify burnout the better. Honestly, at the point of identification, you're likely too late. Especially for something as insidious as burnout, which can last for years and not show any symptoms before it is beyond the poi…

Exactly. Putting on ever more pressure while also disempowering people puts them in a psychological spit that leads to burnout.

Re: Preventing Burnout: A Manager's Toolkit

#99
post #70

Earlier quoted context omitted.

> Looking back, the issue was a company pretending to care about Agile and just making everything worse in the process. First, thanks for your honest input. I suppose the fix was to change job to a company that doesn't pretend to do agile?

Partly, yes. I left that company and started my own. That's brought its own set of troubles, but it has at least given me a chance to regain my love for programming. Looking back, I did really enjoy trying to fix the organisational issues that caused my burnout. So I was going through this constant cycle of - Get frustrated by something when programming - Realise there's an issue in process / workflow - Get excited t…

This resonates very much with my own experience. I’ve quit my last job because it broke this camel’s back and now the last thing I want to do is going back as a developer.

I also do enjoy fixing things and processes so that others don’t needlessly suffer through work and actually enjoy themselves.

But how do you go about switching tracks to coaching? What does it even entail? How do you learn?

And more importantly: who’s buying? I was trying to better things in every job I had and every time I met the wall of “not being paid enough to have these ideas/being road blocked”.

If companies have this attitude (no matter how much they’re losing through low morale, inefficiencies, mistakes, attrition, etc) when offered a chance to fix it “for free” by an actual employee, why would they pay top dollar for a coach to make it happen?

It feels to me that management is even more cynical than the burnt out grunts and their objective is to squeeze as much as they can out of their employees while they last because they know they’ll quit or burnout in a year or two anyway.

How do you even begin a conversation when that’s the prevalent attitude?

Re: Preventing Burnout: A Manager's Toolkit

#100

All the "strategies" (really just tips) follow the same pattern of either tunneling on overwork as a cause, treating symptoms or pathos. >Sid and Michelle emphasized that the earlier a manager can identify burnout the better. Honestly, at the point of identification, you're likely too late. Especially for something as insidious as burnout, which can last for years and not show any symptoms before it is beyond the poi…

A huge problem I had to overcome was learning to leave work mentally every day. The online and WFH nature of software work makes it easy to feel like you're always on-call and feeling some low-level stress. This is a quick path to burnout for me. My advice to anyone in this situation is to be firm about not working outside your regular hours. If someone messages or emails when you're not working, don't respond until you're back on the clock, even disable notifications if that's a stress-trigger. Obviously actually being on-call is different. That needs to be an official policy, ideally spread across multiple devs so you're not on 24/7.
Post reply on HN