This rubric is fine at a certain level of scale, but as a company grows, both in size and complexity, it becomes hard to apply except possibly in the leaves of your organizational graph (and not always then).

Personally I manage a team of 400+ engineers. They do the full range of embedded systems across multiple platforms, iOS and Android native development, full stack web development, backend systems, and data science. We go all the way from device drivers that are deployed to 10's of millions of devices to Spark jobs running in a reasonably scaled up cloud infrastructure (5 digit CPU counts, not 6 or 7).

Needless to say, I am not competent in all of these domains. I do my best, and when decisions get to my level I know how to make them in a way that doesn't leave me as the weakest link, but fundamentally I can't possibly be an expert in all of what we do. There aren't enough hours in the day or days in a life.

Compounding that problem, at this level of scale, I believe in cross-disciplinary ownership. We don't have an iOS team that throws things over the wall to a site team, or a FW team that only thinks about how to optimize their part of the world. That means many of my managers are also managing engineers who know orders of magnitude more about their discipline than the manager does. It turns out this would happen anyway, because the manager shouldn't be making most of the technical decisions, and they don't have enough time in the day to stay expert in even one discipline at the level a senior IC is expected to.

You can't expect your managers to be the ultimate expert across the domains they manage, and even if they happen to be, you can't expect them to be able to keep that position (our industry changes too rapidly). What having been a practicing engineer does for them is to give them a perspective on what matters, to ask the right questions, to help the team develop an ownership culture so that they don't rely on the deus ex machina of a manager know-it-all who tells them what to do. Very few of the skills they need relate to having been the best Javascript engineer on the team at some point in time. They need to know how to _develop_ the best engineers, not continue to occupy that role themselves.

Last thought here -- this compounds when you get promoted into a role of managing managers. For many managers, this is a harder transition than moving into management in the first place.