Comment by MPSimmons | Hacker News Reader

Comment by MPSimmons | Hacker News Reader

The problem that the author identifies is real - when a manager dictates that something needs to be done, a time estimate is given, and the time allotted is dramatically shorter. That happens, as I think we all know.

The _actual_ problem, though, is more insidious. It's that the engineer then frequently accomplishes the task in the shorter time frame, and looks like a miracle worker. This reinforces the manager's intuition that the engineer is padding the time estimates and trains them to continue to behave the same way in the future. What _isn't_ apparent is what was sacrificed in order to accomplish that time schedule.

How much maintenance was deferred? How many other things had their schedules slip? These things are actual tangible sacrifices made to meet a possibly arbitrary deadline.

The other side of the coin is, maybe the deadline isn't arbitrary - maybe the Enterprise will fall into the atmosphere in the 20 minutes Kirk gives Scotty, or maybe there are auditors coming on Friday and a repair needs to be completed before then.

When dealing with other people, I try to give them the benefit of the doubt on intentions, and if I receive unexpected requests, I don't just try to provide a reasonably accurate estimate of my time, but I also ask what the driver is behind the request. Certainly they are aware of pressures that I'm not, and I also voice pressures that I am under that they aren't aware of, so that together we can determine priorities and make the right path. This also makes it much easier to communicate with the people whose projects got de-prioritized, so that everyone can be on the same page.

I agree with your point, but I think the industry suffers from its own incapability to communicate, I had a manager that would ask stuff on tight deadlines, and I would always complain, make sure they understood that it was not how things were to be done, but did it, once, twice, third time I refused and people got the task instead of me, silently. What you say about

>> "The _actual_ problem, though, is more insidious. It's that the engineer then frequently accomplishes the task in the shorter time frame, and looks like a miracle worker. This reinforces the manager's intuition that the engineer is padding the time estimates and trains them to continue to behave the same way in the future. What _isn't_ apparent is what was sacrificed in order to accomplish that time schedule."

The majority of things in life are not apparent, and that's what needs to be communicated correctly, the manager doesn't have a telepathy skill or a crystal ball, developers need to learn to talk

This is exactly the case.

A big problem is that both the following can be true:

a) most task estimates are greater than the time required

b) most project estimates are lower than the time required

even though the project estimates are just the sum of task estimates. Partly this is because there are unexpected tasks, but it's also because errors in estimates are a fat-tailed distribution with a lower bound (a task can't take negative time). So the median error can be negative even though the mean error is positive! But, because tasks happen more often than projects, the availability heuristic means that managers place more weight on a) than b) even though b) is what is actually important for the business.

IMO in that situation it's more appropriate for the engineer to give a list of options, with trade-offs and estimates. If the manager insists on the fast approach, then I would insist they take ownership on that (which can mean managing comms with other teams / stakeholders). If it means cutting corners, then fixing that needs to be added to a backlog with some sort of prioritisation / resource attached to it. If that's all fine, then I think the engineer should accept the fast approach as the prudent one.

Reply on news.ycombinator.com