A lot of technical leads who become managers assume they're doing a good enough job on the management side and that they have to master every technical detail, when the truth is they're only convincing themselves that their split allegiances, attention, and priorities aren't a problem of trying to work two jobs.
An engineering manager who was technical, listens to their staff, and delegates can still be respectable and has the time and focus to help the team in a greater capacity with non-technical things proactively rather than reactively.
An engineering manager who can setup an HA database is as useful as a fireman who can play chess. It's all well-and-good, but it doesn't add value to the management of the team if someone else has that duty. Technical leads yes, but not managers.
You've clearly stated an opinion, but not an argument. You've also smuggled in the claim that an engineering manager who ships stuff is performing two jobs. I argue that engineering managers who cannot ship stuff are performing half a job. (I don't really, but you can see why this is a fallacy in both directions: it's an argument around definitions.)
Your opinion is the same on made in the article and is the consensus view. To me, the consensus view is there for a lot of reasons, one of which is that it's a common anti-pattern for formerly technical engineers to become managers and let themselves get drawn into the code at the cost of management. In all things, balance. The other, more general anti-pattern is to see a failure mode and then presume the diametrically opposed opposite is the global optimum. If engineers are prone to be bad at management because they get sucked into building stuff, then whatever benefits may come from that should to be ignored: they should abandon it altogether. (This is a common error in other domains, like the canards "ideas are nothing execution is everything", "you should never pick stocks, and only invest in index funds", etc.)
It also turns out it's much easier to believe that engineering managers who ship code are worse managers, because it means that you can feel good about deciding you're going to stop coding: you're doing it to do your job better. You already have so little time anyway. But what if it turns out being able to ship stuff actually helps you in being a manager? Now it's harder: you have to decide where to draw the line. And so, it's a much more difficult thing to come to terms with since it means there are no easy choices and you actually have to live with the fact you are always going to suck at this in one way or another.
I argue that, all other things being equal, having the ability to ship with the team makes you a better manager. The question is if that is true or not, and if so, at what point does the trade-off stop making sense to maintain that ability. Creating false hypothetical situations like "setting up an arbitrary HA database" doesn't prove much of anything about the actual, local, domain knowledge I'm referring to that you get by continuing to perform IC-like work alongside the team you manage.
I replied elsewhere a longer form argument, in the form of concrete examples, why I feel being able to ship code confers benefits to engineering managers. I'm not going to argue about titles. Titles are useful for internal political signalling and are basically minimally-transferable cultural norms, but less useful for determining how to best take care of your responsibilities. For the purposes of this discussion I consider an engineering manager's responsibilities will be to maintain the velocity, mental health, and general happiness of their reports. People who argue about the role a person has and what they ought to focus on based upon their designated title, or in this case derive it in the opposite direction, to me, are mistaking the map for the territory.
Also, if you think I'm writing this to defend my ego, you ought to become a psychologist since you are able to read minds over the internet.
Then why are you writing? Why are you unable to interact without respect and curiosity but with adversarial hostility? Are you going to escalate to name-calling since you don't have an argument, only rationalizations to reinforce your worldview or the inability to consider approaches outside of your own? Maybe curiosity and self-reflection would help improve the quality of your conversations rather than promoting a religious doctrine through snide defensiveness.
Interesting that you’ve now accused me of arguing to protect my ego and being snide in the same breath as saying I’m the one being hostile. All I said is that you expressed an opinion, not an argument, which is explicitly true based on your first reply, and explained why if your argument was going to be about why actually there is no trade off why I disagree with it - based on your further responses it feels like you may have taken that personally. It wasn’t personal.
If you’re going to accuse me of a lack of curiosity then you need to explain why anything you have written actually does more than repeats the claims in the article I was explicitly rejecting, or why my claim that you leaning on titles to form your argument is just debating over definitions is false.
An engineering manager who was technical, listens to their staff, and delegates can still be respectable and has the time and focus to help the team in a greater capacity with non-technical things proactively rather than reactively.
An engineering manager who can setup an HA database is as useful as a fireman who can play chess. It's all well-and-good, but it doesn't add value to the management of the team if someone else has that duty. Technical leads yes, but not managers.