←back to thread

388 points replyifuagree | 1 comments | | HN request time: 0.206s | source
Show context
_rm ◴[] No.37966921[source]
It's more Machiavellian than that. What the middleman wants is a heads I win, tails you lose deal.

He wants to present a low number, to encourage whoever he's dealing with on his end to do what he wants, gaining the benefit from that.

So he'll use every technique under the sun to encourage devs to give him a number he likes more, while never making it look like an order or coercion (which would make it his number - spoiling the whole play).

But when it inevitably takes much longer, he can point at the numbers the devs provided and say he was just communicating what they told him, so he's not responsible.

The only language these types understand is for requests for estimates to be "reviewed" to result in them always going up, to send a message.

replies(7): >>37967009 #>>37967182 #>>37967375 #>>37968123 #>>37968508 #>>37968585 #>>37969715 #
jghn ◴[] No.37968508[source]
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.

replies(3): >>37969032 #>>37970076 #>>37970300 #
marcosdumay ◴[] No.37969032[source]
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?"

replies(1): >>37969706 #
1. rmwaite ◴[] No.37969706[source]
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.