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 point of no return.

>GitLab team members are often under a lot of pressure.

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.

Maybe it's time to admit corporations went too far pressuring the average worker to worry over every little detail.

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 about.

Instead, my burnout was caused by a lack of progress, which destroyed a lot of my other needs that I wasn't even thinking about. I felt no autonomy, no meaning to my work, and I felt out of place in the team because it seemed like I was the only one that was so bothered by it.

I wasn't working too much, and I often was only doing a few hours of work a day. However, because of organisational issues, I was making no progress, barely any improvements to the code, and was completely demotivated. I did try taking time off and taking it easy, as the traditional methods to combat burnout. Far from helping, they just made things worse, because that wasn't the problem. Looking back, the issue was a company pretending to care about Agile and just making everything worse in the process.

This ended up being a bit of a rambling vent, and I'm sorry about that - but my point is that we need to be aware that not all burnout is from stress and overwork. A lack of motivating factors can look the same as poor hygiene factors. Your reactionary measures *must* include actually talking to the person about what is causing the stress, and if needed, being willing to fix the organisational issues that are the root cause.

Here are some tips I would give, as an individual contributor:

* Minimize the number of simultaneous projects. Having more on your plate than you can imagine getting done is a huge cause of stress and burnout.

* Avoid switching priorities frequently. Shield the team from too many external requests.

* Avoid making "small" requests (e.g. a random data pull). Handling your request is probably not as small an amount of work as you think. This is especially a problem when for people with a lot of meetings - they may not have that many hours left in the day for their "real" work, and your "small" request might take up all those hours for today (which is really stressful when you badly needed those hours for something else!).

* Avoid interrupting developers / making them feel like you could demand something at any time.

* Clarify priorities, and don't bug people about lower priority things.

* Don't schedule too many meetings. Developers work on a Maker's schedule, and ideally would have at least half of each day completely free of meetings. Meetings are more draining for ICs than they are for you.

* Don't argue with time estimates given by developers. (Though looking for ways to reduce the scope of a project is valid)

* Give developers time to pay down tech debt.

* Listen to and act on issues people raise.

* Let people know what is going to happen well in advance. Give people time to gear up for changes. Don't make people feel like things could suddenly change at any time with no warning.

> Celebrate progress. Burnout is often caused by a feeling of stagnation. Seeing the progress you’re making day-to-day is hard. Managers should create space to celebrate small wins and reflect on the mountains you’ve climbed.

I really appreciate this one. As a very high conscientiousness and med-high neuroticism person a manager asking for a "status check" on a project actually sounds like "You did something wrong that gave me cause for concern/doubt" which causes an inordinate amount of stress and self doubt that I'm truly giving it my all -- which leads me to push harder regardless of how hard I already am...

Celebrating progress allows me to say "Yeah, things may not be on our desired timeline, but also we're making progress and that timeline was unrealistic... We'll get there so long as we continue to invest".

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.

“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?

I think burnout is the brains mechanism to prevent you from doing non-productive work (or at least what it perceives as non-productive) the problem is most of the work we doing in corporate environments feels pretty non-productive.

Most of my periods of burnout in tech have been due to doing a lot of work without any real perceived payoff, this might include a lot of team meetings where we discuss priorities and estimates ad nauseum or working with tools that constantly fight you. Its like playing a game over and over and never making any progress eventually your brain is smart enough to tell you that you need to avoid playing the game (or going on the same hunt). I don't know how you solve this problem but I think most managers don't even understand burn out well enough to start.

How about:

* Listening to each person’s specific concerns carefully and in detail, and then applying as much creativity and empathy as possible to help them come up with a resolution?

* Giving people increased responsibility and increased autonomy as a response to signs of burnout?

* Quickly transitioning coddlers (who stifle growth), complainers (who destroy motivation), victims (who destroy alignment), braggarts (who steal credit and poison achievement) out of teams?

* Managing the team competently so that forward progress is actually happening and the whole team can see it and sense it and take pride in it?

* Ensuring that the team’s mission, the company mission, and business value are all aligned, and making the team stakeholders to give them agency?

Personally, I find saying “the employees have burnout, they should work less and celebrate more” is pretty naive. It’s likely to make things worse.

Burnout isn’t overwork. It’s more like hopelessness. Effort is being made but the emotional reward for visible progress towards a valuable goal is not forthcoming. It can feel like overwork, but it’s more the work to reward ratio that’s a problem.

It bears repeating, many people who think they have burnout actually have chronic fatigue (CFS/ME) but don’t know it yet. Repeated burnouts may simply be a relapse and recovery cycle. A number of the genetic predispositions to CFS also tends to have behavioral components (anxiety disorders and ADHD) that include a preference for a career in software. Now with Covid many of those who may never have had CFS are finding themselves with Long Covid. I mention this because the treatment for burnout is completely different to the treatment for CFS.

A lot of this is fluff. I don't really care about plaudits, your gratitude or other fake positive reinforcement. Give me extra money if you think I'm doing a good job. For those who need a manager to tell you that you're burned out then that's totally the wrong way to perceive it. You tell the manager that you are and tell the manager you're taking time off. It's not a conversation. Those are statements you make and execute.

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 pressure to deliver products by deadlines. Unfortunately, Gitlab doesn't strike me as a high-stakes job for engineers nor managers. This isn't a moral judgement on them, but a reminder that serious work requires sacrifice and some burnout is inevitable, and even unavoidable. And that's not necessary a "bad" thing to avoid as it provides valuable life insights and growth in its own way.

One of the key things I've learned is that the weekend is not for recharging. Every day of the week is. There's that quote goes "now is the time to put away childish things" - and also its complement, at the end of the day, guarantee you have a structure allowing you to do something you want to do for a few hours.

I'm curious why the article was started with:

> Working at a startup is demanding

Is there a corollary "working at an established dinosaur is relaxing"?

I've worked for 10 years at a company that is celebrating its 50th anniversary in a few months. I've been through at least two burnout cycles. Peers have experienced the same.

And I've experienced it at the other 4 companies I've worked at. I don't think startups have some special corner on the burnout market.

Sometimes, I've survived the burnout cycles for another go, but in the end in fact, each time I've departed a company it's been because of burnout of some sort. It's usually a realization that I've made the difference I can make (which may be zero) and I've exhausted all my ideas to make the compnay/product/team/culture/solutions/whatever any better.

Sadly as I skimmed through this list, about the only one that I thought would have had any dent in my various burnouts would be #7 - Express Gratitude. And I'm not sure that's really it. I think at the end of the day, what I have found lacking is a sense of respect. These companies pay so much money to employ and task software engineers, and then they try to put them in harnesses and treat them likes horses.

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 result of this, people will feel better, more valued, and will perform equally as well. It's not like you can really clock out of a software job especially in the remote world, so days off are more important.

What actually burned me out when I was an engineer was conflicting signals.

At one company our team worked ourselves into a froth and got a major multi-year project done 8 months ahead of scheduled and millions of dollars under budget. Everyone on the team was given a sizeable spot bonus and a public thank-you in a company all-hands... then they proceeded to lay off the entire team.

At another company, I clearly raised concerns about a new product ahead of launch, was told that my concerns were invalid, then the senior engineer on the product team left the company, then most of the other devs left, then management went live with the launch on time even though it was not ready, and I was expected (and followed through) on keeping online through the launch rush as the assigned Ops person. Afterwards there was never any acknowledgement of the fact that I was 100% right in all of my criticisms and that their failure to address them directly lead to the lost of 5 people, forced me to work significant overtime (the first 3 days of the launch I didn't even leave the office, I slept on a couch), and that had they addressed them properly it would have increase revenues. Senior managers lauded the product and considered it a success... I considered (and still consider) it a failure, and it's still inferior to competitors that entered the market later and did things correctly, the way I would have done them.

What would have helped me is that when I felt successful, that my management felt our team was successful, and then treated us like we were successful. When I felt that our team was failing, that management would have treated us like we're failing (additional support / time). What happened instead was mixed signals that always resulted in a net benefit to senior managers and a direct net detriment to the engineering teams, and myself personally. A cynical take would be that burn out is caused by senior managers being selfish assholes.

I’m going to use this post as an opportunity to tell people about Amazon.

The company has some of the most incompetent managers, who under pressure, will throw their own people under the bus. By incompetent, I mean “yes” men who tell 10 different people exactly what they want to hear.

These are people doing the bare minimum to keep their own jobs, and when things go off rails, they pass the blame to everyone around them, without ever accepting any responsibility.

It’s the opposite of everything described in this article.

I’ve been in meetings where VPs acknowledged their expectations on a service launch had led to 60+ SDEs leaving the organization or leaving Amazon entirely. They had no remorse.

I was personally told to not get involved in day to day matters and keep a distance with engineers in my own organization, so I can better focus on doing what’s right for the company.

The other problem was that the L5/L6 managers, often without US permanent residency status, would simply cower out of fear of losing their own jobs. If such a manager loses their job, they have maybe 30 days to find another employer who provides them sponsorship, or otherwise they have to move back to India.

This led to managers not acting on their teams interest or protecting their engineers. Instead, they do everything to protect their own careers.

I’m convinced most L7+ managers at Amazon have no ability to empathize with engineers. They are literally coached (like I was) on avoiding it. It’s a sign of weakness.

I do NOT recommend working at Amazon. It’s a form of suicide for your physical and mental health.

>Encourage time off

The best way to do this is to mandate a minimum time off. I've been lucky enough to work a couple places where this was the policy. This has to be a top-down initiative.

>Increase headcount

Definitely. I've seen short-sightedness prevent this from happening and it doesn't end well. In fact, I once quit a job where I was gradually taking on additional work (without additional pay, of course). I probably wouldn't have quit if I had one additional person to help me. When I expressed my concern I got "we can manage our workload right now." An ounce of prevention is worth a pound of cure.

>Express gratitude

Yes, but do it with cash. Don't send trinkets to people's houses - just give them the cash instead. It can get really insulting when you're rewarding people with silly trinkets then saying there's no room in the budget for a pay increase. (Been there).

I have been on the edge to burnout. Reasons why.

Incompetent people always stress everybody up:

They put enormous pressure on single persons.

They steel a lot of time and energy.

They try to get other persons to do their work.

They always sidetrack everybody into quests that are not important.

They never solve anything. Every solution to a problem comes with new problems that are more difficult to handle.

They always blame other people for everything, especially people they can get rid of.

They think delivery is more relevant than things work in production.

Cringey type of article - tbh. It reads a lot like - “people are programs - here’s how to optimize them further.”

Which is exactly what causes a lot of burnout to begin with. People being overworked or worked in such a way that only optimized for the manager - and no one else.

I find myself having not worked insane hours very often. I’ll be real - I’ve never worked much more than 60 hours in a week. (Excluding college) Even then - those were exceptional. However - I’ve been “logged in” for 80+ hours many times. Constantly consumed by the ideas of work, what’s going on, hating my manager, disliking the systems we work in, etc. in some sense it might be better to just log more hours in the chair and actually do a thing that might move the needle but honestly - I’d rather not. I feel they don’t deserve that and when I have done it - it never was recognized or was substantial enough to move us forward or change the fundamental cultural issues.

The fundamental issue is that managers in tech treat people like programs and not like human beings. I know this happens outside of tech too but we try to act like we don’t do that here. But we really do. It’s all a lie.

It’s insane how much lying we all do just to get by. Sometimes I want to found a company just to see if I could actually get rid of the bad incentive structures and actually have a radically honest and helpful company that was driven by compassion and enthusiasm for helping one another. Far fetched tho - I’m not really into brown nosing anyone, VCs included.

I burnt out; I burnt out hard.

I haven't worked in a couple of years (the most positive thing I can say about my state of mind is that - after a very large dose of black market mushrooms - I'm no longer suicidal.

The one thing that was the primary contributing factor in my spiraling downfall is not mentioned here.

Listen to your fucking developers - the one's at the coalface (either they know what they're doing or you've got far deeper problems).

I was the primary developer on the non-DB functionality of the company's deployment tooling.

I took the most cobbled together piece of unmaintainable shit and converted it into something stable and maintainable.

There were times that I needed to make significant changes in order to move towards something sane.

And every time the boss would bring in his pet architect who would veto every effort I made with no feedback what-so-ever.

Just a no.

I want to modularise the project - no, it's not justified by the scope of the project.

I want to move to hierarchical configuration files - no, just keep using blah.properties, despite the fact that that we were using dynamically generated keys to force that which would be cleanly implementable with XML or JSON.

I want a robust solution for dependency injection, I'm thinking Spring. No, too heavy for the project - just use META-INF/services.

Yada, yada, yada. Every damned time. I ended up running the development of a critical utility as a god-damned skunk-works project.

It was soul destroying, but I believed for a long time that the results I produced (the stable releases, tasks that took a fraction of the time they used to) would lead to my input being considered.

It never was.

Recent burnout recoveree here, opinion: your company is unable to fix the problem for you.

The only way to fix it is for you to learn to actually Not Give A Fuck. If you are forced to, for example due to immigration or family reasons, then I don't have any useful advice, sorry :(. Otherwise keep your savings account at 6, 12, ideally 18 months worth of living expenses and don't worry about performance reports, unanswered emails, "failing" your coworkers, etc. Do about 50% of what you can actually deliver and ride along. I actually think this is also better for the company, because workloads expand and contract sort of naturally, so by keeping this margin of 50% you'll be able to handle tougher moments.

Once you get to a dark place: counseling (psychologist/psychiatrist), medication, taking 3+ months off - great stuff, can definitely recommend. Start with a visit to general practitioner.

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.

“Managers should create space to celebrate small wins and reflect on the mountains you’ve climbed.”

I personally can live without the BS celebrations. Make sure the the daily work is bearable. If you are a manager do your job and manage people and the work. Don’t just pass on orders from above and pass metrics back to above.

This seems like a pretty weak list to be called a "Toolkit". I think burnout is like another major issue: boredom, and both share the common trait that by the time a manager is aware of it, it is too late to address. Tips like "be positive" and "express gratitude" are table-stakes to being a decent team member; they're not nearly enough for a manager to to proactively address burn-out. Increasing headcount or reducing scope are rarely in the control of a direct manager. Nothing here attempts to address the underlying causes of burnout that include: boring & repetitive work with no slack in the schedule and a persistent expectation of fighting fires and noisy, immediate delivery.

GitLab team member here.

While this blog post looks at what managers can do, we've also recently started using Yerbo (Slack app) internally to help individuals to assess their own risk of burnout. See: https://about.gitlab.com/handbook/communication/#yerbo-slack...

Mental health and well-being is always a concern at GitLab (ex: the Friends and Family days that we implemented and maintained throughout the pandemic to ensure team members are taking time off). This month, however, we've been adding additional focus to the topic as May is Mental Health Awareness month.

I've never gotten burned out because I had a lot of work to do. Those are the good times.

Mostly I've gotten burned out because I couldn't bring myself to care and because I was bored.

Short-and-easy read that contains much truth. Especially item #10, "Lead by example" which encourages managerial review of recurring meetings (which often boil down to "well, here is my Excel sheet, you tell me how you're doing on each line item: I'll let you talk a lot, but I'll only jot down the completion percentage in the end") is worth emphasizing.

I've had pretty bad burnout earlier in my career and this is what I am doing now

* Better frameworks. If a framework adds complexity, it needs to enhance the feature set and developer experience by 2x. Otherwise, I just stick with the basics. Example: I was working on a react codebase with insane level of hooks, contexts, 7 layers of abstraction. Solution: Axios/Fetch right next to the form, entire backend functions in the controller: no f's given.

* Business requirements first: I hack off 90% of Agile methodology and just do what makes sense. Which is a balance of acceptance criteria and user stories, or contract driven development to pull the features into production and deliver.

* Thursday and Fridays I don't work, and if it do, it's on something completely new or exciting. Last week I played with DallE as an API. Unfortunately this means less pay.

* In the winter if its sunny out, I leave around 2pm. And come back and work 7pm-10pm.

* One meeting a day, or every other day. And Monday's meeting I come in fresh and excited, cite what I am grateful for, and talk about how incredible everyone's effort is. It can sound cheesey but it works for me.

Last burn out was right before the pandemic. I took a position at a startup that told me they were light on meetings, but I ended up spending all of my time in meetings and getting absolutely nothing done. So I left, and took a big break. I forgot a lot of things but realized what I forgot were skills didn't matter. Attitude matters over skill. I am not interested at all in React 18 and instead focusing on Vanilla JS, HTML5, just regular CSS, and just SQL. Day in day out skills. Stuff that won't change in 10 years. If I forget something like a new feature in React 18, then my mind is telling me it is useless in the long term.

The most insidious cause of burnout is excitement. To be excited about a project, to be important to it, wanting to be a hero, wanting to be looked up to by your coworkers, is such a powerful motivation to ignore your own health. And it is exciting/interesting to see what your limits really are.

The best thing you can do is develop habits that help you recover at every timescale. On the smallest timescale the Pomodoro Technique is really, really good at least in part because it quickly proves you wrong if you think you shouldn't stop because "momentum". Never, not once in using the technique, have I ever lost momentum and in fact quite often I come back to the problem with much greater clarity and speed. (Note that taking a 5 minute break every 25 minutes is entirely different than taking a meeting or working on another problem. Those are context switches and are the worst of all worlds - you're not working on the problem AND you're not resting.)

On the daily timescale, morning meditation serves the same purpose as the 5 minute break, but it's more intense and more holistic. I see it as giving you "headroom" for your day so you can deal with things as they come, with equanimity. My worst days have always been the ones where I stubbornly refused to meditate (and I often do that because I have been meditating regularly and feel like I don't need it anymore. Ha. My mind is sometimes a real dick.)

> 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.

Gitlab you are not a startup, don't make me laugh.

Here's a good tip for managers of engineers. Don't be GO all the time. Let your team work on non-roadmap items every sprint. Every last Friday or whatever.

Don't give your team huge high stakes tasks every time. Give them candy in between to relax a bit and recharge. This job will break your mind if you don't cool off.

A couple jobs ago I got very burnt out, MSP where I was the only senior tech left. 60-80 hour weeks for many months straight. I was so burnt out, that I became extremely defensive and worried I was imminently about to be fired literally all the time. Here's what my boss did relative to this list, it's a funny parallel:

1. Disallowed taking vacation because they couldn't afford for me to be unavailable. Overtime was switched to time off in lieu but couldn't be used. I complained and got special dispensation to get overtime paid out.

2. Increased pressure, I was afterall the person who held the place together. New clients are needed to keep the business going right?

3. Regularly micromanaged and brought to light any and all mistakes like prioritizing my tasks incorrectly. I shouldn't have worked on X, I should have worked on Y.

4. Hired fresh out of college people and expected me to train them. I couldn't give anyone any work. I was expected to train them during lunch periods.

5. Certainly provided coaching, see #3 on how to prioritize tasks well.

6. Reminded me regularly that I was disposable. Even came out that he was actively looking for my replacement. Debian, postgresql dba, cisco and hp enterprise networking, MCITP, typical microsoft enterprise stuff, etc. My replacements were way too expensive for some reason.

7. They did have various things in the office like foosball lol. Very cliche at the time. They sold it because we were too busy to use it.

8. Absolutely celebrated progress. There was weekly meetings about salesforce metrics. Like how many hours each of us were billing out. I did very well here. Coworker who did get to take vacation came back to one of these meetings and got publicly chewed out for really bad numbers... because he was on vacation...

9. No sympathy. He explained that he was too busy doing sales and managing. He would regularly say that if he had the time he could go do my job easily.

10. Oh yes, he would affirm that he was the one working the most in the company. 100+ hours he said. I'm not sure what he did. He refused to cold call. He didn't do accounting, there was people for that. He didn't do tech work. Sure he spent probably 10-20 hours a week micromanaging.

11. Reduce hours? I remember this one time where I was headed out of the office to a client site but this was maybe 20 minutes before the usual end of the day. I got chewed out for trying to skip work and go home and be paid for no work. I stayed silent and took it. Anyone who would leave 1 minute after the hour wasn't in the wrong but there would be comments made.

12. There was a small list of banned words. You would be punished if you ever accidentally said "I'm too busy to do that right now" Busy was a banned word.

Minimum wage about 10 years ago was maybe $12/hr in my area. I only earnt slightly over $20/hr for this job. The stress from this job got me so sick, eventually I ended up in the ER. While in the ER he had a coworker 'find me and determine if I am still alive.' mind you... he knew exactly which floor I was in at the hospital.

After I got onto sick leave, he made the ultimatum that if I don't get back to work I would be considered as quitting. I replied explaining that it sounded illegal to be firing me for getting sick. He backpedaled quickly on that. Few months later I got fired anyway for no reason.

I got a new job. He lost a significant number of clients. He assumed I was stealing his clients; of which only 2 actually followed me to my new job. I got sued for 1.1 million $ for poaching his clients but after they found out that none of clients he listed were even either of the 2. They didnt even realize they lost those 2 yet. There was no non-compete or anything, the assertion was that I was a fiduciary employee obligated to protect them even after my dismissal. They wanted to drop the lawsuit, ended up costing me $2000 for a lawyer.

Cynical idea, for Senior Management: Make sure less-senior managers know that you're always alert to the dangers of developer burnout. And that your #1 "quick fix from on high" idea for addressing developer burnout is to downsize the intermediate management, then use the $Savings to hire more experienced developers.

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.

I got burnt out and it took me 3 years to be interested in tech again.. even now I'm not at prev level of starting GitHub projects, going to hackathons, and reading tech books. I was done done. I attempted random entry level jobs in different fields.. video editing, cold calling, marketing, and more

I believe the most important tool to prevent burnout is slack. Not the app, the word.

Slack gives you choice. The choice to work. To have fun. To do nothing. Slack allows you to deal with less bullshit. Less waste, not more production. Less always-on anxiety and avoiding stress completely.

These "manager tools" are not to prevent burnout. They are a list of things managers probably should be doing but don't. They should already be commonplace in any working environment yet many are so barren of them.

1. Encourage time off - It's usually up to the individual to take time off and lookout for their well being. It could be a nice thing once and awhile for your boss to "gift" you a day off. Please don't encourage me to take my own deserved time off though as I have plans for it.

2. Lower the pressure - I don't see how a manager can control this. Some goals are external to the team/individual and people still rely on you to complete the work. If a manager can convince senior leaders to cut certain goals at risk of attrition, then that is their job, not mine.

3. Be more positive - This is a given. Don't know why it needs to be mentioned that positivity begets positivity.

4. Increase headcount - This is a manager's job. But don't expect increasing headcount to improve any condition of burnout just by adding more people to problems.

5. Offer team members coaching - Sure this would be nice, but most companies only offer external coaching for senior leaders and above. ICs and middle managers hardly will see this benefit. Their manager is supposed to be their "coach" and hardly many are qualified to do that nor does it even provide benefits given the role power.

6. Remind employees of mental health care resources - I'm sorry but every resource i've tried that's corporate sponsored is garbage. At least in my experience. The services often ghost you and the corporate sponsored quotas are like 10 emails total. Not enough to even chat about burnout. Everything meaningful is something you still have to pay for yourself (at a discount, but still). Running and walking is free though!

7. Express gratitude - This one is missing all over corporate America. A simple "thanks" goes much further than you think. Especially those that are genuine and out of the blue. For some reason managers tend to not use this "magic" word.

8. Celebrate progress - One great way to celebrate progress is by discussing career growth too. Although chatting about "small wins" and reflect on mountains you climbed is nice in retrospect, you do all this in expectation of a "reward" at the end of the day. Yes some people may genuinely care for their work (I do too), but I still expect these things to lead to something greater. More responsibilities, more compensation, etc.

9. Sympathize - It's hard to sympathize or even empathize. The work is completely different and even if your manager did the job you are doing at one point, you might be doing it better or worse than them. It's hard to relate in certain job tracks. It's nice for a manager to hold the space, but really coworkers and peers usually do it much better.

10. Lead by example - This one is hard for me. I've never had a manager who leads by example. The examples they lead by are not ones I would follow anyway because I'm not going to be answering email at crazy hours of the day because I value my life outside of work more. Sometimes I do check email at night, but I "send them later" at reasonable times in the morning. No way in hell I'll add email onto my personal devices though.

11. Reduce the number of hours worked by agreeing to reduce effort - This is usually through 1:1s or team syncs / sprint ceremonies. Sadly managers do not listen to the boy who cried wolf and reduce projects or efforts accordingly. Many of us know that when this happens, we just enjoy the crash and burn or feign ignorance instead of "I told you so".

12. Share burnout concerns with others - While I used to do this, it has also been detrimental to my career. I become a "flight risk" because I'm exploring my options and now I'm suddenly valued as much as I knew personally. I shouldn't have to resort to this option to feel appreciated. As much as I enjoy talking to others about burnout, it just all sounds like we do so much work that we aren't feeling appreciated enough with (money, recognition, etc).

How to prevent burnout:

Do what you can do, not what someone else wants you to do.

Yes, you need to make money, you can do that too.

This list is missing some stuff...

* lacking a feeling of control over your own success

* removing bureaucratic road blocks in the way of success

* lack of dopamine reward when you complete a project / disconnect from the consumer of your product

I don't think I've ever had a manager that has checked even a single one of these boxed, which I guess explains why I'm so burnt out that my (non-solo) software career is likely over.

What to do post burn out might be a useful resource as well.

> Express gratitude.

Maybe the key is to feel gratitude.