Earlier quoted context omitted.
FWIW, as the manager I don't feel I own the commitment date, the team does. That process has a 'content' aspect to it as well in the form, "by this date, this content, by this later date this additional content". But I understand the angst against managers who "manage up" promising impossible dates and "blaming down" when the dates aren't met. I learned early on as an individual contributor that "getting it in writin…
I think this works, but only in cases where two things are true: - the team is actually responsible for the date—often, there's massive asymmetric pressure to aim for less time - if it's an actual deadline, the team has the autonomy to adjust scope to hit it In my experience, the worst situations happen when estimates are treated like deadlines . An estimate has to have uncertainty . Without some way to manage uncert…
I see the whole "agile" movement as a response to this problem. In an effort to mitigate the "error bars" of an estimate a process that iterates over 2 week sprints allows for estimate corrections during development. It isn't obvious to everyone but this is just upping the sample rate on the estimation signal to get a better handle on the noise and thus the signal to noise ratio.