[tannerc]

Isn't what you're describing precisely what senior ICs should be doing more of?

I agree with OP, the purpose of a manager isn't to manage the technical side of things but rather the people side. It's why they have direct rapports: to manage the people.

A better use of the IC's time is to unblock them so they can meet with stakeholders and develop a rich understanding of the work in order to do it most effectively.

In trying to "shield" the IC from developing an understanding of the landscape they'll be working on, the manager may accidentally be preventing the IC from getting the information they actually need to do their job well.

[nilkn]

> Isn't what you're describing precisely what senior ICs should be doing more of?

Yes, and I think the point I'm driving towards is that if this is the stuff you want to do, you're really not an IC at all -- you're an engineering manager with zero reports who doesn't have any authority, so you're making life 10x harder for yourself.

[pm90]

I think your view is seriously constrained by the assumption that you can't have both a manager and a senior IC on a team. You need both to be successful. Every team I've worked in that had success had both.

In these cases, the manager relies on the team, and the IC to get a clear understanding of the root of problems. You don't need to be super technically proficient to understand constraints, but understanding why those constraints exist requires a deep technical understanding, which is provided by the IC and the team. Using this knowledge, the manager has a perspective of the system and how to improve the system, and the manager tries to reason with the organization, trying to share that perspective with them.

The manager also relies on the IC to do spikes or POC's (or relies on the IC to select a crack team which have a good chance of success).

Most often, the IC has no interest in being in non-technial meetings all day, but the manager does. The manager loves working with other managers + product and helping them understand the issue, while the IC doesn't. The IC wants to spend most of their time on resolving technical issues, thinking deeply about the future and upcoming projects.

All of this to say: they're not exclusive, and both are required for successful teams. BUT, the idea that a technical manager needs to be super technical is not something I agree with.

[nilkn]

I'm not sure if you're actually disagreeing with me. Of course a team needs a technical lead who is likely a senior engineer. I think that much is obvious. However, that person is predominantly concerned with their own team's technology.

As an engineering director, I have an entire organization of teams I'm personally accountable for, and I have to make sure the work that's being planned out meshes well with what all the other teams are also planning. I cannot constantly be pulling in a dozen senior developers into every meeting every day to help me figure things out. I also have my own technical objectives I want to achieve for the company that cut across multiple teams or the entire engineering organization. Most of these considerations are technical in nature, and while a senior IC on one team can help they frankly don't have time to be involved in the whole process -- that would prevent them from succeeding as a senior engineer in their current role.

Under discussion is not the role of a senior engineer, but rather the technical track beyond that point -- roles commonly termed staff, senior staff, distinguished, principal, fellow, or even senior fellow. My core claim is there's more in common between engineering management and these roles than many folks tend to believe and/or realize.

Often an engineering manager is just someone at this level of seniority who also has rock-solid people skills and has been empowered in the organization to actually get bigger things done that cut across teams, though they may not themselves write code anymore.

Certainly I agree with you that not every manager needs to be deeply technical, but I think that for someone who is deeply technical, engineering management can actually be a much more powerful and interesting choice vs. trying to expand your impact without taking on formal leadership responsibility on an IC track.

[tytso]

The primary disconnect on this larger thread is a disagreement about terms. Does an "IC" mean someone who doesn't have any direct reports? What does it mean to be an "engineering manager"? Are staff, senior staff, distinguished engineers, et. al, without any direct reports part of "engineering management"?

The other big disconnect is in the size of companies in question. At the larger companies, you can have a clear separation of roles, so that some people are almost exclusively managing resources, and trying to match resourcing to business objectives, while other people are much more exclusively focusing on technical issues and how they can achieve business objectives by making the right technical decisions.

In these larger companies, the issue of people on "The Technical Track" not having the "muscle" of people in management is really not true, or at least, heavily over-simplified. (And this is another definitions question; at IBM and Google, Staff, Senior Staff, Principal, DE, Fellow, etc., were all considered as on the Technical track and were considered very senior engineers. Yes, they generally aren't coding much by the time they hit that level; although you might be surprised how much Fellows are still coding.)

[kevan]

>>>> ...vs. trying to expand your impact without taking on formal leadership responsibility on an IC track.

This might come down to cultural differences between companies. At Amazon leadership responsibility is formally baked into the upper SDE roles (Sr and above), literally in the role descriptions. There's definitely still value in being a technical manager, but that's not the only way to get formal leadership responsibility.

[pm90]

Apologies. I see the point you're trying to make, and I agree with you.