There are lots of disciplines where highly skilled persons advance to first line management and continue to perform the skill that launched them. But there ar

There are lots of disciplines where highly skilled persons advance to first line management and continue to perform the skill that launched them. But there are diminishing returns as you move up management. Part-time management of a relatively small team coupled with part-time hands-on engineering for the same team works fine. Management of an engineering team requires being in the team's work, and coordinating between contributors anyway, and taking direct responsibility for some elements can contribute to that. But beyond first-line management, two things are true that argue against having people both be individual contributors, and managers: First, maintaining your skills at full fluency for actual coding and engineering is a major commitment. To be a contributor in any significant system, you need to keep a lot of details fully current, and that's harder, the further away from the day to day building your primary responsibilities demand you be; second, no project, program or product manager wants a part-time senior manager, who is likely to be dragged away from day-to-day concerns at any and every turn, and who can't possibly keep current with the details of the project at the lowest level, responsible for some component in the critical path of their project or product. As an executive, responsible for multiple programs and products, I needed managers who were completely tuned into the bigger picture of their particular program or product family, and how it fit into the overall strategy of the company or division. Without question, you want people in these roles who understanding engineering, deeply and capably enough to be able lead, inspire, and read their teams (the one skill every manager and executive in charge of technical engineering needs is the ability to judge the plausibility of what their teams are telling them, because the roll-up of expectation and promise mismatched with ability is project and product disaster), so former developers are probably a good fit. And if they want to code as part of their development time, somewhere out of the management path, that's great. I did, all the way through the rank of CTO. But I never put my organization in the position of relying on me delivering anything in terms of actual code. (BTW, I don't think the author's comparison to surgeons is at all apt. Every surgery is a stand-alone project, and if you're a capable surgeon for a given surgery, and can arrange your calendar so that you do enough to maintain that edge, then you can do them, and leave them, and not in any way dilute your attention to management. That said, where I worked before retirement, where every leader of a clinical department was an M.D. appropriate to that department, and still practiced medicine, they all also had full-time, dedicated administrative partners who actually did all the "pure management" while the M.D.s provided primarily strategic direction and leadership.)