No, I'm not talking about those kinds of skills per se. ("Fundamental revelations.") I'm talking about:
- Grokking what actually sucks about the tools, languages, frameworks, etc in use. And grokking what complaints of suckiness are shallow or misplaced. The former is an opportunity to deliver empathy for the team's suffering and propose good solutions, the latter is an opportunity to remind engineers (esp junior ones) not to be overly-cynical or see problems where they don't truly exist.
- Ability to participate as a true peer in technical discussions, which deepens the bond you have with your team. If you are able to contribute one or two concrete, correct, and actionable ideas that unblock developers or the project's construction every quarter, it pays dividends imo in counteracting dynamics where you are considered an "other" in certain contexts given your position. I'm not talking about things like "maybe you should write some tests" but "maybe you should ditch that testing framework because the problem you are hitting is a non-issue if you just write a special harness yourself. You can start from mine." It's no silver bullet, but it helps. If you literally save a week's worth of effort for a team member by cleverly reframing the work they are doing to a better MVP they can handle (via your domain knowledge and intuition about implementation difficulty) they will be unlikely to care if you accidentally forgot to send them a birthday email. If you don't do that regularly, and basically are a full people manager, the missing birthday email could be a big problem.
- If you aren't in the trenches at all, lots of problems will crop up over time that are insidiously hard to see once you've exited having the domain knowledge. For example, you won't be able to assess talent well enough to flag bullshitters who manage to sneak past your team's interviews. (Given you are the manager, you probably tilt more towards having the people skills needed to detect bullshitters which your team lacks, but without domain knowledge, neither you nor your team may have the total sum of skills needed to detect them.) Or, when giving overview discussions of how the software systems work to other managers, your team members might have to start biting their tongues when you're explaining things in a way that is objectively incorrect but coherent in your (now shallow) mental models. Having to regularly hear your manager saying something that is totally wrong is demoralizing, because it means you either have to "educate" your manager, which is awkward, or you have to effectively endorse what they are saying by staying silent.
All of these come from a loss of literacy in the local domain of the work your team is doing, not in general principles. These are totally different forms of literacy, and the latter one is dynamic and requires effort to maintain (and losing it comes opportunity cost.)
Edit: Also, people saying sitting in code reviews is good enough are fooling themselves imo - to believe that you also generally need to believe that you can become a good programmer on a project by just doing code reviews enough and then instantly be able to execute as a top-tier team member. This is objectively false. So the question is what margin is needed between "code review level literacy" and "building literacy" to get the benefits I mention. I'd argue it's a pretty big margin.