3 ms·

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.

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.
- onion2k 5y ago
  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). This is the exact problem. If developers can't say no then, on occasions where management or product aren't willing to compromise and do insist that a feature is added beyond the team's capacity, then the developers either have to work past healthy hours or they have to resign. That is not a reasonable point of view. Developers should not be in a position where they have to choose between overworking or leaving. Good companies accept and value everyone's input, including the developers, and trust them when they say there's a good reason not to build it. Building good software is a collaboration between everyone on the team. Management and product should not be in a position where they can demand things from developers who have to just accept what they're told. That is very unhealthy and leads directly to people burning out. This is why it's important to be able to say no.
  - mytailorisrich 5y ago
    Accepting and valuing input is one thing but in the end people in management positions make the decisions and people who report to them execute these decisions. These decisions do not always please those who have to execute them but that's how it works. If management makes a decision and you don't like it you have three options: (1) disagree and commit, you don't like it or agree with it but you'll still do it to the best of your ability because that's your job. (2) refuse to do it and most likely be fired. (3) quit. That's life. Good management is to seek input then to make decisions. A dev's job is to provide useful and constructive input (which usually involves trying to find solutions) then to execute the decisions made even if they don't agree with them.
    - brndoutthrw 5y ago
      can you recommend any books, articles or videos to learn from?

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.

onion2k 5y ago
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). This is the exact problem. If developers can't say no then, on occasions where management or product aren't willing to compromise and do insist that a feature is added beyond the team's capacity, then the developers either have to work past healthy hours or they have to resign. That is not a reasonable point of view. Developers should not be in a position where they have to choose between overworking or leaving. Good companies accept and value everyone's input, including the developers, and trust them when they say there's a good reason not to build it. Building good software is a collaboration between everyone on the team. Management and product should not be in a position where they can demand things from developers who have to just accept what they're told. That is very unhealthy and leads directly to people burning out. This is why it's important to be able to say no.
- mytailorisrich 5y ago
  Accepting and valuing input is one thing but in the end people in management positions make the decisions and people who report to them execute these decisions. These decisions do not always please those who have to execute them but that's how it works. If management makes a decision and you don't like it you have three options: (1) disagree and commit, you don't like it or agree with it but you'll still do it to the best of your ability because that's your job. (2) refuse to do it and most likely be fired. (3) quit. That's life. Good management is to seek input then to make decisions. A dev's job is to provide useful and constructive input (which usually involves trying to find solutions) then to execute the decisions made even if they don't agree with them.
  - brndoutthrw 5y ago
    can you recommend any books, articles or videos to learn from?