[EricBurnett]

Relatedly, I'd love to see an experiment in segregating "people managers" from "organizational managers". Imagine having one manager who is responsible for coaching your career growth, helping ensure you have the right opportunities, etc; and another manager who is responsible for the product you work on. You could have lots of people managers for support, and few organizational managers for minimizing org chart depth between products and the CEO.

Of course, in some places this approximates the split between PM and eng. I don't have great breadth of experience, but I haven't seen that work amazingly... though admittedly, more from PM churn issues than necessarily fundamental infeasibility. But still, it might not be as simple as that.

[thomasmeeks]

I’ve seen that engineering manager / pm split work like magic before. Usually there’s also an amazing tech lead in there making it work. It’s rocket fuel for the product (assuming market fit, big assumption) and the career growth for the team.

It doesn’t happen often because most companies don’t want to grow their people that much. Consider the frequent HN comment about finding it easier to get a promotion/raise by finding a new job.

That outcome usually comes from some carefully crafted policies at the company level. Stack ranking is an example, though it is more popular recently to talk about in terms of bell curves (of 4-7 people, hah). Caps on raises, onerous documentation processes, and explicit and implicit limits on the number of promotions a manager can request at a time are all popular. There’s a lot of creativity going into crafting policies that limit career growth without saying they are limiting career growth.

Managers that care about people eventually figure this game out, realize how career limiting it is to push too hard on it, and either leave management or switch to caring about org/product stuff more. This has been consistent in my unscientific study of a dozen friends.

That said, I agree with you. I’d like to see that experiment done with a lot of intentionality and care.

[lupire]

"And here's something else, Bob: I have eight different bosses right now."

[foota]

This is roughly how some places do it with distinct management chains and technical leaders along the chain. So nominally leadership is the management, but the technical people under your directors are responsible for technical direction.

[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 :).

[m-ee]

What your describing is a matrix org. I’ve only seen managers praise it and every IC I know hates it, including myself. But maybe it’s done right somewhere.