4) Be humble. Redirect upstream praise for your team's work onto your team directly (away from yourself). Accept criticism for your team's work directly onto yourself.
5) Expect to do less actual programming, but still keep ownership of one or two components (UI, DB, etc) for up to 1/3 of your time. This helps to maintain an ear-to-the-ground on ongoing features/bugs and to communicate intelligently with the technical team.
1-5 are great and what I do. The hardest one for me is 2. I have so many things to get done, but always remember keeping your team on track is your number 1 priority.
It's hard for me as well, but as I've lead more teams I've learned how to delegate more. It's okay to delegate hard tasks to more advanced members of your team, if it leaves you open for more questions and the ability to support others. As far as the client is concerned, I'm the representative for all of the backend work that's been done, so according to them it is I who take ownership for the whole thing. Therefore, the best thing for me to do is ensure that my team who is doing the actual coding work is as supported as they can possibly be, so they can get the most work done in the shortest time frame.
I have to remind myself that no matter how productive I am, I can't be more productive as a whole team of smart engineers. One of my main jobs as a tech lead is an enabler. If I can remove blockers and try to cultivate experts then things get done.
I do about 30% helping and answering questions. 30% meetings and planning. 30% code reviews. 10% coding.
Even if you don't do much actual programming you need to be the one that monitors and accepts all pull requests.
That also means taking responsibility for any of the subsequent angry users because you merged that code and you could have stopped it.
Keeping an eye on pull requests also means gently guiding the junior devs to amend their code when they head down the wrong path (e.g. by pairing with them) rather than just rejecting it outright or (worse), writing a snarky comment.
> you need to be the one that monitors and accepts all pull requests
I disagree at least in part. On my team all of the engineers have the ability (and responsibility) to merge PRs. It empowers them and gives them a feeling of ownership. I let the experts in the affected area decide when code goes in/gets deployed as they're able to manage that better than I ever could.
That being said, when something breaks, it's still the tech lead's problem, even if he/she didn't hit the merge button.
5th is VERY must, after a while the team feels you are just another non-coding hairy pointed manager. The problem is developers will have hard time to accept your suggestions questioning your judgement subconsciously and consciously. If you keep telling them that you were once a hard coder, i am sure that won't help at all. so always make sure 1/3 rd time is spent in coding.
6) Make sure your team fully integrate the solutions with other teams. Encourage cross team communication. Make sure solutions are built with other teams feedback. The more other people is integrated in your team solutions, the more will be used and supported
4) Be humble. Redirect upstream praise for your team's work onto your team directly (away from yourself). Accept criticism for your team's work directly onto yourself.
5) Expect to do less actual programming, but still keep ownership of one or two components (UI, DB, etc) for up to 1/3 of your time. This helps to maintain an ear-to-the-ground on ongoing features/bugs and to communicate intelligently with the technical team.