3 ms·

The only way to avoid future burnout is to learn to say 'no' when people ask for things. Someone wants a new feature done in double quick time - say no. Someone

The only way to avoid future burnout is to learn to say 'no' when people ask for things. Someone wants a new feature done in double quick time - say no. Someone wants you to add another 20 points to an iteration because there's a customer call in a few weeks - say no. Someone is demanding you work late to fix a 'critical' issue - say no. Your team is going out to socialize after work when you're really tired - say no. Saying no is a super power. It's also incredibly hard to do in a work situation. You have to work somewhere that accepts you might fail to achieve things sometimes. Most companies really don't accept failure well[1]. [1] Interesting side note - because companies refuse to accept failure most employees only ever take on tasks they're basically guaranteed to succeed at. This massively limits the ambition of most businesses. As Chip Wilson (founder of Lululemon) says, you really should be aiming for about a 50% failure rate with your goals. If you're succeeding more than that you're not aiming high enough.

brndoutthrw 5y ago
I agree with you, but sometimes "no" is not an option, especially now with some organizations, where company success relies heavily on saying "yes" to any customer request and sales people "promised" to deliver feature in 2 months, not knowing that it takes 4-6 months if done correctly, if not correctly, then 4-5 weeks, but tech debt is paid by us not by sales people.
- onion2k 5y ago
  Sure, and those are the organisations where burnout is common. Burnout is stress-induced fatigue and exhaustion due to over commitment at work. Unless you fix the over work you can't avoid the burnout. Saying "no is not an option" just means you'll have to accept the burnout instead.
  - brndoutthrw 5y ago
    I am hoping new job will be different for me, to avoid getting trapped into burnout loop again in new place, I am trying to minimize effects and memories to carry from current work. Do you have any recommendations for it? maybe some articles, specific mediation techniques, books, videos, anything?
mytailorisrich 5y ago
If your an individual contributor, a "dev", you cannot say 'no' to feature requests, fix requests, etc. That's not your job and you do not have the authority. What you can, and should, do is provide feedback on these requests to the people who have the authority in a positive and constructive way. Then, you can leave if you really cannot stand it anymore.
- onion2k 5y ago
  If your an individual contributor, a "dev", you cannot say 'no' to feature requests, fix requests, etc. That's not your job and you do not have the authority. You can say no. You have to be able to back it up with a reason, like "we don't have the resources" or "I've already got 20 points of work to do", but you absolutely can, and should, refuse requests if you're not in a position to do them. Saying yes to everything is how you burnout, and how products end up mired in tech debt and eventually fail. On my team I accept even the most junior devs telling me they aren't able to do something so long as they can give me a good reason. If they say yes and then don't do it the outcome is much worse. Every single person on a project should be working together to for the best possible outcome. That means accepting responsibility for your actions on the project - and that includes giving your PM important information like the fact you won't be able to do something.
  - mytailorisrich 5y ago
    As I said you should provide positive and constructive feedback. You are here to do your job and be helpful, not to pick and choose what you want. You cannot refuse a decision made by management apart from quitting. As an individual dev "we don't have the resources" is not something that you can really say, either. Maybe I'll take an example: You're fully busy and you are told that a new feature was requested and agreed that you need to implement. You don't just say 'no'. You say that you are fully busy on another feature and that you then have several other features on your todolist and ask how you should schedule that new feature. Maybe it's urgent and you'll be told to drop what you're doing and work on it, instead. Maybe it's not and it'll go into your queue. Maybe it'll be allocated to someone else (e.g. it's urgent but what you're working on is also urgent so better that you continue). You do not say 'no', you propose ways to make it happen the best you can considering what you've already been asked to work on. If there is no good way then there is a management/project decision to be made (not by you). That perhaps boils down to pretty much what you're saying, but how you communicate it is very important and so is understand where your authority stops.

brndoutthrw 5y ago

I agree with you, but sometimes "no" is not an option, especially now with some organizations, where company success relies heavily on saying "yes" to any customer request and sales people "promised" to deliver feature in 2 months, not knowing that it takes 4-6 months if done correctly, if not correctly, then 4-5 weeks, but tech debt is paid by us not by sales people.

onion2k 5y ago
Sure, and those are the organisations where burnout is common. Burnout is stress-induced fatigue and exhaustion due to over commitment at work. Unless you fix the over work you can't avoid the burnout. Saying "no is not an option" just means you'll have to accept the burnout instead.
- brndoutthrw 5y ago
  I am hoping new job will be different for me, to avoid getting trapped into burnout loop again in new place, I am trying to minimize effects and memories to carry from current work. Do you have any recommendations for it? maybe some articles, specific mediation techniques, books, videos, anything?

mytailorisrich 5y ago

If your an individual contributor, a "dev", you cannot say 'no' to feature requests, fix requests, etc. That's not your job and you do not have the authority. What you can, and should, do is provide feedback on these requests to the people who have the authority in a positive and constructive way. Then, you can leave if you really cannot stand it anymore.

onion2k 5y ago
If your an individual contributor, a "dev", you cannot say 'no' to feature requests, fix requests, etc. That's not your job and you do not have the authority. You can say no. You have to be able to back it up with a reason, like "we don't have the resources" or "I've already got 20 points of work to do", but you absolutely can, and should, refuse requests if you're not in a position to do them. Saying yes to everything is how you burnout, and how products end up mired in tech debt and eventually fail. On my team I accept even the most junior devs telling me they aren't able to do something so long as they can give me a good reason. If they say yes and then don't do it the outcome is much worse. Every single person on a project should be working together to for the best possible outcome. That means accepting responsibility for your actions on the project - and that includes giving your PM important information like the fact you won't be able to do something.
- mytailorisrich 5y ago
  As I said you should provide positive and constructive feedback. You are here to do your job and be helpful, not to pick and choose what you want. You cannot refuse a decision made by management apart from quitting. As an individual dev "we don't have the resources" is not something that you can really say, either. Maybe I'll take an example: You're fully busy and you are told that a new feature was requested and agreed that you need to implement. You don't just say 'no'. You say that you are fully busy on another feature and that you then have several other features on your todolist and ask how you should schedule that new feature. Maybe it's urgent and you'll be told to drop what you're doing and work on it, instead. Maybe it's not and it'll go into your queue. Maybe it'll be allocated to someone else (e.g. it's urgent but what you're working on is also urgent so better that you continue). You do not say 'no', you propose ways to make it happen the best you can considering what you've already been asked to work on. If there is no good way then there is a management/project decision to be made (not by you). That perhaps boils down to pretty much what you're saying, but how you communicate it is very important and so is understand where your authority stops.