If an L6 manager could keep all of the details of all of the things all their reports are working on organized, they aren't handling enough scope. Imo that's the difference between 5 and 6. You can no longer track all the details in one person's head.
That's not what they said, is it? There is a huge difference between what they said and how you interpreted it. They said "you need to be able to build the software and review diffs and write serious ones now and again" and "it’s very difficult to manage a process that you don’t understand with some sophistication" (emphasis mine). How do you get 'know every little detail about everything' from that?
It seems obviously true to me that any manager who can't "build the software", "review diffs", and "write serious [diffs] from time to time" is useless. Anyone who disagrees with this is probably dead wood, spends their time fighting political wars about issues they don't understand, and their team is more likely than not constantly fire fighting and in serious trouble (in my opinion).
If I had a dollar for every time some clueless manager lectured me about how to write software, and I rolled my eyes and ignored them, and they never found out (because they had no idea what was going on to begin with, and were just posturing based on something someone said) I would have at least $100. I obviously have a chip on my shoulder here, but managers who barely know what is going on still tend to want to 'contribute', which of course they can't do in reality, so they end up playing keyword matching and 'helping' the team avoid 'duplicate effort'. For example, they will see one team building something, and another team building something, and notice some of the words are the same, and then make a big show of 'avoiding duplicate work', but in reality the use cases are extremely different and nothing was being duplicated. Once they have alienated enough of the team, people just start telling them nonsense and they have no way to know it. Productive, smart people start to leave or lose motivation. A fast pace is replaced with constant excuses and a team that is basically no longer showing up for work. The manager can't tell the difference. This is what managers who aren't in the details are like, pretty much without exception.
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.
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.
