"No, it's less effort than that"

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.

I swear I hate this estimates thing so hard.

For many reasons:

1) Estimations should be useful so business can adapt. In reality there's no adaptation of any sort, your PM will get the stick from its own boss that stuff needs to be ready by this or that more-or-less vague deadline. Thus, what am I estimating for if you don't care about my estimation anyway?

2) There are no incentives for teams ultimately to estimate anything realistically. What do you get for being accurate? A medal? In fact, all incentives go towards inflating the amount of work through estimates.

3) Ultimately all this dancing of estimates and rituals is nothing else but stuff that management embraces to appear more effectful and impactful than it really is.

Most impressive statement I ever heard said in a meeting between management and engineers about a project's progress was a long-tenured dev saying "it'll be done when it's done", followed by silence, and then they let it be.

To this day I still don't know how this event came to pass.

Yeah if you estimate realistically many companies have a culture that will punish you for not being a team player.

But it’s easy working for such people once you identify them. They are “goes to 11” people. Like that amp in spinal tap you just make your regular output max level be a 9, then you have room to go 1 more when they want you to. Of course that means working slower than you otherwise would. But if they want a dev that “goes to 11” it’s pretty obvious to some of us that there’s only one way that works.

This is very true. And this is exactly my manager and the skip - pushing arbitrary deadlines, not because some customer is waiting for it, but because they want to look good to their own bosses. When the estimate inevitably fails, they all raise their hands and start pipping people for their own poor estimation.

As an engineer, imagine living under this constant stress, missing time with your family and friends, and for what? Just to make your own manager's incompetent estimation look good?

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.

Your are correct in the majority of places where developers work. And this is simply because most developers work under legacy management where they are siloed off from the business - so typical Machiavellian silo on silo violence is employed to get one silo to commit to the desires of another silo.

It's crazy because the customer gets totally hosed by bad software implementations, and if good working software is actually important to the future of the business, a slow march towards bankruptcy happens.

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?"

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.

Yeah, this part is getting lost and there's a lot of apologists here. One of the oldest tricks in the book is to create a vision, make a promise, and then say "I did my job, now engineering just has to do theirs"

I'm reminded of a manager that would add features as I was finalizing a release, sometimes hours before without telling me. He would even add features to releases that already happened. In his mind, he seemed to think that he could just attach the features to a release, and bam. it's done!

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.

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.

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.