I agree, that advice is more for managers than tech leads. A mistake I've seen orgs make often is promoting their best developers into role where they don't code. A tech lead that doesn't code is a manager.
I am sure the meaning of "lead" varies from company to company. This advice applies to any role where you have any degree of responsibility for others' success (and haven't before).
Where I worked, as a lead I was probably doing up to 50% individual contribution and the rest "management". But I have seen new leads in the same role do 150% individual contribution, and then let their team down on leadership tasks because they've let themselves become swamped. This is a very common error for any newcomer to a job that involves leading other people (which OP specifically says is their role).
I don't think it's an error to put a coder in a position of leading others; it's just that being a productive coder is a weak predictor of being a good lead— you have to look at other markers. Having that kind of "on-the-ground" understanding can be a great strength that can't be had any other way.
A tech lead should code, but most of what they achieve is through code written by others, so that should be the focus of their work and what they're evaluated on. The coding done by the tech lead is to (a) keep in touch with what's happening; (b) maintain technical standards and infrastructure; and (c) key parts that require specific expertise, but all these three things essentially facilitate the productivity of others, not mainly make an individual contribution.
