I don't like mixing the 2 but maybe because I don't do it often (I'm more on the technical side). When I do, I feel I am half-assing the technical part and shor

I don't like mixing the 2 but maybe because I don't do it often (I'm more on the technical side). When I do, I feel I am half-assing the technical part and short-changing the people expecting better management. A no-longer-codes, ex-coding manager has some of the advantages, in that they should still not need things dumbing down, but do need to delegate everything technical to the team because their hands are tied. If things are not dumbed down too much, and they are involved in technical discussions even if not the actual implementation, then they can stay on top of the technical side. Not saying your way is bad, just difficult! Some mistakes I have been guilty of with your approach are: If you do not delegate work well then you as a coding-manager can become a bottle neck. Sometimes work as a manager is unpredictable and breaks the flow of the coding part. Your coding work has to be passed to someone else (wasteful, as they need to get up to speed on it, context switch, etc) or others have to wait for you to finish the interruption manager-stuff and carry on with your technical work. A manager like that can be tempted to make snap decisions (which may later turn out to be wrong or costly). Whereas a "dumb" manager can genuinely use the excuse that they have to consult with the team before making a technical decision. Of course you can always say you need to consult with the team, but it is really tempting to speed things up by short-circuiting the process and making decisions right away.