> 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?
An air force officer may have to qualify on their aircraft each year, but they're unlikely to be "the most experienced" fighter pilot, and it's common in the military for enlisted people to make fun of officers for being too abstracted away from the life of a soldier.
> The head of surgery in a hospital still operate just as the junior surgeon. Why does tech have to be different?
Because the load we put on medical personal is abusive and we shouldn't copy it in tech?
You've got some reasonable points and I don't just want to completely gang-tackle you here, but there is a part of your argument that I think is sufficiently incorrect in a sufficiently harmful way that I'm going to sort of keep at you about it, in what I hope is an open-minded or at least respectful way.
Some people like the book "Coders at Work" (I do), some do not, but almost anyone would agree that the people interviewed are absolute luminaries [0].
There are 15 chapters comprising 15 interviews. You have to get to #6, arguably #7 before you find someone who at the time of writing wasn't both a world-renowned hacker and currently or at one time a demonstrably successful engineering leader. The first 5 being: jwz, Brad Fitzpatrick, Douglas Crockford, Brendan Eich, Joshua Bloch. It starts to get a little blurry in the second half because it's so thick with CS academics (who in a different way also do engineering management), but you've still got VP-types who still code like Peter Norvig. The ~50% who aren't demonstrated engineering leaders are super hard-core CS researchers like Donald Knuth. The book doesn't even interview Cliff Click, or John Carmack, or talk about the fact that Larry Page and Sergey Brin wrote the first version of Google themselves and continued maintaining parts of it well into hyper-growth. Eric Schmidt wrote `lex`. When Jack Dorsey was recruiting me for Square over lunch he made an incredibly eloquent argument about why he uses OCaml rather than Haskell for his personal hacking.
At the time I was an L7 EM, my L9 boss didn't have much time to write code, but asked probing questions about everything from the merits of various binary classifiers given imbalanced underlying Bernoulli distributions to the algebraic properties of the data structures we were using for distributed systems convergence.
I don't dispute that plenty of successful leaders in technical organizations have become rusty as hackers when they hit the mega-seniority, but the idea that some L6/L7 manager shouldn't be able to lift some of their team's serious code off the ground, let alone some undergraduate dynamic-programming interview question as was the original point of my original post is simply contradicted by a mountain of evidence both generally-available and anecdotal to numerous people in this thread.
You can get ahead as a mid-level EM without knowing the frib-frobs from that whatsits, but God-willing I'll never work for one again. That's a visibility game, it's a popularity game, it's a schedule-too-many-meetings game, it's a post-too-much-on-the-internal thing game. Fuck that game.
> I don't dispute that plenty of successful leaders in technical organizations have become rusty as hackers when they hit the mega-seniority, but the idea that some L6/L7 manager shouldn't be able to lift some of their team's serious code off the ground, let alone some undergraduate dynamic-programming interview question as was the original point of my original post is simply contradicted by a mountain of evidence both generally-available and anecdotal to numerous people in this thread.
I think this is the root of the disagreement. I want my managers to be technically capable with an engineering background. As far as I know, my entire leadership chain, arguably excepting my SVP and CEO (at Google) have such a background. Yes they should be able to pass a tech screening and certainly system design.
They should have enough knowlege to know why you're making certain technical decisions and be able to see that you're justifying them well. That's all true. What I'm saying is that a manager who is staying so deeply aware of the details of all of their reports work that they can drop in and take over in a pinch probably has too much context. I'm not making an argument on abstract technical ability or knowhow.
Like in the same way that my entire management chain has technical knowlege and background, practically none of them have submitted code at work in the last 3-4 years at minimum, for some that's their entire career at Google. I expect that, with enough effort they could all work on the projects I work on and make contributions, but they'd need to learn all of {language and codestyle, libraries and relevant tactical design patterns and norms, various technical constraints to the design that are important but nonobvious}, so in most cases it would be similar to onboarding someone who was a technical contributor from another team or an experienced new hire. I don't really consider some random employee of Facebook to be someone who could "do my job in a pinch" either, even if they're more technically competent than I am.
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?