What a technical lead is accountable for

A technical lead is the person a team looks to when a decision has to be made and nobody else is going to make it. That is a simpler description than most job ladders give, and it is the one that holds up in practice. The title moves between organisations; the accountability does not.

Three accountabilities

Almost everything a lead is asked to do falls under one of three headings. Naming them makes it much easier to see which one is being neglected in a given month.

Direction. Somebody has to be able to say what the team is building, why it is worth building, and what it is deliberately not building this quarter. A lead who cannot answer the third question has not actually set a direction.
Technical judgement. Not writing the most code, and not approving every change, but holding a view on the shape of the system and being able to explain the tradeoffs behind it in terms other people can act on.
The people work. Making sure the work is distributed so that people grow rather than merely deliver, and that the difficult conversation happens while it is still small.

What it is not

It is not seniority in the sense of tenure, and it is not management in the sense of headcount and budget. A lead can be the least experienced person in the room on a particular subsystem and still be the right person to hold the direction. Conflating the lead role with the management role is the most common reason the role goes badly: the lead starts optimising for reporting and stops doing the technical judgement nobody else is positioned to do.

Why it is worth coaching

The three accountabilities pull against each other, and the pull is different every month. That is exactly the kind of problem that improves when somebody outside the situation asks about it regularly and has no stake in the answer.