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.

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 :)

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).

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.

Thanks for the write up.

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.

Very helpful for anyone looking to hire such a person too - almost a checklist of things to ask them about from their experience.

The article started well, but degenerated into a laundry list.

A list that contains everything is barely helpful.