I've worked under you (at least, under someone who ran the team like this blog post suggests), and let me tell you, it sucked the life out of the entire team. The deadlines are the team lead's problem: if you aren't aware of where some project is at until someone tells you on the day of the deadline that it will be late, it's the lead who screwed up. How could you be so out of touch not to know these things on a daily basis?
Furthermore, if you tell these things to someone who does go out of their way to communicate clearly, they are just going to resent it as patronizing and start playing games with you. Not healthy for a team or any individual.
> if you aren't aware of where some project is at until someone tells you on the day of the deadline that it will be late, it's the lead who screwed up.
That sounds nice, except that how is he going to know? He'll have to come by every day and ask "How's it going?". Which I've experienced, and is annoying. I prefer the asynchronous model.
Agreed, constant requests for status updates are annoying and unproductive. The lead shouldn't have to poll for data all the time but shouldn't expect everything to be pushed his way, either. I don't think it's that hard to have a good sense of where things are at from commit logs, building and running the software, bug reports, and casual conversation with team members. If, however, a team member is working on something high profile, risky, or is trying his best to crawl into a cave and avoid all human interaction, they are probably going to need special attention.
I worked under such conditions and liked it. The responsibility is on me to finish my task, report slippage, or clarify the requirement. No one pesters me for daily status. Knowing that trust was placed in me to do the right thing was wonderful.
Furthermore, if you tell these things to someone who does go out of their way to communicate clearly, they are just going to resent it as patronizing and start playing games with you. Not healthy for a team or any individual.