Here's my advice based on my personal experience with burnout. It's all easier said than done, I'm afraid.
1) People are part of the problem. You solve problems for customers with technical solutions, but your solutions should take into account people in the company. e.g. "how do I solve problem X with a manager that won't listen?" Other people are not a mysterious outside factor, they are a piece of the puzzle that needs to be put together.
2) Ignore your reputation. Do not base your self-worth on the opinion of others. You want to do good work, of course, but often your idea of good work is not what is wanted by the company. They want features, not pretty code. They are often too short-sighted to see the problems they are creating for themselves with this attitude. You must come to accept this.
3) You don't own your work. You must be mercenary. You are paid for your skills but the output is not yours. You will naturally have a sense of ownership over the the work you do. You will want to protect it because your sense of self-worth is linked to the quality of your work. Sever this link.
4) You don't own the company's problems. You must be mercenary. Companies are dysfunctional. They will be short-sighted. They will make mistakes you have seen a thousand times before and the end will be completely predictable. Give your advice, watch it get ignored, get paid, and move on.
5) Find something more important to care about than some stupid tech product. P.S. It's not going to make the world a better place. Quite the opposite if you look at previous evidence.
I'm sure most of us have worked for shit companies that have taken advantage of us. In those cases, I think your points can be helpful.
But I'd also suggest that it's possible to find companies that align with your values, both around work/life balance and around the way the work gets done. That's certainly a skill that I've had to work to develop. And I've had some major misses along the way. But it's probably also the most important skill I've developed.
Owning your company's problems, at least a subset of them, is that fastest (only?) way to move up in a company. If you want to climb the ladder at all, you'll have to own some problems. The key is to do that for a company that recognizes and rewards that ownership. And as soon as they don't, then you become the merc and find a new thing.
> But I'd also suggest that it's possible to find companies that align with your values, both around work/life balance and around the way the work gets done.
How? I keep reading this in similar discussions, but I haven’t found practical advice on how to actually do that. And I can’t trust myself because I keep joining shitty companies on that front one after another.
I'll caveat that this is mostly tailor toward SaaS companies, but it's all I really know:
I think my proxy for work-life balance is days of PTO. I'm typically going to take ~20 a year. That's what I need to recharge and avoid burnout. In a interview with a manager I would ask:
"So, in the job description it says you have Flexible PTO, what does that actually look like here?"
Usually they'll give me some sort of range or average.
A way to cut down on the chances of working for shitty leadership is to ensure you work with high performers. (not foolproof, but helpful) High performers don't like working for shitty leadership. I borrow my proxy for high performance here from the excellent book, Accelerate (Forsgren, Humble, and Kim), and look for the engineering org to implement CI/CD as well as IAC (Infrastructure As Code). I'll ask about these during question time of the technical interview, as well as other things I care about (testing philosophy, etc). I'm sure there are really great organizations that don't do CI/CD or IAC, but I would have to know _for sure_ that they were great, to work for them.
These are obviously super high level proxies for organizational health from the perspective of an engineer. But reading up on organizational health more broadly can help you identify some red flags these proxies don't cover. Check out The Five Dysfunctions of a Team by Patrick Lencioni. It's a fantastic book on organizational health.
Lastly, networking can be very challenging but also very helpful here. It's not something that comes easy to me, but it has helped tremendously in figuring out which companies in my community I do and do not want to work for. This could be less relevant now that almost everyone is cool with remote work. But even my most recent job post-covid, was something I found because of my network. Go to meetups. Go to conferences. Get coffee with people who do similar things. It can really pay off.
1) People are part of the problem. You solve problems for customers with technical solutions, but your solutions should take into account people in the company. e.g. "how do I solve problem X with a manager that won't listen?" Other people are not a mysterious outside factor, they are a piece of the puzzle that needs to be put together.
2) Ignore your reputation. Do not base your self-worth on the opinion of others. You want to do good work, of course, but often your idea of good work is not what is wanted by the company. They want features, not pretty code. They are often too short-sighted to see the problems they are creating for themselves with this attitude. You must come to accept this.
3) You don't own your work. You must be mercenary. You are paid for your skills but the output is not yours. You will naturally have a sense of ownership over the the work you do. You will want to protect it because your sense of self-worth is linked to the quality of your work. Sever this link.
4) You don't own the company's problems. You must be mercenary. Companies are dysfunctional. They will be short-sighted. They will make mistakes you have seen a thousand times before and the end will be completely predictable. Give your advice, watch it get ignored, get paid, and move on.
5) Find something more important to care about than some stupid tech product. P.S. It's not going to make the world a better place. Quite the opposite if you look at previous evidence.