3 ms·

Quick summary?

CraigJPerry 5y ago
Manipulation, passive aggression, telling you that your jobs on the line, … the chapter plays through a few realistic dialogues in the context of a developer providing an estimate the manager doesn’t like and the ways the manager tries to persuade the developer that they’ve guesstimated wrong. He rounds out the short chapter with an appeal to professionalism.
- throw394024 5y ago
  This is something I've never learned how to defend against. I've always tried to stay professional... but I'm a chronic under-estimator, and also find it difficult to say no, which is a recipe for disaster. Unfortunately people usually don't work like the team they purport to be (managers shielding their ICs, POs tracking down AC)-- they just see your willingness to work and exploit it for as much as you'll do, rather than trying to make a system that hums forward quickly. They demand speed, but don't want to improve process to get that, they just want you to work more and harder. Is there a way to build trust or consistently set boundaries or protect your time? Some of my co-workers say "I'm almost out of hours for this week", which I think is one of the only things they understand, but then you really have to close the chat client and not help other devs, lest you miss your "estimates".
  - CraigJPerry 5y ago
    We’re all chronic under-estimators by default so I wouldn’t beat yourself up over that one! The old planning fallacy is very well studied and documented. Humans are terrible at estimating by default unfortunately :-( but it’s not that hard to be conscientious about getting more accurate. For me, the secret is to just delegate to a tool that gives me estimates based on my past performance. The cost to me is nothing more than logging an estimate up front and recording what it ended up after the fact. Doing that for a few weeks rapidly steers you to breaking your work into small chunks because it’s too hard to make the recording work otherwise. Turns out small chunks of standalone useful outcomes are optimal anyway for 1001 other reasons. As for saying no - one way could be to find a role model somewhere close around you, it should be easier to copy what they do if they’re in the same org structure and facing the same struggles. You can’t just assume to flick a switch and behave like them, everyone around you has an expectation of how you behave right now, so you have to be fairly active about signalling to people they should update their perceptions.

Quick summary?

Manipulation, passive aggression, telling you that your jobs on the line, … the chapter plays through a few realistic dialogues in the context of a developer providing an estimate the manager doesn’t like and the ways the manager tries to persuade the developer that they’ve guesstimated wrong. He rounds out the short chapter with an appeal to professionalism.

throw394024 5y ago
This is something I've never learned how to defend against. I've always tried to stay professional... but I'm a chronic under-estimator, and also find it difficult to say no, which is a recipe for disaster. Unfortunately people usually don't work like the team they purport to be (managers shielding their ICs, POs tracking down AC)-- they just see your willingness to work and exploit it for as much as you'll do, rather than trying to make a system that hums forward quickly. They demand speed, but don't want to improve process to get that, they just want you to work more and harder. Is there a way to build trust or consistently set boundaries or protect your time? Some of my co-workers say "I'm almost out of hours for this week", which I think is one of the only things they understand, but then you really have to close the chat client and not help other devs, lest you miss your "estimates".
- CraigJPerry 5y ago
  We’re all chronic under-estimators by default so I wouldn’t beat yourself up over that one! The old planning fallacy is very well studied and documented. Humans are terrible at estimating by default unfortunately :-( but it’s not that hard to be conscientious about getting more accurate. For me, the secret is to just delegate to a tool that gives me estimates based on my past performance. The cost to me is nothing more than logging an estimate up front and recording what it ended up after the fact. Doing that for a few weeks rapidly steers you to breaking your work into small chunks because it’s too hard to make the recording work otherwise. Turns out small chunks of standalone useful outcomes are optimal anyway for 1001 other reasons. As for saying no - one way could be to find a role model somewhere close around you, it should be easier to copy what they do if they’re in the same org structure and facing the same struggles. You can’t just assume to flick a switch and behave like them, everyone around you has an expectation of how you behave right now, so you have to be fairly active about signalling to people they should update their perceptions.