Ask HN: Advice for a new and inexperienced tech lead?

Absolutely this. There's a lot of nice talk in this thread about empowering and enabling your team - but in my experience, that's not what companies are hiring tech leads and managers for. They're hiring you to get stuff shipped!

So understand your own manager's approach to management, and make sure you're aligned with it. Recently I was in a job where my own "servant leadership" style clashed quite badly with my boss, who was much more focussed on management "driving delivery" of projects. It did not end well.

its' like a family where you enjoy when the whole family is doing great You have to think about each and everyone on the team while keeping the healthy competition. Identify the people's interests and feed them type of challenges e.g. someone like debugging for those weird things or someone doing research and coming up with the ideas Lead with the examples Try to connect with them off the works (depending on the country/location) Bring up the difficult discussion as early as possible, don't avoid them at any cost Train more leaders as you're trying to finish your job Take ownership and delegate

The bits I wish I'd known:

It's okay to make mistakes. Really, you're going to make loads of them, and your team is going to make loads of them and you're going to own those mistakes.

It's now going to be more about getting the best out of your team than it is about squeezing out more code. I spent a lot of time beating myself up over how much code I wrote dropping off, there is a nice sweet balance you'll find.

Learn to delegate, and learn to do it early. You'll burn yourself out super quickly otherwise.

I am two years into being an 'inexperienced tech lead', and I think there are some good pieces of advice in the other comments. But I think the most important thing seems to be having some structure to your progress in all of the mentioned categories. When dealing with your team have an objective in mind for not only the conversation or meeting but for the takeaways you want your team to have. Take note of what assumptions changed your mind for certain decisions. Assume you're wrong and need to experiment to be right.

More practically: I write down feedback that is given to me regarding leadership style and write down things that I think about at the 'moment of impact' (assumptions, reasoning, and metrics for success/failure of decision) when decisions are being made. Read over these notes often enough that you are aware of those things when they happen again. Anecdote: Developers often want time to create a quality feature and if they are frequently pressed for time due to business requirements, they are unhappy and the product suffers, often in less than obvious ways. It was only really obvious that this was a problem when we tried other ways of planning and prioritizing because the assumption was that development pressure was a given for a tech company, turns out that some development work can be offloaded by better planning and prioritization based upon better thought out business objectives. These learnings came about because we kept took notes of decisions that were made, and could refer back to them as crucial points of pain/cost/failure.

If you don't have some structure to your approach, you'll find it difficult to call out specific changes that need to happen.

There's a lot more that could be said. Tech leads are often interfaces for other parts of the business so respecting the context of other's roles and aligning incentives is more important than proving your job is being done 'correctly'.

This is more or less my definition of the term "product engineering".

The one caveat is to be sure to also think about your team members as "users" of the code base.