Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Preventing Burnout: A Manager's Toolkit

about.gitlab.com

Post reply on HN
Print view View original

81–90 of 205 posts

Re: Preventing Burnout: A Manager's Toolkit

#81

Post by chrsig »

hallway_monitor wrote: post #54
spacemadness wrote: post #10

Earlier quoted context omitted.

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…

Moving to a small company is the only antidote, for the most part. Actually, pretty much everything is better at a small company. For anyone who's only worked at a mega corp or a "Unicorn" where working 60+ hours is expected, working with a small group of people who all know each other will change your life.

it can depend on the stage of life of the small company.

I've been at my current company from it's series A, through a series B, a layoff, sale of one of it's IPs/customer bases, and ultimately sale to a holding company.

I agree with your overall point -- working with a small group of people who all know each other is great. I've had the opportunity to work with some people for the better part of a decade, and having that kind history with coworkers can be a real boon for communication and planning. It's also much more impactful when a coworker decides to leave.

The real shift towards a more sane work style happened after the acquisition by the holding company. It came with a layoff at the start, which was really disruptive. However, since then, there's been a huge focus on profitability rather than growth. Willingness to make big investments is much more conservative.

Re: Preventing Burnout: A Manager's Toolkit

#82

Post by howinteresting »

PeterStuer wrote: post #38

is this an out of season April's Fool joke? Burnout's main cause is cognitive dissonance between the will to contribute and succeed, and the believe in the outcomes and methods. NONE of the points mentioned (with the exception of seeking external help) in this article would make any significant difference to someone advanced n the road to a burnout.

Burnout is not just one thing, it can have several overlapping causes. What you describe is one of them, and the article covers others.

Re: Preventing Burnout: A Manager's Toolkit

#83

Post by balfirevic »

0daystock wrote: post #8

A lot of this is centered around doing less, expecting less from your workers, hiring more and "being more positive". These are pretty sentiments, but frankly they're completely dis-joined from the reality of working in a competitive, high-stakes engineering environment, where your boss WILL call you while you're on vacation, where you WILL go 8-12 months without finding a qualified candidate, where you WILL feel pre…

> where your boss WILL call you while you're on vacation

> where you WILL feel pressure to deliver products by deadlines

vs.

> where you WILL go 8-12 months without finding a qualified candidate

Sounds like a pretty good position to set some boundaries as an employee.

Re: Preventing Burnout: A Manager's Toolkit

#84

Post by StevenWaterman »

hu3 wrote: post #70
StevenWaterman wrote: post #37

I suffered from severe burnout around a year ago, and only now am I starting to feel back to normal. Nothing here would have helped me, and it's pretty clear to me why that is the case. (Paraphrased from literature that I read at the time) There's two kinds of burnout. One is caused by overwork, stress, long hours, not enough breaks, no holidays, not enough headcount, and so on. The kind of things this article talks…

> 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 to fix that issue - Come up with an idea - Get shut down because I'm not paid enough to have those kinds of ideas - Go back to programming, even more frustrated

I've since realised that I actually never fit the developer role in a company that well. I was good at it, but always got drawn towards creating tooling, CI pipelines, running the retros - the meta-changes and process improvements. In previous jobs that was fine because they were a lot more agile. There wasn't as much that needed fixing, and they were happy to let me fix the issues that did exist.

I felt no meaning to my work because I was motivated by improving things, whether they were in my job description or not. I could have a minimal impact by writing some code, or a huge impact by helping everyone else write code more efficiently, but I wasn't allowed to do the latter.

Anyway yeah long story short I'm currently pivoting my career towards the managerial/coaching/processes side. Something like "Software Development Coach" rather than just "Software Developer". I'm excited for the future again, and excited to help other people that are dealing with similar issues :)

Re: Preventing Burnout: A Manager's Toolkit

#86

Post by swagasaurus-rex »

civilized wrote: post #41

> Working at a startup is demanding. Is there no limit on what businesses can call themselves startups? GitLab is a publicly traded company with a $7B+ market cap, 1,500 employees, and many enterprise customers.

Startup sounds sexy, so everybody and their mother are part of a startup

Re: Preventing Burnout: A Manager's Toolkit

#87

Post by LegitShady »

BlargMcLarg wrote: post #7

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…

You're not wrong. The problem is conflicting incentives. Managers are incentivized to create metrics, goals, deadlines, and performance structures that give them the feeling (really just a feeling often) of being able to measure and 'control' progress.

The problem is the people accountable for all those things are living under the weight of all their KPIs and metrics. The more those measurements are reduced or made less important the easier it is to focus on just doing the work. But for the manager it becomes harder to state how good the process is, and what they need to do to stay on track.

Re: Preventing Burnout: A Manager's Toolkit

#88

Post by scruple »

candiddevmike wrote: post #42
StevenWaterman wrote: post #37

I suffered from severe burnout around a year ago, and only now am I starting to feel back to normal. Nothing here would have helped me, and it's pretty clear to me why that is the case. (Paraphrased from literature that I read at the time) There's two kinds of burnout. One is caused by overwork, stress, long hours, not enough breaks, no holidays, not enough headcount, and so on. The kind of things this article talks…

I think this is actually the most common type of "unreported" burnout in tech. The enormous amount of work to be done weighs on you, but the work doesn't have a defined set of requirements or the requirements are constantly shifting. For me, I've seen it mostly when a rewrite is happening, seems closely related to analysis paralysis.

> the work doesn't have a defined set of requirements or the requirements are constantly shifting. For me, I've seen it mostly when a rewrite is happening, seems closely related to analysis paralysis.

I'm currently dealing with this at work. I'm effectively responsible for a rewrite of another teams backend because that team is "short-staffed" or whatever (simple solution: hire people, train people, fix the staffing problem) and because "we like services!" or whatever (a very stupid and short-sighted reason to start a project: it's trying to fit a solution with a problem we don't actually have -- oh, no! That application is a monolith! The horror!). And on top of all of this I was pressured into agreeing with some arbitrary deadlines set by someone else before I even had a decent understanding of what my team and I were being asked to build!

It seems to me, however, and many others at the IC-level, many who are not even on our team but who are aware of this project I've been gifted, that another teams manager just doesn't want to own the problem space any more and he's found a way to misuse management to shove it off onto someone else.

And it's all decisions made levels above me (and even my manager, FWIW) and we're all just supposed to accept that our reality is one where we're thrashed around from project to project without any consent, without any conversations, without understanding why. And I'm a tech lead at this company, and I've been very effective in this role in the previous 3.5 years, but now I'm hamstrung by these absolutely horrendous decision making processes that exist somewhere near the stratosphere.

It's frankly fucking insulting to exist as an IC in corporate America and the only thing that keeps me clocking in every day is the fact that I have a family and live in a high CoL area: They've got me by the balls and they know it. I suspect I'm not alone.

/rant off

Re: Preventing Burnout: A Manager's Toolkit

#89

Post by BlargMcLarg »

outworlder wrote: post #78
BlargMcLarg wrote: post #25

Earlier quoted context omitted.

It's not just the US. Without going into the nuances of the US, things like burnout are severely on the rise among the younger crowds all over the world despite some of them working as much or less than before in several countries. Most of these countries are adopting American office concepts. More statistics, more pressure, more management / talks with management, more "work family", tighter interviews, you name it.…

You start by arguing that it's not just the US, and then continue by saying that the rest of the world is adopting american practices, which is causing the issue. I'm confused.

The former was referencing location, in that other western countries are already having the same problems. Partially due to adopting the latter culturally. However, American office culture is not the sole problem: a lot of people in EU wouldn't object to these office politics nearly as much if there was a luxurious total comp attached to it or an interesting job. They go through worse hoops just for those.

That said, maybe it'd be more apt to say "Silicon Valley office culture".

Re: Preventing Burnout: A Manager's Toolkit

#90

Post by jseban »

BlargMcLarg wrote: post #7

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.

Yeah I wish you'd at least be given a chance to be responsible about delivering, and not always crack the whip by default, there's just no way you can ever have a healthy working environment.

Post reply on HN