[ethnicify]

Please, help us understand how having a 60 item worklist per week is "micro-documentation". I'm sorry, but you haven't really worked with or had training from real-world engineering managers.

For the engineers, and yours, peace of mind and progress -- please spend some time with stellar execution managers that understand software development is a people problem, not a project management problem.

[padobson]

Good engineering managers (preferably someone who knows how to write code) are going to be able to break tasks down effectively. So yes, it always starts with people.

And I agree with you: talented people, be they managers or developers or janitors, will be able to overcome any process or planning shortfalls.

But there's no difference between what I'm describing - a project manager breaking down features into bite-size bits of work - and a developer taking on a single feature and writing down TODOs in code, on post-its, on a white-board, or in the comments of the project management software.

The difference is one of documentation and communication to stakeholders - which is the PRIMARY problem with software estimation. There are ALWAYS unknowns in software. A team leader needs to be able to go to his boss when something is falling behind and say, "We didn't anticipate this. This is the reason it's taking longer".

This is FAR superior to going to the developer and asking them why feature X is taking so long and having them compile a report from Notepad/post-its/white board scribbles. With my process, you can just pull up the project management software and find the tasks that went way over, and the developer stays almost completely insulated from management.

I'm sorry, but you haven't really worked with or had training from real-world engineering managers.

This is the worst kind of condescending ignorance, it betrays an inability for civility that I wouldn't tolerate in a colleague.

[ethnicify]

Apologies, your perceived "view" of engineers had me fuming. I din't mean to attack you - but I understand where you're coming from.

It is not your fault if your leadership demands detailed answers as to why X is off by Y days. All you're doing is cascading that mistrust/poor management skills to your engineers. I understand what you're doing is the most reliable way to do it, but there is a better way. This is why I mentioned its a people problem.

The better way is to not break down things into hourly tasks but weekly sprints as most teams do. Let your engineers break that down into how much ever granularity they're comfortable with. If something goes off track, build communication trust that helps them keep everyone in the loop and work towards a common goal.

As a product person, I've had the fortune of working in two of the big 4 with some of the best engineers there is - so maybe that contributes to my worldview and it might be terribly biased.

Thanks for explaining :)