Ask HN: Advice for a New Technical Lead | Hacker News Reader

Ask HN: Advice for a New Technical Lead

What advice would you offer to a developer who is about to become a technical/team lead? Both in terms of technical and management skills, non-obvious things to consider, etc.

Books and other resources are welcome as well.

View on HN

Learn a bit about project and product management. - Product Podcast is a great podcast. - IF you don't already know, learn about how one would break down a large project into user stories and tasks and setup a project plan. - Read a book on negotiating - "Getting More" is a good book.

Understanding these give you some tools to allow you to see promote your team's interests outside your team.

As one who made this same transition, albeit decades ago, I’ll share the advice my manager gave me: it’s no longer about you. It’s about your team and you have to be able derive a sense of accomplishment and job satisfaction from your team’s performance, otherwise you’ll never be happy in the role. When the team does well, they get the credit. When they screw up, well that’s on you. It was some of the best career advice I ever received. It was not, however, an easy transition. Good luck.

When I became a tech lead, I found

"The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change By Camille Fournier"

very useful. There is a chapter on 'being a tech lead'.

Never say a negative thing to your subordinate, especially not about something they spent a lot of time on. It's always possible to frame a sensible point constructively.

This is the opposite of what my manager does :(

Make responsibilities clear as soon as you enter a project. The closer you get to management the more overlap between responsibilities there are (e.g. you don't want to redo what the PO or the architect are doing).

Also there is a difference between tech and team lead. Team lead is more about mentoring and project management whereas tech lead is more about ownership of the tech afaik.

Often times it is simply best to make a decision. There may be two reasonable ways to approach a problem with different downsides. Most of the time one approach is clearly better than the other. Sometimes it is worth prototyping both to see. However, a small, but significant, portion of the time the best thing to do is pick one at random so that progress can continue.

Reply on news.ycombinator.com