It doesn't always work as designed (ok, maybe rarely works as designed), and TLs can get too bogged down in cat herding, planning, and bike shedding to actually work as an engineer. But at least the spirit of the role is sound.
It doesn't always work as designed (ok, maybe rarely works as designed), and TLs can get too bogged down in cat herding, planning, and bike shedding to actually work as an engineer. But at least the spirit of the role is sound.
If you are immature or competitive, you cease being a force multiplier to be a morale destroyer.
If you are more of a domain expert than your Product Managers, you will spend your time fighting and refining tasks to build features the right way.
If you don't have enough time to code, you'll go obsolete.
Where I disagree is with the idea of fighting with product owners. If there's a disagreement around approach or tech choices that's a sign we don't have enough information. Fighting or refining won't solve that. It's a signal that we need to do more discovery work and understand the problem better.
The problem is not needing discovery work or understanding the problem. The problem is when the Tech Lead is the one who's providing all the data for that discovery, or helping them understand the problem better, because of lack of expertise of PO/PM. Or having to push back because of incomplete knowledge.
If there is lack of information or incorrect information, POs should be able to get that information themselves. If a TL is the sole source of that info, then it becomes an issue.
IME this is very common. And it takes too much time of a Tech Lead's day.
If you are more of a domain expert than the product managers, argue for the product managers to be fired - they serve no purpose.
Now TLM (Tech Lead + Manager), however......there's a role that's set up for failure. Be a manager but be judged entirely on your technical contributions.
Any meaningful contribution or engineering is extra credit.