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.
> 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 summed up by your statement. It's great they're acknowledging it, but putting corporate make-up on it is cringey; it almost comes off like we are the problem and not the other way around.
I don't give a damn about "drinking the kool-aid" and I don't give a damn about your business theatrics nor the political drama that goes with it. Give me work to do and leave me alone to do it. That'll solve a lot of the burn-out.
American Corporations drink their own kool-aid, which is probably why they can sit there and talk about what's wrong concisely without knowing what to do about it. The days of servant leadership, or leading from the front are gone in terms of management. Instead, they're a self-serving bunch. Engineers are effectively the lowest on the hierarchy and their happiness matters to no one in the chain because everyone is serving the link above them. If software ever does unionize I don't think it'll be over pay, it'll be over stuff like this.
> 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.
that's super right. Got first hand unfortunate experience. The simple thing is: please managers don't buy the work-hard-to-compete ethos. It's not because you can take it that others can or should.
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 their work.
> 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.
I agree fully with this. I'm currently at a small company (which has a different set of challenges), but my experience is that large employers come up with flavor-of-the-year useless metrics in an attempt to measure progress towards goals and productivity.
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.
> 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.
Ditto.
At this point I feel that spending my entire day writing emails (even though I'm on engineering) would not only look better but would meet OKRs, while getting zero actual useful work done.
I'd shorten that to "Maybe it's time to admit corporations went too far pressuring the average worker".
It took me a long time to realize it, but work/life balance in the U.S. is weighted far too heavily in favor of business, at the expense of the individual and their family and community.
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. All stuff that pressures the Average Joe who just wants to make a living. For SE, the majority of these jobs are best described as "gluing APIs together", nowhere near the prestigious "you really gotta want it!" jobs they are sold as. Now add to that while SE does earn above average in all of these countries, it isn't so luxurious as a non-senior that you could pick your nose and live super comfortably no matter which city you live in.
So the pressure got worse and both intrinsic and extrinsic motivators are down. Add onto that a bunch of other societal problems. If anything, it's more surprising people aren't expecting half the populace to burn out at some point in life.
Is burnout a major problem in Asian countries which are famous for their long working hours? I'm thinking China's 9-9-6 system, Japanese salarymen, and South Korean gwarosa.
> Maybe all this goalsetting, OKRs and such is exactly the problem with the industry,
Yes, yes it is.
That is also a symptom of a bigger problem: management doesn't really have to be useful for the company, they merely have to _appear_ to be. Exceptional management is nearly invisible, which is great for companies, bad for careers.
The solution? Managers will make noise and a lot of it. Part of this requires crazy deadlines. If the ship is not creaking it's not being pushed hard enough. Attrition? Bad culture fit, we work hard, we play hard. "I delivered <project> months ahead of schedule" sounds way better than "I delivered it on time" - nevermind that the "delivered" project is a buggy mess noone uses and will require a lot more effort to get to an acceptable state.
We should be praising progress. Not everything should be a 'sprint', it should be a 'march'. What's all the sprinting for?
Most deadlines literally don't matter. Motivated teams that are able to perform their best work do matter.
> when most people just want to put in an honest day's work and progress.
> We should be praising progress. Not everything should be a 'sprint', it should be a 'march'. What's all the sprinting for?
I'm of two minds on this statement. On the one hand, "sprint" isn't meant to be taken literally in the scrum metaphor, in that teams aren't supposed to be trying to cram in as much stuff as humanly possible. But at the same time, the idea of each two-week period needing to have concrete goals, and failure to meet those goals being a negative indicator, is a major issue.
For me, the value of having deadlines, or something resembling a deadline, is to make it easier to get started. Once I've actually got the ball rolling, it's less important that the schedule actually resembles the plan, insofar as it doesn't affect other people. But my experience with scrum teams is that progress isn't seen as good enough. You have to execute on the plan, at least as far as scheduling is concerned, and cut corners if you have to.
The issue is this rigid equivalency of plan = commitment, and therefore deviation from that plan = failure. No, a plan does not necessarily mean a commitment. A plan lets you get started without spending so much time in decision paralysis. Once you're moving, the real plan evolves.
I think it's a bit more complicated than that. Pressure can be perceived even without expectations. I think especially junior developers have a hard time knowing which deadlines are actually important, and may tend to experience a much larger responsibility for the entire project than anyone expects of them.
In part this may be down to a bad communication style from managers, a good manager shields the team from worrying about clouds on the horizon; but this isn't always the case.
I've had people I've had to sit down and tell that this overtime they're putting in isn't expected of them, nobody asks this of them, it isn't their responsibility but the team got this, it's not worth burning out at age 24 over some sprint deliverable that's like just a cell in a spreadsheet that nobody really cares about.
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.
Since I started working from home, I have an alarm set for 4:50pm to remind me that 'work' ends in 10 minutes. I might choose to violate that deliberately, but not by accident.
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.
I have similar views on the OKRs. I am not even sure how they became so ubiquitous as a measuring stick. Did this come out of Scrum and just found a welcome place in general management speak?
I'm also curious if anyone feels similarly about daily standup meetings and the hyperventilating over the Jira board? I feel like I've been in environments where the goal seems to perversely turn into having something to discuss at the next days standup meeting.
I noticed OKRs and OKDs and whatever other flavour of it popping up after the big tech rise. Google and others were seeds of this style of delivery management, somehow this was taught in some MBA and when this generation of MBAs started to take reins of other companies it got spread around as gospel.
I fucking hate it, it's overloaded with rituals that get repeated every quarter: workshops, planning sessions, vision/mission workshops, and so on and so forth. The worse is that never seems that anything has enough time to be done, in my experience roughly a month of each quarter is mentally spent by going through these motions, justifying work that needs to be done, doing discovery for what's upcoming (that needs to be done before planning season ends). Constantly switching contexts about what we're working right now with what work needs to be done in the future, every single fucking quarter.
I'm getting extremely tired of this cycle, it's getting longer and longer to recover from each of these "planning seasons".
P.S.: Not mentioning the variance in processes, each company you join has their own set of rituals and timelines for planning and so it'll take a few cycles of it until you figure out what's important and what I can tune off and give my mind a break.
> 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.
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.
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.
As far as I know there are no different kinds of burnout. A burnout is always caused by long periods of stress exhausting the body.
The causes of stress can of course be very different. Working below or above your level can cause stress. But also long periods of physical pain can cause stress. Or being overstimulated all the time. And it can be a sum of all kinds of stress. For example when you struggle in a relationship it is much harder to cope with stress at work.
Stress eats your energy.
It's also difficult to prevent a burnout yourself because after a long time you can get used to being stressed. You forget how it is to be relaxed.
Sometimes it is just not clear what caused a burnout. It just adds up.
The best way to prevent a burnout and to recover from it is to accept you are stressed and tired and you need to step back.
This is also the most difficult thing to do.
I very much agree, it's a big assumption that burnout is only cause by too much work or too much pressure. When that assumption is unchallenged, it can lead to managers dismissing concerns about burnout because their teams are not overworked.
A lack of meaning to the work, or even a lack of work overall, can also cause feelings of burnout. A lack of obvious career progression can cause burnout. Constantly fire fighting can cause burnout.
So if someone says they are burned out, I always ask what is causing it before talking about solutions.
These are not two different types of burnout... They are one and the same. Pressure and overwork do not per se cause burnout... What causes burnout is if the effort-reward cycle misses (either repeatedly for small efforts, or if you put in a lot of effort and have a categorical miss)
Reward could be anything. The feeling of a job well done (easy to miss if the project is a failure, or if management pivots), it could be the expectation of career advancement, it could be soft recognition by peers... And is dependent on the individual and project. You could even have an outward success and a pay raise but if you wanted your peers to love you and they didn't.... Burnout. You could even have an easy and unpressured job and burn out if it's not providing the rewards you expect.
In any case the disconnect between effort and reward teaches your brain to associate effort with failure and the fact that the common. "take a break" advice failed for you should not be surprising, because I think that doesn't work in general: it doesn't reassociate effort with expected reward.
I feel like a lot of people here are using the topic of burnout to hoist their opinions about American capitalism or whatever, but I honestly don't believe that this is the root cause. Plenty of people work their asses off and are happy to do so because it can be its own reward, or, they know what they want and know how to get it after each brutal push of effort. But not falling victim to burnout takes self-awareness, or good managers (capitalist systems or otherwise - e.g. academia or military) and both of those are in short supply, blaming capitalism is much easier.
I think you are right. But the operating regime of your hypothesis is basically from naive entry until a point, and that point is when the expected reward transcends rewards that capitalism can provide.
If you want meaning from your work, and that meaning was initially provided by personal growth, then when the position no longer feels like growth, there is no reward possible. Similarly, if you thought you were doing something meaningful but then discover your company, or individuals who benefit more from your work than you do, are part of the problem, there is no redeeming it. To continue you have to resort to selective attention or basic ostriching.
If this is true then the primary protective traits against burnout would be 1) strongly established healthy boundaries around what to expect from a job and a healthy home life or 2) myopic focus on problem solving and a lack of interest or self-limiting that prevents curiosity about higher levels of organization. Anecdotally this matches with my experience — most people who endure fall largely into one or both of those categories.
A possible corollary is that with improvements to (that is, restrictions on) capitalism, more categories of people could continue to work without such ready disillusionment from bad or gray actors.
That's a really interesting hypothesis, and it would make sense. Is it something that you've come up with, or is there some literature I can read about it?
Get out of my head! This resonates with me - this is exactly how I'm currently feeling. Do you have any resources that were particularly insightful to you from your research?
I think that [1] was the article that first alerted me to the fact that there's different kinds of burnout and it's not one-size-fits-all. Other than that, I don't have too many resources. You probably shouldn't take my advice, because my burnout ended up with me quitting and taking a year out to work on a startup. However if you can leave and join a different team / company, I'd recommend it. By the time you're feeling burnt out, you probably don't have time to fix things.
I did try to fix the root-cause organisational issues, and actually did have a sizable impact with many of my suggestions having been implemented now. However, I ruined myself in the process. It was far more difficult than I expected, because it was a huge old-school hierarchical place. I wasn't paid enough to fix things, and it wasn't in my job description. I ignored that and pushed to fix things anyway - last I've heard it actually made a difference and some of the things I advocated have actually happened now, but it was too late for me.
I just got round to reading the Phoenix Project & Unicorn Project recently, and I'd recommend that. I saw an awful lot of similarities with my old company, and I think it would have helped to have that example of how to improve things. Even then, they were only successful in the book because they had management buy-in.
Take care. I do validate and recognise exactly what OP mentioned, I suffered of it from the later half of 2020 all the way to the end of 2021, things are slowly getting better since December when I changed orgs (inside the same company).
I'm still far away from how I used to perform, I'm doing therapy and it's been one of the worst issues I've talked about for a while. It creeped into other areas of my life and now affects my day-to-day life and hobbies, the pandemic just made everything much worse.
I actually recently suffered (am still suffering from?) a burning caused by the combination - super high stress combined with absolutely no progress, "busywork" and literally a feeling like a plumber whose job is to "support" the people doing the cool stuff (which I thought I would get to work on when I was hired).
I was given most advice that this article mentions - I took vacations, we had internal rotations to reduce stress, we tried hiring. Ultimately, none of these efforts came to fruition. I think there really is no counter to bad decisions from management. You can try to be as nice as possible at an individual level, but the "lack of progress" burnout will bite you if the pressure doesn't.
This is exactly what I have been going through for the last year or two. I even changed jobs, finding a role that was supposed to be better. At a company that would allow my skills to improve, while having what I assumed would be a better run company.
Unfortunately the new company is so full of corporate BS that I'm finding it even harder to get through each day. I genuinely feel like there are staff who are hired to 'improve productivity' through implementing Agile company wide, are actually doing everything in their power to slow things down. I've never seen this amount of unneeded meetings in my calendar, all in the name of 'planning'.
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 could inject 'boreout' into the public consciousness, but it's more realistic for me to say I was experiencing burnout with different root causes.
I think your comment is very insightful. I agree with your distinction between the two kinds of burnout. I feel like the second one you mention is often the much worse of the two as least with the first case there's the potential to discuss, joke and possibly commiserate over head count and long hours.
I would be interested in hearing how you went about moving forward form your burnout.
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 :)
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".
I really dislike this when it feels forced and artificial.
Also there's a strong risk of doing some little employee-appreciation gesture that backfires and pisses people off. Most of them do, because it feels like the company has cheaped out, or worse, spent a shit-load of money on something that you hate and then expects you to be grateful about it.
Yeah it pisses me off when I've been squeezed for every drop for the whole project by some bozo manager, and then I'm also now forced to be forget and forgive all of that, and pretend to be happy, because of some awkward celebration, just becomes another ass kissing for the manager and salt in the wounds for me.
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.
I think that’s a lovely page and some excellent sentiments in many areas.
However I feel that it’s important to accept reality and not attempt to redefine words.
A startup is literally defined as to “get something moving”, I would say at this point that gitlab is definitely in the realm of “in motion” and has a significant amount of inertia. It is not in the first stages of becoming a company, it is a relatively well-oiled, thought through and publicly traded company.
Obviously terms can be fuzzy, there may be no single event that defines gitlab as no longer being a startup and no particular point in time being the point of state alteration.
But gitlab as it exists today definitely does not meet my own personal and informal definition of startup, and I suspect that is true for many people.
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 universal consensus but in this sense many HNers would see GitLab as a startup despite being worth many Billions.
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.
Disclosure-- A contact I discuss with regularly gives me some insight into what C-suites are actually thinking.
Novy-Marx (http://rnm.simon.rochester.edu/) showed that top-line revenue growth (rather than bottom-line, the "primary measure" cited above) was the strongest predictor of share price appreciation. He may or may not have been right, but he was undoubtedly influential, in that his insight lead to the "management quality" factor in factor modeling. [The Other Side of Value: The Gross Profitability Premium, Journal of Financial Economics 108(1), 2013, 1-28. http://rnm.simon.rochester.edu/research/OSoV.pdf]
So I would say most CEOs are looking at top-line revenue growth as their key measure.
Which makes PG's distinction more of a polemic than a discriminant.
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.
* 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.
While those behaviours are (to varying extents) anti-social, I think some lee-way has to be given for people being human.
e.g. To an extent, someone burning out and thinking "I don't have enough autonomy to fulfill my responsibility" is complainer/victim, even if it's not what you had in mind.
I think that rather than emphasis being on productivity (a growing, motivated, aligned team), I'd think the more important think in psychological safety. -- The anti-social behaviours have a negative effect; but, without safety, there's a heavier social/political cost to counteract them.
Readit News
>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.
You nailed it. The entire article can be summed up by your statement. It's great they're acknowledging it, but putting corporate make-up on it is cringey; it almost comes off like we are the problem and not the other way around.
I don't give a damn about "drinking the kool-aid" and I don't give a damn about your business theatrics nor the political drama that goes with it. 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.
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.
Ditto.
At this point I feel that spending my entire day writing emails (even though I'm on engineering) would not only look better but would meet OKRs, while getting zero actual useful work done.
I hate this fad.
It took me a long time to realize it, but work/life balance in the U.S. is weighted far too heavily in favor of business, at the expense of the individual and their family and community.
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. All stuff that pressures the Average Joe who just wants to make a living. For SE, the majority of these jobs are best described as "gluing APIs together", nowhere near the prestigious "you really gotta want it!" jobs they are sold as. Now add to that while SE does earn above average in all of these countries, it isn't so luxurious as a non-senior that you could pick your nose and live super comfortably no matter which city you live in.
So the pressure got worse and both intrinsic and extrinsic motivators are down. Add onto that a bunch of other societal problems. If anything, it's more surprising people aren't expecting half the populace to burn out at some point in life.
Yes, yes it is.
That is also a symptom of a bigger problem: management doesn't really have to be useful for the company, they merely have to _appear_ to be. Exceptional management is nearly invisible, which is great for companies, bad for careers.
The solution? Managers will make noise and a lot of it. Part of this requires crazy deadlines. If the ship is not creaking it's not being pushed hard enough. Attrition? Bad culture fit, we work hard, we play hard. "I delivered <project> months ahead of schedule" sounds way better than "I delivered it on time" - nevermind that the "delivered" project is a buggy mess noone uses and will require a lot more effort to get to an acceptable state.
We should be praising progress. Not everything should be a 'sprint', it should be a 'march'. What's all the sprinting for?
Most deadlines literally don't matter. Motivated teams that are able to perform their best work do matter.
> when most people just want to put in an honest day's work and progress.
This.
The more I think about it, the more it aligns with my experiences so far.
<< Most deadlines literally don't matter.
What?! Are you insane? What are we going to tell blue ribbon initiative committee?
<< Managers will make noise and a lot of it.
Yup.
I'm of two minds on this statement. On the one hand, "sprint" isn't meant to be taken literally in the scrum metaphor, in that teams aren't supposed to be trying to cram in as much stuff as humanly possible. But at the same time, the idea of each two-week period needing to have concrete goals, and failure to meet those goals being a negative indicator, is a major issue.
For me, the value of having deadlines, or something resembling a deadline, is to make it easier to get started. Once I've actually got the ball rolling, it's less important that the schedule actually resembles the plan, insofar as it doesn't affect other people. But my experience with scrum teams is that progress isn't seen as good enough. You have to execute on the plan, at least as far as scheduling is concerned, and cut corners if you have to.
The issue is this rigid equivalency of plan = commitment, and therefore deviation from that plan = failure. No, a plan does not necessarily mean a commitment. A plan lets you get started without spending so much time in decision paralysis. Once you're moving, the real plan evolves.
I think it's a bit more complicated than that. Pressure can be perceived even without expectations. I think especially junior developers have a hard time knowing which deadlines are actually important, and may tend to experience a much larger responsibility for the entire project than anyone expects of them.
In part this may be down to a bad communication style from managers, a good manager shields the team from worrying about clouds on the horizon; but this isn't always the case.
I've had people I've had to sit down and tell that this overtime they're putting in isn't expected of them, nobody asks this of them, it isn't their responsibility but the team got this, it's not worth burning out at age 24 over some sprint deliverable that's like just a cell in a spreadsheet that nobody really cares about.
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.
I'm also curious if anyone feels similarly about daily standup meetings and the hyperventilating over the Jira board? I feel like I've been in environments where the goal seems to perversely turn into having something to discuss at the next days standup meeting.
I noticed OKRs and OKDs and whatever other flavour of it popping up after the big tech rise. Google and others were seeds of this style of delivery management, somehow this was taught in some MBA and when this generation of MBAs started to take reins of other companies it got spread around as gospel.
I fucking hate it, it's overloaded with rituals that get repeated every quarter: workshops, planning sessions, vision/mission workshops, and so on and so forth. The worse is that never seems that anything has enough time to be done, in my experience roughly a month of each quarter is mentally spent by going through these motions, justifying work that needs to be done, doing discovery for what's upcoming (that needs to be done before planning season ends). Constantly switching contexts about what we're working right now with what work needs to be done in the future, every single fucking quarter.
I'm getting extremely tired of this cycle, it's getting longer and longer to recover from each of these "planning seasons".
P.S.: Not mentioning the variance in processes, each company you join has their own set of rituals and timelines for planning and so it'll take a few cycles of it until you figure out what's important and what I can tune off and give my mind a break.
Deleted Comment
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.
Deleted Comment
Deleted Comment
Dead Comment
(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.
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
Deleted Comment
As far as I know there are no different kinds of burnout. A burnout is always caused by long periods of stress exhausting the body.
The causes of stress can of course be very different. Working below or above your level can cause stress. But also long periods of physical pain can cause stress. Or being overstimulated all the time. And it can be a sum of all kinds of stress. For example when you struggle in a relationship it is much harder to cope with stress at work.
Stress eats your energy.
It's also difficult to prevent a burnout yourself because after a long time you can get used to being stressed. You forget how it is to be relaxed.
Sometimes it is just not clear what caused a burnout. It just adds up.
The best way to prevent a burnout and to recover from it is to accept you are stressed and tired and you need to step back. This is also the most difficult thing to do.
A lack of meaning to the work, or even a lack of work overall, can also cause feelings of burnout. A lack of obvious career progression can cause burnout. Constantly fire fighting can cause burnout.
So if someone says they are burned out, I always ask what is causing it before talking about solutions.
Reward could be anything. The feeling of a job well done (easy to miss if the project is a failure, or if management pivots), it could be the expectation of career advancement, it could be soft recognition by peers... And is dependent on the individual and project. You could even have an outward success and a pay raise but if you wanted your peers to love you and they didn't.... Burnout. You could even have an easy and unpressured job and burn out if it's not providing the rewards you expect.
In any case the disconnect between effort and reward teaches your brain to associate effort with failure and the fact that the common. "take a break" advice failed for you should not be surprising, because I think that doesn't work in general: it doesn't reassociate effort with expected reward.
I feel like a lot of people here are using the topic of burnout to hoist their opinions about American capitalism or whatever, but I honestly don't believe that this is the root cause. Plenty of people work their asses off and are happy to do so because it can be its own reward, or, they know what they want and know how to get it after each brutal push of effort. But not falling victim to burnout takes self-awareness, or good managers (capitalist systems or otherwise - e.g. academia or military) and both of those are in short supply, blaming capitalism is much easier.
If you want meaning from your work, and that meaning was initially provided by personal growth, then when the position no longer feels like growth, there is no reward possible. Similarly, if you thought you were doing something meaningful but then discover your company, or individuals who benefit more from your work than you do, are part of the problem, there is no redeeming it. To continue you have to resort to selective attention or basic ostriching.
If this is true then the primary protective traits against burnout would be 1) strongly established healthy boundaries around what to expect from a job and a healthy home life or 2) myopic focus on problem solving and a lack of interest or self-limiting that prevents curiosity about higher levels of organization. Anecdotally this matches with my experience — most people who endure fall largely into one or both of those categories.
A possible corollary is that with improvements to (that is, restrictions on) capitalism, more categories of people could continue to work without such ready disillusionment from bad or gray actors.
Another second order consequence of this thing is putting in a lot of effort almost certainly sets you up for this effort-reward cycle miss
I did try to fix the root-cause organisational issues, and actually did have a sizable impact with many of my suggestions having been implemented now. However, I ruined myself in the process. It was far more difficult than I expected, because it was a huge old-school hierarchical place. I wasn't paid enough to fix things, and it wasn't in my job description. I ignored that and pushed to fix things anyway - last I've heard it actually made a difference and some of the things I advocated have actually happened now, but it was too late for me.
I just got round to reading the Phoenix Project & Unicorn Project recently, and I'd recommend that. I saw an awful lot of similarities with my old company, and I think it would have helped to have that example of how to improve things. Even then, they were only successful in the book because they had management buy-in.
[1] https://www.inc.com/melody-wilding/3-types-of-burnout-accord...
I'm still far away from how I used to perform, I'm doing therapy and it's been one of the worst issues I've talked about for a while. It creeped into other areas of my life and now affects my day-to-day life and hobbies, the pandemic just made everything much worse.
I was given most advice that this article mentions - I took vacations, we had internal rotations to reduce stress, we tried hiring. Ultimately, none of these efforts came to fruition. I think there really is no counter to bad decisions from management. You can try to be as nice as possible at an individual level, but the "lack of progress" burnout will bite you if the pressure doesn't.
Unfortunately the new company is so full of corporate BS that I'm finding it even harder to get through each day. I genuinely feel like there are staff who are hired to 'improve productivity' through implementing Agile company wide, are actually doing everything in their power to slow things down. I've never seen this amount of unneeded meetings in my calendar, all in the name of 'planning'.
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 could inject 'boreout' into the public consciousness, but it's more realistic for me to say I was experiencing burnout with different root causes.
[1] https://www.inc.com/melody-wilding/3-types-of-burnout-accord...
I would be interested in hearing how you went about moving forward form your burnout.
First, thanks for your honest input. I suppose the fix was to change job to a company that doesn't pretend to do agile?
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 :)
* 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.
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".
Also there's a strong risk of doing some little employee-appreciation gesture that backfires and pisses people off. Most of them do, because it feels like the company has cheaped out, or worse, spent a shit-load of money on something that you hate and then expects you to be grateful about it.
I do think the "appreciation store" model is a really good one. Allowing each to choose their reward.
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.
Isn’t being a $7.5B publicly-traded company the definition of not a startup?
However I feel that it’s important to accept reality and not attempt to redefine words.
A startup is literally defined as to “get something moving”, I would say at this point that gitlab is definitely in the realm of “in motion” and has a significant amount of inertia. It is not in the first stages of becoming a company, it is a relatively well-oiled, thought through and publicly traded company.
Obviously terms can be fuzzy, there may be no single event that defines gitlab as no longer being a startup and no particular point in time being the point of state alteration.
But gitlab as it exists today definitely does not meet my own personal and informal definition of startup, and I suspect that is true for many people.
Look at how many different hands this had to pass through before anything got done. I don't think I've seen any startup survive working like that.
Oh and nothing is done yet, 5 months later. It's still in the "design phase".
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 universal consensus but in this sense many HNers would see GitLab as a startup despite being worth many Billions.
Intel is a startup by this definition.
Novy-Marx (http://rnm.simon.rochester.edu/) showed that top-line revenue growth (rather than bottom-line, the "primary measure" cited above) was the strongest predictor of share price appreciation. He may or may not have been right, but he was undoubtedly influential, in that his insight lead to the "management quality" factor in factor modeling. [The Other Side of Value: The Gross Profitability Premium, Journal of Financial Economics 108(1), 2013, 1-28. http://rnm.simon.rochester.edu/research/OSoV.pdf]
So I would say most CEOs are looking at top-line revenue growth as their key measure.
Which makes PG's distinction more of a polemic than a discriminant.
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.
* 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.
While those behaviours are (to varying extents) anti-social, I think some lee-way has to be given for people being human.
e.g. To an extent, someone burning out and thinking "I don't have enough autonomy to fulfill my responsibility" is complainer/victim, even if it's not what you had in mind.
I think that rather than emphasis being on productivity (a growing, motivated, aligned team), I'd think the more important think in psychological safety. -- The anti-social behaviours have a negative effect; but, without safety, there's a heavier social/political cost to counteract them.