I guess I don't get what's objectionable about working for someone who doesn't understand how you do what you do. Isn't what matters being appreciated? I certainly can't work for someone who doesn't value what I do, but I can care less whether they actually understand how I do it.
I guess it depends on the perspective, and the attitudes of those above you towards your work. If people and product managers are showing deference to your team's expertise in this knowledge domain (whatever it may be), then that's good, and I don't think anyone here is going to complain about that working relationship.
Where folks get objectionable (myself included) is when those same managers conflate superior rank with superior knowledge. It's the CIO demanding we use a specific product suite without objective justification, or the SVP forcing a given architecture because it suits their political objectives rather than organizational ones. That's presently on the rise as tech companies (in particular) bring in "outside talent" (aka, the same failed-upwards managers and leaders of unrelated enterprises in their social circles) instead of promoting from within or hiring qualified candidates, and it results in a whole host of grievances and problems that can rot the org from the inside out.
The clue is the rise of these sorts of posts, trying to coach us on how to step into leadership roles and transition from Individual Contributors to People or Product Managers instead. The takeaway I got was less "managers shouldn't code", and more "managers should not assume their code is better or necessary just because they're managers"; in other words, to strike a balance.
And if they have no clue what the job is about they will inevitably appreciate/promote/give raises to people who talk the most random jargon in meetings rather than to people who actually work.
