Am I totally off base that a development group should be managed by a senior developer/experienced developer or maybe that actually has a negative impact to a development group?

I think that may or may not help...the real answer (I think) is that a development group should be managed by someone who is able to provide guidance while allowing the developers a certain latitude for creativity and ownership.

My two previous managers were highly skilled technically...in the same areas that I am. What should have been a wonderful collaboration turned into a classic, um, "spitting" match. Granted, I share the blame, but good managers stop those type of events from even starting. Good managers are able to focus on the real objective: hitting the deadline, solving problems, and so on. They're able to sense bad situations and diffuse them as appropriate.

My current manager is not as technically skilled at programming, though she's has programmed. However, she is highly skilled in the business that we write software for, a business that (frankly) I don't really care much for and therefore haven't taken the time to learn. She provides the business rules, I implement them and suggest alternatives. It's an interesting partnership.

The best manager I ever had was during my stint as a tech writer for a commercial software publisher. Two incidents illustrate why:

1. We were in Death March and had been for about a year. My book wasn't complete and I was leaving every evening at 5:00pm to attend rehearsals for a local theatre production I was in. She felt some pressure from upper management and other members of the team who were miffed because I was leaving while they were working. She confronted me with it.

   Stunned, I hit back with both barrels. I asked if she was unhappy with my work? (No) I asked if my work was sub-par. (No, far from it.) I asked if there was any question about my devotion to the project (No) I asked if she was aware that I came in after rehearsals and worked a few extra hours, trying desparately to get things finished. (Yes) Then, I asked, why are we even having this conversation? If you don't trust me, then fire my @$$ and be done with it. She didn't reply right away, thought, and then told me that I was right. I had never had a manager admit a direct mistake before.

   Furthermore, the incident was not discussed during my performance review, nor did it detract from it. And...I never heard another word about the problem.

2. The product was a database and I felt it was important to include some additional introductory material in the Getting Started manual, specifically a chapter discussing why normalization is important and beneficial. Since I'd recently been working in Tech Support, I knew how often the question came up. She challenged me on it, made me defend it, and listened when I did so. Interestingly, a certain review voted us higher than the competitors' products *because* of that chapter. (That was an eerie moment.)

My point being that a good manager does more than assign tasks, check schedules, or build Gantt charts. Good managers allow their employees to provide input; they foster collaboration. The best managers understand that software design is a partnership between the developers, the users, and upper management. You may not be in charge, but your input should be valued. You are not a drone, not a code monkey...don't allow yourself to be treated like one. Life is too short.

Technical people can be good managers--if they're willing to allow their people to help design the software. There are times to micro-manage (not many, but they do exist); however, the best managers will follow Truman's advice about how to best tell a man to go to Hell...Make him look forward to the trip.

If your boss isn't like that...well, the economy isn't *that* bad...yet.

--f