This is a good article, and I find myself agreeing with it almost entirely. My current manager is one of the most effective development managers I've ever had in my career, and I think a good part of that is because he is involved in the codebase, but not directly responsible for new features in whole.
I have had managers with no concept of what's going on the codebase, and those were dysfunctional development teams that produced poor results, despite great communication and productive meetings.
I have had managers that were effectively another engineer on the team, and those were dysfunctional development teams that produced decent results, but had poor interaction with stakeholders and no unified direction.
As in many things, the ideal seems to be a happy medium. Someone who can read the code, who can write the code, and is interested in both, but whose duties are not primarily to do so.
I agree with this sentiment! One way to set up teams is with a squad leader who acts as shit shield first, and developer if the company is running smoothly. That way if the boss manager is a full time shit shield with little time to understand product, the team still has a local product owner to guide the team’s vision and concept of the product, but the power imbalance is also less as the team lead could fairly easily be deposed by accessing the manager.
I have had managers with no concept of what's going on the codebase, and those were dysfunctional development teams that produced poor results, despite great communication and productive meetings.
I have had managers that were effectively another engineer on the team, and those were dysfunctional development teams that produced decent results, but had poor interaction with stakeholders and no unified direction.
As in many things, the ideal seems to be a happy medium. Someone who can read the code, who can write the code, and is interested in both, but whose duties are not primarily to do so.