Even though the book is old, the concepts in it haven't changed: Developers need to work with minimal interruption, management needs to serve development.
Here's the thing: "Team lead" and "manager" are very, very different roles. "Team lead" is very hands on, because you need to be able to jump into the code base to help team members understand the bits; and you need to be able to speak to management with detailed technical knowledge.
(As you can probably infer, I've been a team lead and really, really enjoyed it.)
In my case, "team lead" was about a 50/50 split between hands-on coding and leadership. At times, it was basically me doing the hardest parts of development with assistants who I would directly assign tasks. Other times, I worked with other developers and directly mentored them in tasks because I had the most experience in the code they were working with. Other times, I was merely a peer making sure that process was followed.
At one point I had to "manage up" and explain what the boundaries are between QA and development. This was mostly to avoid situations where other developers were spending a week scratching their heads trying to reproduce a bug. It turned my reputation from being "difficult" to being a leader overnight; because (surprise surprise) sometimes you need to tell QA that their responsibility is to clearly communicate bugs.
As far as management, part of it is making sure there is just enough process that people can hand off work from one person to the next. The processes need to be flexible so they don't get in the way, and they don't exist for the sake of existing. It comes down to things like making sure bugs are documented so that someone doesn't spend a week trying to figure out how to reproduce it; and that the actual steps to reproduce aren't buried in a chain of 100 comments in a ticket. (But that's just part.)
The other part of management, and any leadership role, is realizing that you're not a boss. You merely have a more powerful role in a team, and you need to use your power wisely. Everyone should feel like they are doing what they believe is right.
Comments
Read: The Mythical Man Month: https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Even though the book is old, the concepts in it haven't changed: Developers need to work with minimal interruption, management needs to serve development.
Here's the thing: "Team lead" and "manager" are very, very different roles. "Team lead" is very hands on, because you need to be able to jump into the code base to help team members understand the bits; and you need to be able to speak to management with detailed technical knowledge.
(As you can probably infer, I've been a team lead and really, really enjoyed it.)
In my case, "team lead" was about a 50/50 split between hands-on coding and leadership. At times, it was basically me doing the hardest parts of development with assistants who I would directly assign tasks. Other times, I worked with other developers and directly mentored them in tasks because I had the most experience in the code they were working with. Other times, I was merely a peer making sure that process was followed.
At one point I had to "manage up" and explain what the boundaries are between QA and development. This was mostly to avoid situations where other developers were spending a week scratching their heads trying to reproduce a bug. It turned my reputation from being "difficult" to being a leader overnight; because (surprise surprise) sometimes you need to tell QA that their responsibility is to clearly communicate bugs.
As far as management, part of it is making sure there is just enough process that people can hand off work from one person to the next. The processes need to be flexible so they don't get in the way, and they don't exist for the sake of existing. It comes down to things like making sure bugs are documented so that someone doesn't spend a week trying to figure out how to reproduce it; and that the actual steps to reproduce aren't buried in a chain of 100 comments in a ticket. (But that's just part.)
The other part of management, and any leadership role, is realizing that you're not a boss. You merely have a more powerful role in a team, and you need to use your power wisely. Everyone should feel like they are doing what they believe is right.