4 ms·

Sometimes, but not always. I've been on both sides of this situation. As an engineer I'm always adamant - yep, no way this could be done any faster and please

by jghn 3y ago

Sometimes, but not always. I've been on both sides of this situation. As an engineer I'm always adamant - yep, no way this could be done any faster and please stop pressuring me to just get the number you want to hear. It'll be done when it's done, and it'll be robust and good. Now please go away and let me cook. But when I've been the manager pushing for smaller estimates, it's been because the business realities were that delivering *something* in a given time frame is critical. And if it requires making a house of cards and cutting corners, well at least we'll have survived long enough to deal with that problem later. And when I've been in that situation I received the usual pushback from engineering - the same pushback I would give in their shoes - that this is a terrible idea, will doom us to fail in the future, and we need to put in the leg work now to avoid future pain. I've gone back to being an engineer but that experience as a manager has helped me quite a bit when dealing with this sort of divide.

marcosdumay 3y ago
If you need a stable software released by Christmas, you go to your developers and say "people, we need to release a stable version of this by Christmas". You don't say "hey, how long do you need to do X, Y, and Z? Oh, no, that's too much time, how can you shorten it?"
- rmwaite 3y ago
  I agree with this. Incidentally, some of my most productive periods were when the team was given a real deadline. Often times either the deadline is made up entirely or there’s a generally understood sense that it can easily be pushed back. I find that if I can trust that the constraint is a real one it really helps us to scope things out of necessity. My theory is a lot of the never ending development cycles is because engineers don’t actually believe the constraints are hard, which leads to scope creep or at least the development getting stretched out.
ghusto 3y ago
It is entirely reasonable for the business to say "we need X in Y weeks" — it still might not be possible, most of the time engineers can make _something_. What's unreasonable is saying "we need X in Y weeks, and it needs to be done properly". It will take a certain amount of time to do anything properly, and that doesn't change with pressure.
- jghn 3y ago
  Yes, exactly. As a manager when I've pushed back on estimates it was because the engineers were pushing for "done properly". Where "done properly" didn't mean more features but building a more solid foundation. And I 100% understood the desire, but at a higher level the long term cost of not having that solid foundation was worth incurring. Requiring both "fast" and "good" is foolish.
verve_rat 3y ago
What you are describing is shit managers. If corners need to be cut for valid business reasons then there shouldn't be any real push back from the devs, because they have the business context laid out for them. Every dev I've ever worked with will say "yup, I understand. I might not like it, but I understand" when given the context of pushes for quicker delivery. But that requires understanding on both side that you are sacrificing quality to hit a date, and that has its own costs. Mostly this all boils down to: talk to people like they are you colleagues, don't order them around, find a solution together.

by jghn 3y ago

marcosdumay 3y ago

If you need a stable software released by Christmas, you go to your developers and say "people, we need to release a stable version of this by Christmas". You don't say "hey, how long do you need to do X, Y, and Z? Oh, no, that's too much time, how can you shorten it?"

rmwaite 3y ago
I agree with this. Incidentally, some of my most productive periods were when the team was given a real deadline. Often times either the deadline is made up entirely or there’s a generally understood sense that it can easily be pushed back. I find that if I can trust that the constraint is a real one it really helps us to scope things out of necessity. My theory is a lot of the never ending development cycles is because engineers don’t actually believe the constraints are hard, which leads to scope creep or at least the development getting stretched out.

ghusto 3y ago

It is entirely reasonable for the business to say "we need X in Y weeks" — it still might not be possible, most of the time engineers can make _something_. What's unreasonable is saying "we need X in Y weeks, and it needs to be done properly". It will take a certain amount of time to do anything properly, and that doesn't change with pressure.

jghn 3y ago
Yes, exactly. As a manager when I've pushed back on estimates it was because the engineers were pushing for "done properly". Where "done properly" didn't mean more features but building a more solid foundation. And I 100% understood the desire, but at a higher level the long term cost of not having that solid foundation was worth incurring. Requiring both "fast" and "good" is foolish.

verve_rat 3y ago

What you are describing is shit managers. If corners need to be cut for valid business reasons then there shouldn't be any real push back from the devs, because they have the business context laid out for them. Every dev I've ever worked with will say "yup, I understand. I might not like it, but I understand" when given the context of pushes for quicker delivery. But that requires understanding on both side that you are sacrificing quality to hit a date, and that has its own costs. Mostly this all boils down to: talk to people like they are you colleagues, don't order them around, find a solution together.