The article's argument is founded on the idea that non-engineers should not manage engineers. Since this idea reduces to nonsense at the limit, it seems worth b

The article's argument is founded on the idea that non-engineers should not manage engineers. Since this idea reduces to nonsense at the limit, it seems worth being skeptical about it throughout its domain. Limit: CEO -- it is not possible and no one would seriously suggest that a CEO must be expert in all disciplines they manage. Therefore at some extreme we must admit that functions can be managed by non-experts. Taken a step down, does the most engineering leader reporting to the CEO need to have been a practicing engineer? If we examine this carefully, this is also a kind of nonsense. Such a person is usually managing a wide array of engineers working across multiple disciplines. We cannot expect them to be an expert in all areas that they manage, given that these will likely include some element of infrastructure, quality, security, performance, front-end, back-end, mobile, and potentially other disciplines. Even if you had a mobile-only team, it's not likely to find a leader who is an expert in both iOS and Android. Ok, let's go down another level, to a director that manages a given domain of engineering, for instance an iOS engineering team. First of all, at scale most companies I've worked with do not even organize in this way -- they find it most efficient to build high-functioning teams that have most if not all of the disciplines needed to ship product in a given business problem domain. Since this is simply a repeat of the above issue, I won't cover it again, in favor of focusing on the specific issue of someone managing a discipline that isn't matrixed out like this, perhaps a backend infrastructure team. In a reasonably-sized team (50+ engineers), such a person has no time to be actively involved in the development process, and likely has not had time for this in several years at a minimum. Even if they do maintain side projects that use the technologies of the team their efforts are at best dabbling and cannot be compared to someone who is full-time engaged with those technologies. I would not trust such a person to make a reasonable estimate for degree of effort when it comes to any given specific project -- they are simply too far from the current state of the codebase and technology, despite their having been an implementor in the past. Now we get down to the case of a manager of a team. If they competently manage more than 6-8 or so people they likely have no time free to be actively involved in development and effectively are in the same situation as a director, hopefully with more recent context. If they actively involved in development, then they are probably operating in a role that is best described as "tech-lead / manager". I would trust and expect someone in a role like this to be able to judge level of effort for work their team is doing provided they are actively working in that discipline (cross-discipline teams as described above will include a solid percentage of work that they are likely not expert in). Hopefully it goes without saying that this is a minority of engineering managers, even correcting for the tree-like structure of most engineering teams. Finally, as other commenters have pointed out, managers are required to spend a great deal of time (often 100%) in meetings and dealing with personnel issues. These require skills that are not specific to engineering, and as managers grow in their career, they will get stronger in these areas (and weaker in terms of their ability to engage directly with the work that "line" engineers do). You should work with the grain of a manager's natural skillset trajectory, not against it.