Hacker News Reader

Comment by that_guy_iain | Hacker News Reader

> To me this is insanely disrespectful of the team, and it seems as though it's a boundary violation on some level.

To be fair, people asking you to justify your estimates aren't disrespectful. Realistically, you should be able to provide justification otherwise, your estimation is most likely flawed. And people wanting to have a better understanding of what is going on isn't necessarily a bad thing. Just like you would ask your joiner why it's going to cost X and take Y days, you want to have a good understanding of what is happening and to be informed.

View on HN

> people asking you to justify your estimates aren't disrespectful

In my experience, people are only _pretending_ to ask you to justify estimates. In reality, they are just angling for a discount and/or rush job. It's just a technique for increasing anxiety.

Sometimes they legitimately don't know. It's a good opportunity to help them understand how much work goes into what you do.

I recommend not default-reacting to "why does it take so long? Isn't it just A, B, and C?" as an expression of pushback, but rather just as an expression of honest confusion.

But OP is saying they consistently do this. At that point, it's a pattern, and it's intentional.

And I do agree with OP: every company does this. They want to squeeze every bit of work out of you, and this comes in other forms, not just through 'agile estimates'. Communications across teams that emphasize 'work-hard play-hard' also fall under this, and the 'play-hard' never actually comes. It's just new time-crunched work that gets dumped onto you. Or 'move-fast teams', or 'OKRs', etc.

The entire corporate infrastructure and communications is designed around pressuring workers to work more and more. Sure, there might be some great managers that can push back, but how many of them have you encountered across all the jobs you've been at? Most of my experiences have been what OP has said, most teams are terrible.

It's not a coincidence that the Tech Burnout Index is almost 43% across all of tech. Which means any job you jump to will have a good chance to burn you out some way or another. Which means all the crap that developers experience that burns them out is nearly ubiquitous, including being constantly grilled on estimates.

Burnout Index: https://f.hubspotusercontent30.net/hubfs/7677235/The%20State...

Even if it's consistent behaviour, I'd consistently answer the same way, treating it as honest ignorance. Tasks always look simpler from the outside.

If that conversation is happening with senior management, it can also identify some consistent mismatch between their perception and reality. (Didn't your team get 5 new hires last year? Yes but two are on leave and we also took over responsibility for customer-facing documentation from marketing). Or reveal new priorities when consistent themes come up -- maybe the testing process is being slowed down by a growing matrix of product configurations, and management had no idea how much work that creates.

When the language shifts to something like "regardless of your estimate, we need it done by the end of Q3, so make it happen", then I treat it as pushback.

> Even if it's consistent behaviour, I'd consistently answer the same way, treating it as honest ignorance.

This has been how I handled issues, yet I'm getting more convinced that it is not productive.

People don't learn through only repeated exposure. In the second time something happens, they should be reminded of the first time. And in the third time, they should be outright denied any explanation with a reminder of the first two incidents. Otherwise, they'll keep doing the same thing, probably because it's very low-cost to them, and I'll keep spending my precious resources.

> Sometimes they legitimately don't know. It's a good opportunity to help them understand how much work goes into what you do.

In my experience, they definitely don't know. But no amount of explanation is going to do it for them; any explanation is going to be met with stuff like "well, there must be a simpler way", which is a hell of a statement when it comes from someone who has no idea what they're talking about.

And oftentimes, at the point where you're making the estimate, you don't know how long "A, B, and C" are going to take. You might know how long they will take if the system underpinning "A, B, and C" do their jobs, but they inevitably won't do their jobs, and the extra time is usually working around the failings in systems that you have no choice but to use.

That's a toxic attitude.

The software is being written for the customer and/or management, and they're paying for it. They have a legitimate right to know why the estimate is what it is, and to understand what work is going to be done. If they want to exclude parts of it because they don't see the value, then that's up to them because they get what they pay for.

If you can't explain why it's a bad idea to cut certain parts out, or why certain things take the time that they do, then it's a failure on your part as the engineer, and not theirs.

There's a difference between asking an expert for their opinion and commensurate respect for the effort it takes to provide it, and demeaning an expert because you dont like their answer. I sense that OP was indicating that they felt undermined and attacked for their honest take. Being attacked for your best effort is also toxic

But sometimes I don't know why it's a bad idea ahead of time! That doesn't mean I'm wrong -- often time reveals what it was I was subconsciously worried about.

That's what expertise is sometimes like: an accurate gut feeling, impossible to articulate clearly.

In that case one must be assertive. Speaking this way does not come naturally especially to engineers.

You don't have to articulate it clearly, you don't have to know why you are making the estimate you are making. It's ok for management to push, in fact it is their job.

I suggest this book. https://www.amazon.com/dp/B004IK8Q22

I agree, sometimes it is just a gut feeling, but a lot of times expertise means knowing where the gut feeling comes from and being able to explain it.

If nothing else, management will be more trusting in those situations if you give good and accurate estimates the rest of the time and are able to justify them.

Management, yes. Customers, no. Customers should have no expectation that they can reach into another company and manage teams and individuals like they're employees. Management should step in and make the line clear. Not just because it's counter-productive, but because it's exactly the sort of thing that upsets talented senior staff who rightly believe they deserve more respect than to be told how to do their job by someone that knows nothing about them.

It’s the telling the team how to do their job I find disrespectful. If all they were asking for was more information on the estimates, it’d be a different story.

The presumption in their attitude and approach is that our team doesn’t know what they’re doing and they could do it better, even though they haven’t put in the effort to do the scoping.

To be honest, I think that is in your head. Why? Because I've been on both sides of these conversations, you need something done the other companies engineer says it's going to be X and you want to know why since to you it seems rather simple but you don't know all the things that happen in the other system so what on the face of it can be simple. I've also got to explain to other people why task X is delayed by the third party and why what seems like a simple task is now taking a lot longer.

I think it's more than you're being questioned and you don't like that and feel like your word should be enough.

Reply on news.ycombinator.com