Sorry, but this is horrible, and simply not how leadership works.
It's the team lead's job to answer all of these questions on their own, by interacting and communicating with the team members. The role of the leader is to take up the communication slack of the team members because they are to focus on getting the work done.
Now, that's not to suggest that members shouldn't be communicating at all, but this is presented in such a way that if all team members followed it properly and consistently, they are basically self governing and don't require a leader at all.
The whole point of the leadership position is to account for each of these failures in human nature.
There was an old saying that was used in the Army that I remember fondly:
"If the student hasn't learned, then you have not taught."
In other words - it's always the teacher (or leader's) fault, because it is the job of the leader to adapt to the personalities on the team not the other way around.
It's easy to be a leader of all-stars, all you need to do is stay out of the way (topic for another day). Being a good team lead is about achieving all-star results with normal people.
Well what the article is advocating is "management by exception" - basically a callback system. Where as what you seem to be arguing is a polling system.
It sounds like you want to regularly poll each of the developers, asking; "How's it going? Are you done yet? Any problems?". Where as the articles advocates a callback system, where the developer tells the manager that an event has occurred; "I'm done. I have a question"
In general a callback system is always going to make more effective use of resources than a polling system, both in software design and in management.
All this theory is fine. However the practicality is, some developers are never going to work in a 'callback' manner. You need to prompt and ask them and occasionally pull them out of whatever rabbit hole they have disappeared down. Others are going to absolutely chafe if you keep asking them for progress updates. The difference between an ok manager and a great one lies in being able to understand the human side of things and deal with each person as an individual, rather than just blindly following one theory or another.
And until a certain point, a programmer may not recognize when the code is out of hand. Even still, I sometimes spend an absurd amount of time working on something that seemed trivial, because it spent the whole day looking five minutes out of reach. Or a week looking an hour or two away. Those times don't generate callbacks because they don't seem like big enough problems.
Though if a manager polled me a couple of times that week, the second time I was the same distance into the same task, it would be a major trouble sign.
Sure the team leader can and should facilitate communication, but it shouldn't be too much to ask for someone to mark at ticket 100% complete when they are done. Leaders can block disruption so that focus can happen but it isn't their job to baby sit.
"If the student hasn't learned, then you have not taught."
I think the idea of the blog post is that the team lead will teach these 3 things to all the other developers... As a team lead, I think this list seems like a very effective tool to ensure that communication is not just one-way from lead -> developer, but is also developer -> lead.
No competent team leader is going to be caught by surprise by the schedule slipping on the whole project because of widespread problems, but it's easy to become derailed by a little "detail" which a developer didn't think was worth mentioning, but is actually a critical component which holds everything up.
The team lead can't ask about each and every tiny thing -- so I think this list is a great summary of the communication responsibilities that must fall to the rest of the team.
this is presented in such a way that if all team members followed it properly and consistently, they are basically self governing and don't require a leader at all.
Again, totally disagree. It would be wonderful if a team were self-governing, but it's rarely the reality. And if it is self-governing, you would need far more rules than just these!
However, I may be conflating the roles of coordinator and team lead a bit... in my role, I do both...
>>It's the team lead's job to answer all of these questions >>on their own, by interacting and communicating with the >>team members.
Are you serious? The team lead's expectation from his/her team is that the members are going to be self-organized. That is what the author of the article talks about - his _expectations_. How does communicating well interrupt getting work done in any way?
It may be the teacher's fault when your team members are novices, but not beyond a certain point.
Comments
Sorry, but this is horrible, and simply not how leadership works.
It's the team lead's job to answer all of these questions on their own, by interacting and communicating with the team members. The role of the leader is to take up the communication slack of the team members because they are to focus on getting the work done.
Now, that's not to suggest that members shouldn't be communicating at all, but this is presented in such a way that if all team members followed it properly and consistently, they are basically self governing and don't require a leader at all.
The whole point of the leadership position is to account for each of these failures in human nature.
There was an old saying that was used in the Army that I remember fondly:
"If the student hasn't learned, then you have not taught."
In other words - it's always the teacher (or leader's) fault, because it is the job of the leader to adapt to the personalities on the team not the other way around.
It's easy to be a leader of all-stars, all you need to do is stay out of the way (topic for another day). Being a good team lead is about achieving all-star results with normal people.
Well what the article is advocating is "management by exception" - basically a callback system. Where as what you seem to be arguing is a polling system.
It sounds like you want to regularly poll each of the developers, asking; "How's it going? Are you done yet? Any problems?". Where as the articles advocates a callback system, where the developer tells the manager that an event has occurred; "I'm done. I have a question"
In general a callback system is always going to make more effective use of resources than a polling system, both in software design and in management.
All this theory is fine. However the practicality is, some developers are never going to work in a 'callback' manner. You need to prompt and ask them and occasionally pull them out of whatever rabbit hole they have disappeared down. Others are going to absolutely chafe if you keep asking them for progress updates. The difference between an ok manager and a great one lies in being able to understand the human side of things and deal with each person as an individual, rather than just blindly following one theory or another.
And until a certain point, a programmer may not recognize when the code is out of hand. Even still, I sometimes spend an absurd amount of time working on something that seemed trivial, because it spent the whole day looking five minutes out of reach. Or a week looking an hour or two away. Those times don't generate callbacks because they don't seem like big enough problems.
Though if a manager polled me a couple of times that week, the second time I was the same distance into the same task, it would be a major trouble sign.
Sure the team leader can and should facilitate communication, but it shouldn't be too much to ask for someone to mark at ticket 100% complete when they are done. Leaders can block disruption so that focus can happen but it isn't their job to baby sit.
Um...
"If the student hasn't learned, then you have not taught."
I think the idea of the blog post is that the team lead will teach these 3 things to all the other developers... As a team lead, I think this list seems like a very effective tool to ensure that communication is not just one-way from lead -> developer, but is also developer -> lead.
No competent team leader is going to be caught by surprise by the schedule slipping on the whole project because of widespread problems, but it's easy to become derailed by a little "detail" which a developer didn't think was worth mentioning, but is actually a critical component which holds everything up.
The team lead can't ask about each and every tiny thing -- so I think this list is a great summary of the communication responsibilities that must fall to the rest of the team.
this is presented in such a way that if all team members followed it properly and consistently, they are basically self governing and don't require a leader at all.
Again, totally disagree. It would be wonderful if a team were self-governing, but it's rarely the reality. And if it is self-governing, you would need far more rules than just these!
However, I may be conflating the roles of coordinator and team lead a bit... in my role, I do both...
>>It's the team lead's job to answer all of these questions >>on their own, by interacting and communicating with the >>team members.
Are you serious? The team lead's expectation from his/her team is that the members are going to be self-organized. That is what the author of the article talks about - his _expectations_. How does communicating well interrupt getting work done in any way?
It may be the teacher's fault when your team members are novices, but not beyond a certain point.