On the other hand, if you want to lead a bunch of engineers, you should know their work very well, otherwise you will have unrealistic ideas about what can get done and how they should do it.

Indeed. Often mutually exclusive.

To really build great software, you need time and space to git your head around the problem. This is obviously not possible if you're spending most of your week in meetings and tracking the work of 7 or 8 team members.

In my experience, you can be a great IC *or* a great tech lead, but you cannot be both at the same time.

Might work for some projects. For really complex projects (which is what I typically work on), strong engineering helps and so a lead-by-example approach tends to work out and it helps to motivate the team.

Also, I can give my team members detailed feedback. I think they take my constructive criticisms more seriously if I also give them praise which is detailed and accurate. You need a hands-on technical person to really understand people's strengths and weaknesses in a concrete way. Being hands-on also makes you more approachable; people will tell you things that they wouldn't tell a non-technical manager.

Being a good leader is partially out of your control. The people under you need to respect you as a leader. Working with them and showing your technical skills can gain their respect

I was thinking the same thing. Sounds more like staff engineer not team lead/mgmt?

It is a good way to burn out high performers haha.

Honestly I’ve seen plenty of folks get promoted to “team lead” because they aren’t as productive with the actual coding. Someone needs to focus on the non-technical project tasks, so the boss picks the least productive team member to move to that role. Calling it a “team lead” makes it more appealing than calling it “worst coder”.

I would argue that the two skills are necessary but not sufficient. If you’re lacking in the core skill, what exactly are you leading? If you’re a great coder and socially inept, good luck leading.