I'd like to differ slightly: the job of a good tech lead is to be an effective first among equals.
If you're working on a talented team, there should be no presupposition that the tech lead is necessarily the best developer on it. But you should be good enough to break ties and set direction. I've worked on a lot of teams with talented developers who aren't especially interested in leadership, or former leads who've decided they want to go back and hack some more. You cannot, and should not, boss these people around. But you can block management up, and unblock team down, by keeping management out of everyone's hair, and keep the developers from tearing each other apart over complicated technical questions or obscure business ones.
If you're working on a team that embraces pairing, that can ease a lot of the pressure on the lead to do reviews as long as the pairs are well-chosen. Trust but verify.
My own take on it is different again - as far as I see it the job of technical lead on a project is take ensure that the right technical decisions get made and to ultimately take responsibility for those decisions. Yes, I could directly override people and tell them to do things - but if I ever did that then IMHO I would have failed.
A lot of my job is asking questions, making suggestions and proving (when necessary) that something can actually be done. [I love it when someone utters a phrase starting "There is no way to...."]
The point about prioritizing clearing road-blocks for your team cannot be underestimated, but, in my experience, with a serious caveat:
- Unless your SURE you have the time, do not put the technical task onto yourself, try to redirect.
I've made that blunder over and over again: saying "heh, I'll hack this little bit up tomorrow", and in the middle of planning, helping other people and so forth you postpone, losing the blocked developers attention and focus.
Other than that, great write-up on my job description :)
I can't upvote you more than once, so I'll add an "amen" and a personal experience.
A while back a company where I'd been doing contract web dev work had a dual account/project management role come open and offered it to me. I'd done some client-facing work for them before and freelancing on my own, so I thought "How hard could it be?"
Two things I didn't know when I said yes:
* how much work there was for the small team in place -- and because I wasn't replaced as a technical resource, the team had just gotten smaller
* how different development and management work are in terms of headspace. It's very hard to do both simultaneously, because one job requires a lot of immersive concentration, and the other requires near continuous back-and-forth to discuss, track, and push a lot little pieces of information where they need to go.
So... I'd end up having to find non-office hours to do development work, but still had to be "on" and available during normal office hours.
I managed to keep it up for about six months. Kindof. Wouldn't recommend it, though.
This list covers a lot of good ground, one of the smaller but i think important points is this: "simplify". It's part of your job as a tech lead to show your team a simpler route. Simple code reduces complexity, which makes maintenance easier, and can get you to your goal faster. A lot of new to intermediate guys will over engineer a small piece (and i mean that literally, for some reason i've never had the experience of women over engineering code).
I think I've seen more aimlessness than overengineering, but otherwise, yes. Simple sometimes takes a second look, and a willingness to edit during that look.
Great article with many excellent points, especially those about unblocking/blocking - essentially the two main activities you'll participate in to keep a project moving forward. Everything else exists just to serve these two goals, in my opinion.
I'd also add that a great tool that a tech lead can direct is post-mortems (corrections of errors, whatever your company calls them). Effectively leading these discussions improves a company culture, educates individuals both involved and those not involved in sometimes obscure errors, and elevates the team's overall experience level.
Good differentiation between leadership and management. Reminds me of some very good HBR articles on that difference, and the need for putting leadership before management in any organization.
Fantastic article. Reading it felt like I was reading a guide on how to become a better coder.
Sidenote: I'm sure to want to reread this in the future. What terrifies me about Medium is that if I'm flipping through my notes, say 5 or 10 years from now, will this link still work?
I haven't read all the article, but it looks very close to the daily-work I have had for 3 years. I agree with almost every aspect, and also I will take good tips from here.
s/code/{work activity}/g and s/technical/{business area}/g
The methods here apply to many aspects of leadership. Thinking about going from technical to general management you can use the same methods, think of them as a template class. My one recommendation is to not underestimate the complexity of other areas of business, use experts just as you do in technology.
If you're working on a talented team, there should be no presupposition that the tech lead is necessarily the best developer on it. But you should be good enough to break ties and set direction. I've worked on a lot of teams with talented developers who aren't especially interested in leadership, or former leads who've decided they want to go back and hack some more. You cannot, and should not, boss these people around. But you can block management up, and unblock team down, by keeping management out of everyone's hair, and keep the developers from tearing each other apart over complicated technical questions or obscure business ones.
If you're working on a team that embraces pairing, that can ease a lot of the pressure on the lead to do reviews as long as the pairs are well-chosen. Trust but verify.