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