Burnout is real – how to avoid it
atlassian.com
atlassian.com
I've found that doing all the non-work bits of advice helps, but it doesn't reverse the trend. It only slows down your burn rate which can be dangerous. You begin to think it is under control when in reality, you're like a frog in a pot slowly being boiled alive.
To really combat burnout, large influential companies need to target these types of articles at companies themselves, not individuals. We are beyond the point of calling out individuals. Notice how all of the language in this article (until #8) is centered around you. You are supposed to take full responsibility for burnout. It is your choice. Your lack of self-management is causing your burnout. But sometimes, it's really not you. It's them.
I hope the community begins to realize that responsibility goes both ways and shifts the focus of these conversations onto companies. Don't put the entire onus of burnout on the employee. That is avoiding responsibility and too much of it can make it appear to be victim blaming. Start talking about how companies can change culture around this, train management to recognize it, and what it takes to make this a top-down effort instead of a bottom-up one.
A good start to this conversation can be: What does Atlassian (or your company) do to prevent burnout throughout their company?
...give notice and quit. No company would do this if they weren't completely toxic.
Crazy hours are not something driven solely by management.
There are points in time at which this isn't viable.
Those bordering on, or prone to, burnout, may have a lesser degree of capability to act on this.
Internalising the costs to firms (and their investors and creditors) fostering burnout-inducing conditions may be a more effective mechanism. Destroying 2, or 5, or 10 years of peak-career productivity should carry costs.
It's up to you to ensure that your "no's" can't be ignored. Really what shy programmers need is confidence and healthy boundaries.
It's unsurprising to see comments that revert to pinning the blame back on the employee. That's how the narrative has been formed and controlled. It's also a product of the "self-made person" idea where you ultimately have all the control over where you end up in life.
As a side note - not everyone is speaking from the position of being a programmer. Burnout is affecting many other careers. This forum just happens to be tech centric, but I do hope that stereotypes and assumptions can be minimized.
"Do you want someone who will tell you want you want to hear? Or do you want someone who will tell you how much it's gonna cost?"
I did get better at saying no and establishing my boundaries. But that itself is still exhausting. The best move I made was recognizing the culture there had shit respect for developer boundaries and switching to a company that does.
There are places and people that will take advantage of the fact that many developers do not want to say no. Do get better at saying no. But also get away from those people.
Unless you believe the “Shortage Of Engineers” meme, intense labor competition is a huge contributor to industry wide burnout.
This problem should be self-correcting. If it's as unproductive as it is unhealthy, then better companies will win by retaining talent for longer.
Also, the best developers rarely come on the market, they go straight from job to job thru good relationships with previous managers and co-workers. Managers who abuse workers are not usually able to retain the best talent, they end up adversely selecting for the least productive talent.
1. New engineers, and it's certainly valid. The net pros and cons of your abilities are equivalent to those coming straight out of college. You must set yourself apart from the competition by putting more time into your work or increasing the quality of your talent.
2. Experienced engineers who work for companies that devalue personal growth, and that is valid too. Our most challenging daily work will usually come from employers -- If that work isn't mentally stimulating, you're not learning anything, and nothing is being meaningfully done to separate you from those college level entries.
3. Experienced engineers who work in fields with a lower barrier to entry, and it seems valid to me. If your company's projects are more resilient to the mistakes novices will make, or there are less mistakes to make because it's easier to understand, it's difficult to increase the quality of your talent in a competitive way.
4. Experienced engineers who knowingly have poor talent quality, and it's valid. It's challenging for some people to critically think, to navigate the abstract nature of engineering, and to learn those deeper concepts that typically separate experts from novices -- And that is surely difficult to overcome.
5. Experienced engineers who believe they have poor talent quality but are indeed quite talented in meaningful ways, and it's invalid. It's imposter syndrome and it's absolutely rampant in our industry.
6. Experienced engineers with good talent quality but poor interpersonal skills, and its validity depends on your interpersonal growth. If you're not great at negotiating or you intensely value validation, you're certainly at risk to being taken advantage of, and not necessarily with malice on the company's part.
There is definitely a shortage of engineers with high talent quality in fields that require it. Many people believe weekly hours are the only competitive aspect of our industry and it simply isn't true in many cases.
While we will almost indefinitely feel pressure to stay busy, talented engineers have far more leverage to push back than they realize. Great engineers are hard to come by and many companies will work hard not to lose them.
Yes, this! My company seems to be halfway there: acknowledging that burnout is a problem, but then turning that into helpful advice (eat healthy, take breaks, go work out, etc) that is focused on the individual, ignoring cultural factors and the total amount of work that gets taken on and needs to be done by X people in Y time.
It's even worse than this because, all of the factors you mention are actual risk factors for burnout (pressures, lack of control, isolation, fighting)
I agree completely with this, since this is a health AND socio-cultural problem. Trying to solve the problems without the necessary cultural resources in any organization will just put a heavier weight on the worker, and it will eventually crack him. Without true commitment this is a Catch-22.
But these sprints normally are done repeatedly with no actual stop or sight of a finish line.
Employees just churn through tickets with no designed breathing room or planned downtime. Jira is probably one of the biggest helpers at causing burnout with all of those burn down charts and story point comparisons, driving companies and employees to not support taking reasonable time off or spending time at lower pressure to encourage employee wellbeing.
Basecamp’s team wrote a guide to their take on this process and why they rejected it called “Shape Up” which seems pretty pie in the sky but makes some incredibly good points on maintaining team happiness, culture and quality of work.
why would it it be "above sustainable pace".
Humpty Dumpty smiled contemptuously. 'Of course you don't — till I tell you. I meant "there's a nice knock-down argument for you!"'
'But "glory" doesn't mean "a nice knock-down argument",' Alice objected.
'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.'
-- L. Carroll
High-intensity long-haul efforts can require months of recovery, or be permanently crippling.
The 100m world record is 9.58s. The world-record marathon pace, 17.2s/100m. The Race Across America 3,000 mile bike race record, a sustained speed of 12.57 mph, or 17.8s/100m.
The specific physiological mechanisms for physical and mental exhaustion differ, but the general principles are similar: metabolites, waste products, side-effects, and damage accumulate. Absent a period of rest and recovery, these will eventually prove damaging.
In sport training, there is a carefully calibrated set of activities and rest and recovery, ranging from in a given motion (power and recovery stroke in running, cycling, swimming, rowing, or virtually any other action), to exercises, efforts, sets, workouts, seasonal, and lifetime scheduling.
Speed, skill, and muscle aren't created on the track, in the pool, on the road or trail, or at the gym, they're created in bed, when you're asleep, during recovery, given adequate nutrition. Training is stress, but a stress that's calibrated to trigger a conditioning response.
If you don't get rest, you'll simply break down.
There are reports produced that developers don't get to see that the manager does to compare developers this way.
Of course, this can be easilly gamed. The most cunning developers will go out of their way to get the tasks that are clearly defined in scope and that they are familiar with, while others always end up getting the short end of the stick.
Guess who is going to look better under that report. Developers are overloaded, and will actually avoid to raise new issues or suggest improvements and new tasks, with fear that they will get more work on top of the workload that they can't already handle.
JIRA is really used by middle management to treat developers as essentially replaceable assembly line workers in a factory context.
We use JIRA and we find it extremely useful, although we never use real-time values for estimates or reporting. Story points, which I believe are recommended by the Agile framework, are used to estimate and draw burn down charts and reports. We can then use these to adjust our estimates for future sprints.
JIRA really is a tool and just because some managers use it poorly, doesn't mean that is why it was created. Those managers would be bad regardless of the tool.
I think the more fundamental issue is that most businesses that existed before and after digitization don't really understand or appreciate that they are alive because of that transformation.
Most tech enabled companies do not understand that competent IT execution is important to their ability to have freedom of movement and the ability to respond to change in their markets.
Also Developers think developing is important, but also business thinks business is more important and they got by with paper and phones for a long time before computers turned up.
Both are fair points.
I would say that quality of life at work (in tech) is a function of how much the business thinks that the work you do is important. Is IT a cost center or a capability factory where you work?
In start ups and tech focused companies the core work is technology so it's easy to understand the investment. But places where IT isn't core work, developers are just cogs. They get treated like crap and are made to sprint because who cares, the 'actual' business is important.
Lastly, IT workers talk a big game about Unions but I'd really like to see the day where a strike by IT workers starts with them walking off the job after turning off the network.
I think Atlassian is the Uber of the software development process and devs are the drivers.
Death by metrics isn't the fault of Jira--Jira provides tools to do many things more effectively, and gathering metrics is just one of those. Providing effective tools to ineffective people, unfortunately, does allow those people to shoot themselves (and in management's case, everyone around them also) in the foot more easily.
Exacerbating this, as you mentioned, is that metrics do provide a simple, cheap representation of productivity, even if that representation is not aligned with reality. Middle management can present this to upper management to show that they're doing a "good" job, and upper management will be none the wiser about what's not exposed by the metric until a while down the road when problems created by optimizing for those metrics become more apparent.
A team that is doing agile right is not "sprinting", they are completing as much work as they can do at a long term sustainable pace.
Oh, please stop with the "because you're doing it wrong" defense. Yes, I most likely am doing it wrong, I already know that. Is the fact the process allows the level of flexibility for me to screw up this bad a feature or a bug?
I'd love the opportunity to practice Pedantic Agile but things like customers, coworkers and bosses keep getting in the way.
One project is in Sprint #17 this week.
One is on Sprint #41 as of Wednesday.
One is on Sprint #56 as of this Friday. On top of that, the weekly meeting is set at 4:30pm on Fridays in my time zone. The sprint planning meetings typically go 2 hours.
Each project has a daily stand-up too, each lasting about 30-45 minutes. I get about 3 hours a week total to actually code.
Yes, this has effectivly killed the entire idea behind a sprint and agile in general, we all know, it's super obvious. But the company is now an 'agile' company as of ~2.5 years ago, so we can say so in the job apps. All the interviewing devs know to ask about how long the stand-up is, we tell them the truth, and the job apps stay open when they decline our offers (we also pay under market rates). Our copies of 'The Phoenix Project" remain in shrinkwrap.
Majority of managers will always be mediocre. But previously, managers without tool just let the developers do the job. Nowdays, mediocre managers have industry standard tool to make everyone life terrible and destroy the product by accumulating bad decisions founded on jira/agile metrics.
Also, jira and agile gives management ability to be extremely shorter oriented in their reasoning - that is major factor changing dynamic in the team.
In the modern workplace, workers are often given a task without being given the good conditions to take it through, or a good overview of the context that the task is part of.
A good percentage of the tasks but not all are hot potatoes, and it can get very political (in some places this is worst than others, but its always there).
You get to the office in the morning and have new 10 trouble tickets assigned to you, with estimations of 2 or 3h of execution time over which you have no control, estimated by a clueless middle manager who has never coded the simplest of programs in his/her life.
If you make too many waves or comments about the length of the tasks, you are not going to last long and you know it, so what do you do?
Stay late, take shorter breaks, connect one hour in the evening to get a couple more things done or do some preparation work like analysis, reading documentation, answer emails, etc.
If you don't do that, you know that it's a fast track to performance improvement program which is essentially a death sentence.
I think the problem is the system and not people, the current employer/employee social contract is needing a huge rehaul because society is coming to a breaking point which all these jobs disappearing due to automation and informatisation in general.
I've never had manager who hasn't coded ever in his life. WhatI had most of the time was a manager who hasn't coded in a longtime.
The non-technical manager will focus more on the business side and will be easier to manage in many situations, but the problem is that that type fo manager will neglect tasks that are purely linked to technical debt, refactoring etc that don't add new functionality to the system but are still really important.
Did he suggest an alternative ?
Plus, threads and processes are essentially the same on unix land – kernel flags will control behavior like shared memory. Which you can still setup manually. Or just use whatever IPC fancies you.
Running on how many CPU cores? Were you writing code for a supercomputing cluster? Otherwise for what kind of system could 10,000 threads possibly be an ok strategy?
Can't wait for 64-core Threadripper to have something similar at home in a little box ;-)
It's only happened to me once, but the guy was pretending to be a past Java expert and didn't know the difference between Java and Javascript. I don't mean we grilled him on the differences in syntax. I mean in conversation he would use "java-script" to mean a Java source file, and said he had experience with Java frameworks like jQuery and Angular. Don't know how he expected to fool any developers, but he actually kept the job longer than I expected, even with people calling him out as fake.
Putt's Corollary: "Every technical hierarchy, in time, develops a competence inversion." with incompetence being "flushed out of the lower levels" of a technocratic hierarchy, ensuring that technically competent people remain directly in charge of the actual technology while those without technical competence move into management.
https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successfu...
If we are going to be treated as factory workers, we should defend ourselves as factory workers by creating unions.
Unfortunately, due to the volatility of tech skills and the overuse of one-month contracts, I don't see this happening anytime soon, but I agree it's the only solution.
I've worked in the industry for 10 years and have never seen any of this, except for three people who were PIPd.
Totally, totally this.
To make an analogy, many companies seem to be run by a crazy crossfit overtainer dragging everyone else into workouts that are like the Bataan Death March.
I agree 100%
For me, I found two workable solutions.
1. Get to work at 6am and get a ton done before 8am, or stay after 6pm and get a ton done. I basically write off the hours of 8am-5pm, knowing I'll achieve essentially zero due to meetings, interruptions, 'urgent' emails, etc.
2. Get to work at a normal time, put my stuff on my desk, reply to a couple of emails so people know I'm around, then I take my laptop and sit in a local coffee shop with headphones on. I can get actually 6 hours of work done in an 6 hour stretch. I'm not far away from the office if I must attend an 'emergency' meeting, but I'm not at my desk getting interrupted every 13 minutes.
Usually the success of the second one depends on if your manager respects you actually getting work done.
3. Reduce the amount of work to be done. (Probably by more than half.)
Since when was taking what amounts to a six hour exam every single day acceptable?
Also, you will have the tendency, no matter how early you start, to always leave late anyway, at least that's what happened to me so I would end up getting in slightly later.
As for option 2, it's really not an option for the majority of companies. The things you need to work are on the internal LAN, you have a desktop and not a laptop, etc.
The constant interruptions either in person, by email or chat in the open space prevent from getting anything done, I used to stay later and have my most productive hours late in the evening.
Still, there was occasionally some colleague that would also stay late due to having to catch a bus or a plane and would chat all the time.
It was doable, but I always felt I was constantly living on the edge, always scrambling to get things finished in the last day of the dealine, thinking what I'm going to say on the status meeting that immediately interrupts the work at the beginning of the morning, etc.
The only thing surprising to me in these working conditions is how there are not MORE people burning out, I suspect it happens to a lot of people at least once, and then they learn to recognize the signs and leave the company before things get to that point.
But I don't think it's about taking more yoga classes, meditating or whatever, it's the working conditions and not the people.
People are getting grinded like beef chuck by these companies, these working conditions are literally taking years out of peoples lives, and no one calls out these companies by the harm that they cause to society.
Also, a lot of the work people are so busy with is completely unnecessary and people know it. Several times I was scrambling for deadline after deadline doing super "urgent" stuff, and one day I left and I literally wasn't even replaced!
Really...this is their example of healthy boundary setting? A professor who says he's available the entire time he's awake, but won't answer emails when he's supposed to be sleeping.
Average healthy sleep time is 8 hour a day. Even if it's less for some, this professor can be disturbed when he eats ? When he is in his shower ?
Seems strange to me.
Math professors aren't known for showering :)
> * You drag yourself to work and have trouble getting started
> * You’re irritable or impatient with co-workers, customers or clients
> * You lack the energy to be consistently productive
> * You find it hard to concentrate
> * You lack satisfaction from your achievements > * You feel disillusioned about your job
> * You use food, drugs or alcohol to feel better or to simply not feel
> * Your sleep habits have changed
> * You’re troubled by unexplained headaches, stomach or bowel problems, or other physical complaints
You say "burnout symptoms", Corporate says "reasons to fire you". Potato, potahto.
My plan now is just to save aggressively until 40 or so, then either lean FIRE or switch to a 6 month on 6 month off contracting schedule.
The only other option I can think of is take a job I might enjoy. But all those kinds of jobs pay poorly (relative to a software engineer’s salary), so I’d be locking myself into the working world for an extra decade or longer.
Edit: I should note that I realize I am extremely fortunate to be in the situation I am. I don’t mean to sound like I’m ungrateful for a lot of the things in my life.
This is the real answer to preventing burnout: focusing on getting to financial independence starting from the very first day you start your career. There is nothing more liberating and comforting than knowing you don't have to stay at your job one moment longer than you feel like it.
Granted, it's not an option for everyone because of their life circumstances, but it is for most people in the software industry.
And when is it going to mandate a change of langauge in Scrum from "sprint" to some word vastly more reasonable in designating a staged, sustainable, work effort?
The English language is in dire need of an idiom connoting the fox advising the henhouse. This post lacks all credibility.
(See above Humpty Dumpty "glory" quote.)
in case the original stalls
hobby - honestly just try a bunch of different things for a while and you might be surprised what you like. Take up gardening, hobby games (build/paint miniatures and play 40k, battletech, etc.), hiking, really anything that requires some focus and a bit of work. In a lot of cases its more about having something to do other than work and being tired/lazy/depressed at home vegging out and/or getting into a worse headspace.
mate/social circle - honestly this can be hard (especially if you’re really introverted) but getting into a hobby can open new doors. Also think about getting a pet or two. Animal companionship can really be more than a substitute for other people and fill you with all sorts of joys.
life purpose - this is really hard but honestly you and in complete control over this if you push yourself hard enough. Literally just choose something. It can even be to just live as long as possible despite any shitty circumstances (doesn’t have to be some grand unachievable goal).
I really hope I'm not stepping out of line but your message seemed like a call for help. I've had my own long spells of depression and some of the above have helped me a lot. Please also consider getting in contact with professional help if it’s really getting bad. Forget about shame, nervousness, or whatever had headspace your currently in, your life is 100% worth more than any of that.
Thinking about exercise, thinking about cleaning my room, thinking about doing laundry. I can sit in misery thinking about what needs to be done, or I can just start working.
I suffered burnout there. I had the misfortune of working as an "SRE" at Atlassian. The reality was you spent your days, nights, and weekends dealing with major incidents.
I do not know if it was a conscious strategy, but it would seem the approach taken to reduce organizational wide pager fatigue and burnout from out of hours work was to concentrate it on a few.
(My guess is that it was conscious, as that best explains why my cries for help whilst falling on seemingly sympathetic ears, yielded no changes.)
They forgot "unionize".
Remember, every time you attend a meeting while on your vacation, or answer an email at 10 PM, you're normalizing that behaviour. You're telling your boss it's OK to demand it of everyone.
Insane work hours and constantly availability is the epidemic here. Workers can de-stress their workforce by refusing to be available for more than 40 hours a week, and not worrying about doing outside projects if they don't feel like it. Employers can de-stress their workforce by not asking for more than 40 hours a week.
> Quick, who is also a professor at the University of Texas at Arlington, tells his students he’s always available – except between 10pm and 6am
This is the solution to burnout? Telling people you are not available to answer emails and send over quick spreadsheets when you're literally asleep?
Eh, what? I thought ICD-10 already had a code for occupational burnout: Z73.0. (https://icd.codes/icd10cm/Z730)
[1] https://medium.com/camplight/what-can-we-do-to-prevent-teams...
I mean...
> Track vacations and plan burnouts.
That just doesn't sound healthy.
Thankfully I'm ending my current job in a couple of weeks and will take a couple of free months before starting my next adventure.
Start of sub-title.
def: a widespread occurrence of an infectious disease in a community at a particular time
So a wide-spread, non-infectious phenomena that has been occurring... forever?, doesn't really meet the definition.
I'm not debating this is a real thing nor that it may be more prevalent, but a bunch of generic tips that put the entire responsibility on avoiding burnout onto me seems likely to increase the risks rather than address them...
The study of epidemiology hides its core principles well (most texts discuss statstical methods, rather than theoretical underpinnings), but they are: susceptible populations, adverse conditions, and vectors of transmission.
You can apply fundamental epidemiological methods to any phenomenon matching this general description. Generally, a vector involves some transmission factor which promotes an adverse outcome, and some transmission carrier, which communicates that outcome between affected instances.
To take a highly non-medical example: Iomega's Jaz drives, a removable, Winchester-style disk storage, in which platters and heads were separated, had a phenomenal capacity to create propogating media and drive failures: misaligned drives would damage heads, misaligned heads would damage drives. The condition could spread through an entire population of disks shared on a single drive, or drives in which disks were shared among systems. It was a phenomenally bad design. Disk/head misallignment was both the infectious agent and vector.
In public health, contaminants (radioactive materials, lead, asbestos, PM2.5, endocrine disruptors) can transmit adverse health outcomes among populations. Host-to-host transmission isn't generally prevalent (though some secondary contact may occur), but source-to-host most definitely is. Prions transmit MCD and YCS without a direct biological agent.
In the case of management and workplace factors, business organisation, management practices (or fads), and tools are transmission factors, and the educational, marketing, cultural, and ideological systems which promote those factors are the carriers.
TL;DR: Agile is a disease.
A pig In a cage On antibiotics