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.