I wonder how much empathy plays into it? I’ve trended towards teach lead roles and not that I feel my code is necessarily special, I think it’s clean enough and concise at times - occasionally some ASCII art slips in of course…

But what I have noticed across multiple companies is that I offer feedback for reviews that is thorough when it counts - I may pick apart a huge PR with lots of notes and suggestions, and that’s because the change has the potential to impact large systems. I also explain why, and I ask questions of the engineer to make sure I know why they did a thing because maybe I missed something.

I also talk to managers, product, and design, and do a lot of listening. Often times people are working towards a goal, or working against some barrier to getting their goals met, and being able to listen and understand them lends to a lot of credibility. And when you do a lot of that listening, you inherently gain a good amount of understanding of the systems - both technical and human.

When the time comes for someone to say “we should have a new lead on X”, the people that listen and engage tend to rise to that position naturally.

I think accountability and empathy go hand in hand to some degree - by owning something, you’re also saying “I understand how my work might impact other things, other people, and I want to reassure you that I have your back”.

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.

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.

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

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

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.

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

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 am assuming that the point is, when you start in your team's shoes and then get promoted to team lead, your team knows you are capable and that you have well reasoned opinions. Hopefully.

Because that's how Silicon Valley works?

I took it as good, central contributions are one path to respect and trust.