4 ms·

You seemed to skip their second paragraph, which is what I was replying to. Someone who can review diffs and even write a serious change every now and again is

You seemed to skip their second paragraph, which is what I was replying to. Someone who can review diffs and even write a serious change every now and again isn't the most knowledgeable person on the team. The person who is writing and reviewing all of the serious diffs is. And for many L6 EMs, you'll have three of those people reporting to you, they're all working on different projects, each of which you have partial but imprecise knowledge of (and sometimes, very little because L5s and FAANG are expected to be able to operate mostly independently). So you spend your time ensuring that everyone on the team has career growth opportunities, and that your less experienced people have mentorship, and hiring and arguing about headcount allocation and prioritization, which all matter, but which are all things that most engineers don't want to touch! Yes, managers should still have engineering experience (at least up to like director/vp levels, where IDK maybe they don't need it) but having a baseline knowledge of how to do a software is not the same as being the most knowledgeable person on the team.

benreesman 5y ago
I made a concrete statement about what I think the minimum technical bar for EMs is up to at least L7. I also remarked that "clearly this isn't your main focus" at that seniority, which you seemed to skip. The second paragraph, the one you seem to have an issue with, a combination of 2 things: - a few examples of extremely senior, extremely successful engineering leaders who stayed at or near the top of the game technically, and those are but a few examples from a very long list - an observation that in other fields, law for example, they call in the highly-knowledgable, highly-expensive, person capable of solving problems few in anyone else in the organization can and that this person carries titles like "partner" and makes the most money. I know this is a touchy subject and I've been trying to be less flamey on HN so I didn't go hard like the GP, but they're fundamentally right even if the language is a bit intemperate: there is a prestigious and important job track for people who are pretty damned technical/quantitative but not wildly hands-on and generally concerned as much or more with coordination and communication, particularly in cross-functional or externally-facing scenarios than software systems per se: product manager. As a wild oversimplification: when an EM becomes senior enough they end up as a CTO, and when a PM becomes senior enough they end up as a CEO. This is natural and healthy division of labor. An EM is concerned first and foremost with the health, happiness, and therefore productivity of engineers. On the foundation of the trust and rapport and deep knowledge that comes from that kind of engagement with their team, they are able to also be concerned with how their team fits into the bigger business picture: is this the right team for the needs of the business, what hiring and performance management would be necessary to make it so if not, what is a realistic schedule for the work that needs to be done given the strengths and weakness of the team members both generally and at this moment in time? When I'm wearing my hacker hat I have no interest in reporting to an EM who couldn't do my job in a pinch, I might respect that person on a lot of levels but I won't be interested in their opinion of how I should do my job. And at no time in my career has it been so easy to identify such managers: they are the "back to the office damn the torpedos" crowd. When the task tool, and the code review tool, and the oncall/incident situation, and the build wiki are not sufficiently comprehensible to an EM to form an opinion of who is doing a good job, the instinct to do "ass-in-seat" performance evaluation is strong, the instinct to be "visible" is strong, and narrative that there's value add looks very threadbare over Zoom. This bloc is probably too big and too entrenched to dislodge, but WFH for 2 years working out just fine is the best chance we're going to get. IMHO.
- joshuamorton 5y ago
  > - a few examples of extremely senior, extremely successful engineering leaders who stayed at or near the top of the game technically, and those are but a few examples from a very long list But all of these are the exception, not the norm. You said you've been in a FAANG style org, so you've been able to view the org-chart. For every Jeff Dean or John Carmack, there's three-dozen directors and VPs who manage large orgs whose names you've never heard of and who haven't checked in code in half a decade. They're still usually very good managers. (A reasonable opinion I've seen, btw is that if you're managing a team of say 5 or more people, if you have time to make regular code contributions,you probably aren't focusing enough on your other managerial responsibilities and are letting your reports down) > - an observation that in other fields, law for example, they call in the highly-knowledgable, highly-expensive, person capable of solving problems few in anyone else in the organization can and that this person carries titles like "partner" and makes the most money. This is pseudo-true. Partners are called partners not because they're capable of solving problems no one else can, but because they carry an ownership stake, and I'm not a lawyer (and presumably neither are you) but the impression I get is that law is far more delegatory than software, where a partner may call in some favors to address a problem, but will also have 20 Jr. associates investigate 20 different possible approaches and write 20 different briefs to then choose between. > When I'm wearing my hacker hat I have no interest in reporting to an EM who couldn't do my job in a pinch, Maybe we have different definitions here, but I've never, or perhaps once, had a manager who I felt could do my job in a pinch, and I was a new grad and he was the worst manager I've had at the time (although he very quickly got better as he learned to be more hands off). A manager who could do my job in a pinch is too micromanaging. Maybe you mean something different in that they could, given a week or two to turn-up on the project take over, but that's not really what I'd consider "in a pinch".
  - softveda 5y ago
    > Maybe we have different definitions here, but I've never, or perhaps once, had a manager who I felt could do my job in a pinch, The chief of Air Force still flies the fighter jets just as well as the junior pilots. The head of surgery in a hospital still operate just as the junior surgeon. Why does tech have to be different?

benreesman 5y ago

I made a concrete statement about what I think the minimum technical bar for EMs is up to at least L7. I also remarked that "clearly this isn't your main focus" at that seniority, which you seemed to skip. The second paragraph, the one you seem to have an issue with, a combination of 2 things: - a few examples of extremely senior, extremely successful engineering leaders who stayed at or near the top of the game technically, and those are but a few examples from a very long list - an observation that in other fields, law for example, they call in the highly-knowledgable, highly-expensive, person capable of solving problems few in anyone else in the organization can and that this person carries titles like "partner" and makes the most money. I know this is a touchy subject and I've been trying to be less flamey on HN so I didn't go hard like the GP, but they're fundamentally right even if the language is a bit intemperate: there is a prestigious and important job track for people who are pretty damned technical/quantitative but not wildly hands-on and generally concerned as much or more with coordination and communication, particularly in cross-functional or externally-facing scenarios than software systems per se: product manager. As a wild oversimplification: when an EM becomes senior enough they end up as a CTO, and when a PM becomes senior enough they end up as a CEO. This is natural and healthy division of labor. An EM is concerned first and foremost with the health, happiness, and therefore productivity of engineers. On the foundation of the trust and rapport and deep knowledge that comes from that kind of engagement with their team, they are able to also be concerned with how their team fits into the bigger business picture: is this the right team for the needs of the business, what hiring and performance management would be necessary to make it so if not, what is a realistic schedule for the work that needs to be done given the strengths and weakness of the team members both generally and at this moment in time? When I'm wearing my hacker hat I have no interest in reporting to an EM who couldn't do my job in a pinch, I might respect that person on a lot of levels but I won't be interested in their opinion of how I should do my job. And at no time in my career has it been so easy to identify such managers: they are the "back to the office damn the torpedos" crowd. When the task tool, and the code review tool, and the oncall/incident situation, and the build wiki are not sufficiently comprehensible to an EM to form an opinion of who is doing a good job, the instinct to do "ass-in-seat" performance evaluation is strong, the instinct to be "visible" is strong, and narrative that there's value add looks very threadbare over Zoom. This bloc is probably too big and too entrenched to dislodge, but WFH for 2 years working out just fine is the best chance we're going to get. IMHO.

joshuamorton 5y ago
> - a few examples of extremely senior, extremely successful engineering leaders who stayed at or near the top of the game technically, and those are but a few examples from a very long list But all of these are the exception, not the norm. You said you've been in a FAANG style org, so you've been able to view the org-chart. For every Jeff Dean or John Carmack, there's three-dozen directors and VPs who manage large orgs whose names you've never heard of and who haven't checked in code in half a decade. They're still usually very good managers. (A reasonable opinion I've seen, btw is that if you're managing a team of say 5 or more people, if you have time to make regular code contributions,you probably aren't focusing enough on your other managerial responsibilities and are letting your reports down) > - an observation that in other fields, law for example, they call in the highly-knowledgable, highly-expensive, person capable of solving problems few in anyone else in the organization can and that this person carries titles like "partner" and makes the most money. This is pseudo-true. Partners are called partners not because they're capable of solving problems no one else can, but because they carry an ownership stake, and I'm not a lawyer (and presumably neither are you) but the impression I get is that law is far more delegatory than software, where a partner may call in some favors to address a problem, but will also have 20 Jr. associates investigate 20 different possible approaches and write 20 different briefs to then choose between. > When I'm wearing my hacker hat I have no interest in reporting to an EM who couldn't do my job in a pinch, Maybe we have different definitions here, but I've never, or perhaps once, had a manager who I felt could do my job in a pinch, and I was a new grad and he was the worst manager I've had at the time (although he very quickly got better as he learned to be more hands off). A manager who could do my job in a pinch is too micromanaging. Maybe you mean something different in that they could, given a week or two to turn-up on the project take over, but that's not really what I'd consider "in a pinch".
- softveda 5y ago
  > Maybe we have different definitions here, but I've never, or perhaps once, had a manager who I felt could do my job in a pinch, The chief of Air Force still flies the fighter jets just as well as the junior pilots. The head of surgery in a hospital still operate just as the junior surgeon. Why does tech have to be different?