Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: