[sunaurus]

I always take it as a red flag when a manager wants to be responsible for technical decisions.

The best managers I've worked with have always made it their mission to serve technical teams by removing obstacles and making sure that the specialists have everything they need in order to create a high quality product. Managers who try to babysit developers and tell them how to do their jobs tend to just slow things down and lead to lower quality results.

[nilkn]

I think that being involved in the technical side and "babysitting developers" are two very different ideas that have little to nothing to do with each other.

> The best managers I've worked with have always made it their mission to serve technical teams by removing obstacles and making sure that the specialists have everything they need in order to create a high quality product.

I think you're underestimating the degree to which doing this requires a solid technical understanding when there are dozens of teams involved and interacting with each other. In order for an engineering manager to bring their team(s) a clear plan of what needs to be done with few blockers or obstacles in the way, often a lot of technical planning with other groups has to precede that. As always, management done right is the sort of management you don't notice -- but that doesn't mean a ton of work isn't happening behind the scenes to make things very organized and clear for individual developers. You could have ICs do that, but they wouldn't be writing much if any code, and they probably wouldn't want to anyway.

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