[AStellersSeaCow]

Depends on the company and management. Google codifies this role to some extent as Tech Lead, which is an engineer expected to act as a force multiplier and mentor more than an individual contributor.

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.

[whstl]

Tech Lead is a very difficult role. :/

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.

[onion2k]

I'm the frontend lead in a company of about 200 people (mostly devs) these days, and the idea of being a force multiplier is spot on. I'm not there to be the best dev or the most knowledgable; I'm there to lead the conversation and amplify people who are saying good things. Having a pretty deep understanding of the tech is useful so I can tell what those good things are. I am absolutely not in the company to show off or take credit for what my teams do.

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.

[whstl]

I never said one should be fighting. My point is that POs/PMs should know the domain at least as much about the domain as TLs do.

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.

[3np]

Domain expert, not tech expert

[jen20]

> 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 are more of a domain expert than the product managers, argue for the product managers to be fired - they serve no purpose.

[TheRealPomax]

It also doesn't get people promoted to that position just because that's what they're doing. Because politics.

[Arainach]

My experience at Google has been that TLs were generally strong engineers who were doing that kind of mentorship and product leadership, so to the degree that it's a "promotion" (same money, more responsibility isn't a promo in my book) it does seem to go to those who are doing it.

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.

[nobodyandproud]

I have to manage up, gently, reminding my manager and his peers that we’re managers first.

Any meaningful contribution or engineering is extra credit.

[AdrianB1]

Is that a higher level position ("promoted" suggests that)? In my FMCG IT department I am the TL & "technical architect", but I am on the same level as a senior developer, just having in the top 3 priorities the coaching and mentorship of all technical people in the department and no code expected (I do write some as examples or templates). What is the TL level in Google vs developers and architects?

[Arainach]

No different. TLs are Software Engineers in title, track, compensation, and performance reviews. Most TLs are L5/6 (Senior or Staff).

[mlhpdx]

The TL role is a little restrictive IMHO. I’ve worked with very junior people who have a very effective ability to pair and improve others’ effectiveness. Perhaps as they learn they also teach.

[teirce]

This was my experience as well. It's completely up to management to recognize these kinds of engineers regardless of role name or leveling.