It’s almost universally a very bad sign if managers are significantly contributing code. I agree with you that occasional bug fixes or small tweaks would be fin

It’s almost universally a very bad sign if managers are significantly contributing code. I agree with you that occasional bug fixes or small tweaks would be fine, but anything beyond that and it means the manager is taking time away from support and setting others up for success, which is way harder and requires much more vigilance. A manager should not be making tactical implementation decisions - they should trust their team to make those decisions, and offer higher level architecture & product guidance about the problems worth solving, the context and the constraints. Managers should be somewhat like 1/3 principle engineer, 1/3 product manager and 1/3 personnel / recruitment / rewards manager. The absolute worst is when a company very openly embraces “team lead” or “player coach” roles, which are essentially an unspecified dumping ground of any arbitrary, flailing responsibility from any domain, with no clarity and with unrealistic expectations of “wearing many hats” and getting no staffing or team growth yet still being expected to deliver high project throughput and still somehow manage personnel issues, compensation, team building and so on. “Team lead” is a bad cop out by senior leaders who are too weak to defend org structures they designed. They want to have their cake (take credit for constant reorgs) and eat it too (drop in to any part of a reorg that’s not succeeding and arbitrarily redefine a team lead role to mean whatever they want it to mean at that moment, for political convenience). Even though it might be fun to still do coding, your life as a manager is so much better if you refuse anything like “team lead.” Don’t do it. Only accept roles with super explicit clarity that your job is to be a manager, not an implementer, and require a company culture that really backs this up and affirms it.