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

Become a student of psychology. If you're coming from an IC->management role for the first time, expect your worldview to be broken, and let it happen so you don't have to have a spectacular flame-out to allow it to reset (happened to me, and very common for people coming from the very unambiguous world of "code compiles" to the very loose world of human interaction, where people can't even understand their own motives, let alone anyone else's). Even a modicum of authority changes the way people interact and respond to you, and that's not going to change. Work within it, meet people where they're at, and understand that when it comes to dealing with reports, they're usually right and you're usually wrong.

People are the only thing that matters. Deadlines come and go, companies go bankrupt or get their entire C-suite arrested in midnight raids, competitors come in and break everything and turn the company into a zombie. The thing that endures is the people. If you have good people on your team, consider yourself lucky; being a great boss is one of the best ways to cement a lifelong connection to the best people, and you'll get way more benefit from it than you deserve.

Nothing is straightforward or face value. Understand this and don't try to change it. There's a lot that you'll have to learn for yourself, but keep your priorities and loyalties straight, don't buy into anyone's bullshit too far, and you'll be fine. Good luck.

The truth is that the "best ones" are often obsessed with their work and endure painful tradeoffs in their lives, for example their family lives, because of it.

People who do great work tend to think about their work all the time. No one thinks about their fourth priority all the time.

Get the O'reilly's book "The Manager's Path - A Guide for Tech Leaders Navigating Growth and Change" and READ IT.

1) You will not need to trust others to write better code/systems then you and that you will very likely be unable to code anymore.

2) Establish a good relationship with your team members. Seek for people who you can delegate to and trust. Trust and reliable people are really hard to find. When shit hits the fan - and it absolutely does - you'll need that.

3) You need people who will push and people who will follow. Having just one group and not the others is a recipe for disaster.

4) Establish what things you should care for and what not. The amount of shit is insane and it only gets worse you need to have a threshold on when and on what to react.

5) Do you own research as much as possible on key things.

6) Keep asking "why". It annoys me as f* but also forces you to go deeper with explaining and understanding of the problem. (don't wanna say google "Five whys")

7) Encourage people to go deeper, to learn more to become experts.

9) Have 1-on-1s. Regular. Scheduled. Talk about life/work. Try to find how you can make the place and challenges better. Help them grow in an organisation and professionally.

10) Sketch things out. Write em' down. Otherwise, you'll go insane repeating stuff.

I sincerely wish you good luck.

P.s.: People have more bugs and are sometimes even more broken than software. :D

I agree with this because my 2 favourite places to work (my current on and one 9 years ago) had more of a 'self organising' vibe which encouraged people to put their hands up for things, and although the most senior people have the most codebase knowledge (due to simply having written that code themselves over the years), there are now a lot of areas of code that newer people like myself are the experts in. And also applies to technologies, for example React is known more by a few people needing it for their task.

The point I am getting at is that it is OK and I'd argue optimal if the team leader knows less than the person they are leading and the team leader has to ask them questions about how something works, but their job is to know enough to be able to make decisions and get a feel for things.

Consider that a successful product will be maintained for years. It is highly likely that a people will come and go. Documenting already running code will inherently have less priority (both in the eyes of upper management an developers- the temptation to jump on the next project is huge). So if you don't start documenting first- odds are you never will.