4 ms·

Don't 'push back'. That is the wrong terminology, and it's inherently confrontational. Explain to your managers the range of outcomes and give them the power t

Don't 'push back'. That is the wrong terminology, and it's inherently confrontational. Explain to your managers the range of outcomes and give them the power to make the decision with the best information you can provide them. i.e. 'if we skip this bit, then quality will likely suffer, with these kinds of expected outcomes'. Don't be dramatic or emotional, just try to give the best information you can. Also have sympathy for them - money does not grow on trees - and basically balancing quality vs. time-to-market is a constant and difficult challenge. This way - if they decided to 'rush' it - they know what the likely outcomes will be and the inherent outcomes. If they are making the decision then the responsibility falls on them to the extent that you have provided them with thoughtful and realistic assessment.

michaelbuckbee 10y ago
I think you're laying out what is absolutely the best approach. If you're an employee it's sometimes hard to separate the company's interests from your own, so I sometimes do a mental exercise I call "playing consultant" - where it's purely my job to "consult". I try to honestly describe the options, give my best recommendation and then whatever they choose is on them.
watwut 10y ago
Pretty much this. Sometimes pushing back is needed, but way more often "negotiation" is needed. It is unreasonable to expect managers to magically see into the development details, you have to explain, made plans transparent etc etc. When you do that you often (not always) find that requirements are negotiable and not equally important, e.g. it is possible to meet the deadline without sacrificing code quality. Oftentimes the compromise is possible - you wont get two week straight of refactoring, but they are ok with using 20% of development time for cleanups. I have seen developers "push back for the right thing" in a way that basically amounted to angry emotional outburst over things manager did not understood. The dude thought he is pushing for the right thing, but everyone else thought he does not listen to their needs, refuses to follow the company vision of the product replacing it by his own. (They wanted simplest possible functionality and fast, he was constantly adding own requirements to "make it better". When the same person pushes for yet another refactoring, management does not trust him.) The other thing to understand is that some experienced lead remembers teams that were given time, no deadlines and all the good stuff and then produced mess anyway, procrastinated and took long time to do it. I have seen that happen and I have also seen that ended in long wars over petty differences in style and opinions. Sometimes the mess is result of people doing something knew and thus bad decisions along the way. Code review alone wont solve that, because the reviewer may be the one forcing mistake on others. You need to communicate in the way that will ensure the manager that he or she is not in the above situation.
- edblarney 10y ago
  There should be no need for 'wars' or even 'negotiation'. It's the managers decision - not the developers, really. The devs can lay out what can be done, and describe what the results will be if various paths are chosen. 'Skip the tests' - you get quality issues, but better schedule. 'Write perfect code' - you get quality, but it could take to long. The old saying: 'fast' 'quality' or 'cheap' -> pick 2. If your team is having problems because of bike-shedding over details, or messed up code - this is altogether another issue and needs to be addressed differently.

michaelbuckbee 10y ago

I think you're laying out what is absolutely the best approach. If you're an employee it's sometimes hard to separate the company's interests from your own, so I sometimes do a mental exercise I call "playing consultant" - where it's purely my job to "consult". I try to honestly describe the options, give my best recommendation and then whatever they choose is on them.

watwut 10y ago

Pretty much this. Sometimes pushing back is needed, but way more often "negotiation" is needed. It is unreasonable to expect managers to magically see into the development details, you have to explain, made plans transparent etc etc. When you do that you often (not always) find that requirements are negotiable and not equally important, e.g. it is possible to meet the deadline without sacrificing code quality. Oftentimes the compromise is possible - you wont get two week straight of refactoring, but they are ok with using 20% of development time for cleanups. I have seen developers "push back for the right thing" in a way that basically amounted to angry emotional outburst over things manager did not understood. The dude thought he is pushing for the right thing, but everyone else thought he does not listen to their needs, refuses to follow the company vision of the product replacing it by his own. (They wanted simplest possible functionality and fast, he was constantly adding own requirements to "make it better". When the same person pushes for yet another refactoring, management does not trust him.) The other thing to understand is that some experienced lead remembers teams that were given time, no deadlines and all the good stuff and then produced mess anyway, procrastinated and took long time to do it. I have seen that happen and I have also seen that ended in long wars over petty differences in style and opinions. Sometimes the mess is result of people doing something knew and thus bad decisions along the way. Code review alone wont solve that, because the reviewer may be the one forcing mistake on others. You need to communicate in the way that will ensure the manager that he or she is not in the above situation.

edblarney 10y ago
There should be no need for 'wars' or even 'negotiation'. It's the managers decision - not the developers, really. The devs can lay out what can be done, and describe what the results will be if various paths are chosen. 'Skip the tests' - you get quality issues, but better schedule. 'Write perfect code' - you get quality, but it could take to long. The old saying: 'fast' 'quality' or 'cheap' -> pick 2. If your team is having problems because of bike-shedding over details, or messed up code - this is altogether another issue and needs to be addressed differently.