| Second step: stop referring to people as "which". "which" is for things, "who" is for people. Replying to param, but don't want to spam another comment: > "b) understand the criticality of the deadlines," Why is the deadline critical? For whom? What is the programmer's stake in this deadline, and do your people feel like they have been treated fairly? To answer the first part, ask yourself seriously: what happens if we don't hit this deadline? Does it truly impact the company and/or team, or does it impact you? I've seen many a time when deadlines are touted as hyper-critical, but have minimal actual business impact. They were hyper-critical because it was critical for the manager to get it done on-time, otherwise he/she looks bad. This is not something I would normally presume about a manager, but you've already demonstrated some misguided overly corporate buzzword-notions in your post. I personally am much more likely to trust my manager's prioritization of tasks (and thus, deadlines) when I feel that he is looking out for the team (or hell, the company) rather than himself. |
I think my question is being taken the wrong way. Let me try asking again: I have work X to get done. I have a team member who I would like to work on this. I ask them to estimate the work, validate the estimates and then track against the same. In the weekly status calls, if they are behind schedule, can not give a justifiable reason for being behind (like personal reasons, unexpected technical complexity, hardware issues); how does the group manage?