"Lead or follow, but GET OUT OF THE WAY!"

       - plaque on the desk of Ted Turner

I've worked with some really GREAT managers, several of whom had absolutely no software development experience.  Some were hardware engineers, some were from marketing, and some were just individuals with relevant domain expertise.  Qualities that made them great engineering managers included the ability to quickly grasp the GIST of technical issues, highly-developed BS-detectors, calm in the face of a need for decisions on the basis of limited information, the courage to say "no" to upper management when necessary (and the willingness to fight, to make it stick), intolerance of empty beauracracy, a commitment to the highest (practical) engineering standards, and acceptance of the fact that plans and predictions inevitably CHANGE, incrementally but continuously, sometimes right up until near the very end of a project.

A good engineering manager enjoys getting their hands dirty with the evolving product, and is able to provide constructive feedback like "I was playing with the product yesterday, and I noticed X, Y, and Z", or "How can we design feature A to be better than a similar feature in our competitor's product?"  A poor manager takes refuge in a filtered subset of second hand information ABOUT the project, in the form of tidy reports and spreadsheets and charts, and may go to great lengths to avoid commiting to a decision involving actual technical or design issues.  Unfortunately, over the course of dozens of projects, at half-a-dozen different companies, really good managers have been in the minority, and were often handicapped (if not initially, then after the first or second reorg.), by having to report to individuals farther up the chain who seemed to consider "management" to be a TITLE instead of an ACTIVITY.

Some managers become obsessed with being recognized as the primary source for all information and decisions on the project.  I once walked into a project manager's office, with print outs of bug reports spread out all over her desk, who complained she was being overwhelmed with issues reported by our publisher client.  Since I'd recently resolved several issues just by speaking directly with one of the publisher's engineers, I curiously leaned over to look at one of the reports, and she practically THREW HERSELF onto the desk, covering the print outs with her arms, as I sloooowly backed out of the office.  On another occassion, a year into a job at the Tokyo offices of a US investment banking firm, I was CC'd on email that revealed that a certain middle manager had been rewording requests for information from upper management, and then rewording my responses, in order to hide the identities of the original email authors and ensure that they remained at the center of all communication.  That would have been fine (if a little silly), except that they sometimes misunderstood either the original request or my response, creating confusion and wasting everyone's time.  Some dysfunctional managers insist on personally taking charge of presentations, or leading discussions, on issues with which they have only a very superficial understanding, where they hopelessly mangle key technical information, or sidetrack the proceedings onto irrelevant (but more familiar, non-technical) issues.

Managing software engineering is HARD!  Even skilled developers who take on a management role quickly lose touch with continually-evolving development technologies and best practices, and must depend on their top engineers for guidance on project decisions.  Identifying RELIABLE sources for information from among the development staff is especially difficult for non-technical managers, since it is easy for mediocre developers to fake a convincing level of expertise, while many of the best developers don't bother to cultivate the kind of basic social skills that engender management trust.  Some organizations resolve this by splitting management responsibility, giving a "Technical Lead" authority over a project's engineering-related issues (including issues which are not strictly technical, such as "Joe is not performing and needs to be taken off of the project"), while the "Project Manager" takes on a more administrative role, becomming responsible for shepherding issues through the corporate beauracracy so the engineers can focus on... engineering.