[EricBurnett]

I'm (at Google) one of those "technical leaders" - peer to a manager of ~50 with an informal title of "Uber TL", and no reports of my own. Though for us at least, responsibility still accrues to the manager - I'm a consultant in some sense, with impact through my ability to influence rather than any direct authority.

I'd love to see the end of this road, if other companies have taken it further. I personally offer guidance to the TLs in my scope (and that of my director, to a lesser extent), but have no technical leadership above me. And I think that's where it gets really hard - finding folk capable of being TLs for say 500 to 1000 people is hard.

[ethbr0]

The biggest argument I've heard in favor of TLs (or shudder architects) is that it keeps a company from hemorhaging technical experts who have little interest in people managing.

When it's done right, it seems to work well.

People who are interested in managing people become managers.

People who are interested in deepening technical expertise become TLs.

I think the often unvoiced key expectation that needs to be set that TL skillsets include (a) evangelism, (b) consensus building, & (c) flexibility.

I.e. If you're an unrepentant asshole who can't work with your colleagues and "lose" decisions in a graceful way that leaves everyone feeling okay, the company probably shouldn't make you an architect.

[EricBurnett]

> When it's done right, it seems to work well.

I think this is the most interesting truism of leadership. Which leads risk averse companies to minimize the harm a bad leader can have, and utilitarian companies to maximize the expected value - even when that results in tolerating terrible managers. I don't honestly know which strategy I prefer.

> ...is that it keeps a company from hemorhaging technical experts who have little interest in people managing.

In our defense, it's not quite that simple. I personally can and will write code in any product in my scope, often at the behest of an ongoing incident where the team in question lacks the necessary experience to get themselves out of the situation they find themselves in. E.g. breakdown of some communication protocol, backend knocked offline by a firehose of retries, corrupt database. But even more, my job is to _prevent_ incidents, whatever that takes. Over the last ~year I've concluded that a lack of sufficient staffing prevents any good long term future, and so my main (self imposed) project is evangelizing leadership for headcount. Primarily through the lens of technical arguments - I can tell you which systems will hit fundamental scalability limits first (that aren't being invested in!), and also the individuals across the org that are at highest burnout risk from toil.

Am I an architect? Sometimes. More often I'm a janitor. But most of all, I spend an inordinate amount of time understanding the technical product of hundreds of engineers, to be able to speak to any part of it.

And what does that qualify me for in terms of organizational responsibility? I have no clue :).