4 ms·

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 t

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.

batmaniam 4y ago
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%20of%20Burnout%20in%20Tech%20-%202022%20Edition.pdf https://f.hubspotusercontent30.net/hubfs/7677235/The%20State...
- jbay808 4y ago
  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.
  - laserlight 4y ago
    > 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.
deathanatos 4y ago
> 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.

batmaniam 4y ago

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%20of%20Burnout%20in%20Tech%20-%202022%20Edition.pdf https://f.hubspotusercontent30.net/hubfs/7677235/The%20State...

jbay808 4y ago
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.
- laserlight 4y ago
  > 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.

deathanatos 4y ago

> 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.