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.
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.
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.