Managing a team as a tech lead (that is, I also develop a lot).
I primarily use two techniques; simple project management and communication.
Our developers are not forced to work on the project nor are they assigned by anyone else; they are in the team because they want to work on it (and they can leave at any time). The project management is simple; we have a backlog and engineers are (mainly) free to choose what to work on. We have priority indicators and developers tend to work on things they are already familiar with, but in general one can choose what sounds interesting.
How do we (we are two tech leads) determine if engineers are doing a good job? On the code level, we are doing reviews (everyone can review everyone else's code) and give feedback. We are talking a lot with each other, asking about progress, blockers and new ideas. We also talk about technology in general. We encourage our engineers to look at other things and try new ideas.
And the whole project management is transparent; we as tech leads do most of the communication with the business so that developers can focus on their stuff but we report everything in great detail to them.
We do not use metrics like bug counts. Everyone writes code with bugs. What I recognize is whether engineers can take responsibility for their stuff or not. We "teach" them that mistakes are nothing bad; they are encouraged to say "Hey, that's my fault, I will fix it".
I think we, couldn't use this approach with 20 or 30 developers, but in a small team it as really working for us. And as I see it, our developers have a great time and work and a developer-friendly environment.
I like this. So if the question was "how do you tell which sled dogs are really pulling", your answer would be: you can't, if you're standing on the sled. But if you're one of the dogs, it's a lot easier to tell.
I primarily use two techniques; simple project management and communication.
Our developers are not forced to work on the project nor are they assigned by anyone else; they are in the team because they want to work on it (and they can leave at any time). The project management is simple; we have a backlog and engineers are (mainly) free to choose what to work on. We have priority indicators and developers tend to work on things they are already familiar with, but in general one can choose what sounds interesting.
How do we (we are two tech leads) determine if engineers are doing a good job? On the code level, we are doing reviews (everyone can review everyone else's code) and give feedback. We are talking a lot with each other, asking about progress, blockers and new ideas. We also talk about technology in general. We encourage our engineers to look at other things and try new ideas.
And the whole project management is transparent; we as tech leads do most of the communication with the business so that developers can focus on their stuff but we report everything in great detail to them.
We do not use metrics like bug counts. Everyone writes code with bugs. What I recognize is whether engineers can take responsibility for their stuff or not. We "teach" them that mistakes are nothing bad; they are encouraged to say "Hey, that's my fault, I will fix it".
I think we, couldn't use this approach with 20 or 30 developers, but in a small team it as really working for us. And as I see it, our developers have a great time and work and a developer-friendly environment.