I've seen absolutely brilliant developers fail as managers because they got so bogged down in the technical hurdles of developing the code that they failed to see the big picture-- that the project they were developing was certain to be cancelled, for example. Sometimes technical knowledge can lead to odd blind spots. One manager of mine, for example, believed that a large Perl project should be ported to Java, simply because he was more familiar with that language-- even though few of his employees were familiar with Java.

The best managers I've worked for hired bright people and worked as facilitators-- tried to figure out what they needed to do, prioritized tasks for them, and worked to make their employees more efficient. The least effective managers I've seen did the reverse-- tried to advance themselves by making their employees' lives more difficult, made priorities less clear (Me: "I can do this or that... which?" Bad manager: "Do both!"), and failed to trust their employees.

The one thing that I find useful about senior developers as managers is that they understand the software development process, which is a fairly unique activity. They hopefully won't try to manage it as though you were digging ditches ("It's not done? Program HARDER!")

A good manager who listens to his/her employees and works to make them more effective (and gets out of their way) will pick up the software development process pretty quickly-- there are a number of books on it out there, after all. (It never fails to amaze me how few of my managers have read any book at all on the software development process.)

It's very subjective, though. Your mileage may vary.

stephen

Both of you brought up a good point - personality is very important. It seems that the more technical managers can communicate on the same level with developers. But it is true that in time non-technical managers can reach the same level. I've found that technical managers understand developers and they seem to view the project in a more technical mannner than non-technical managers (that I've seen so far, I admit.. I should be more patient and give it some time) - this manager has a more marketing prospective - which is also important down the line. It almost seems that the market aspect of the product overshadows the functional aspect of the product. I guess I just get a tad frustrated, that functionality is lost over a marketing - when in reality the users want the functionality. More than likely the lost functionality will be brought in with the next version.

That isn't realistically going to happen in any company of reasonable size.

Yeah, it is nice when your manager understands your needs. But it isn't going to always happen, and when it doesn't you have to live. That is when it is important to know how to communicate with them and vice versa. You have needs. They don't need to know how to do your job if they know enough to understand your requirements.

However personally I would prefer a capable manager who did not understand programming to a capable programmer who did not understand managing. Managing people well is a subject in its own right. And not a particularly easy one. To get some sense of how much there is to know it is worth turning on JavaScript and skimming some articles by Jim Collins. (I recommend the article on Level 5 leadership as a good sample.)

Now this is not to say that there are not special concerns with managing software development. Of course there are. And it is good for developers to be aware of what some of them are. (Starting with The Mythical Man-Month and working onwards.) But it can be done with a non-developer at the helm - if it is the right non-developer. And it can fail drastically with a developer at the helm if they don't know anything about management.

So ask yourself, is your manager competent? Does your manager appreciate that you are bringing specific expertise to the table that deserves to be listened to? Do you appreciate that there is more to successful development and running a business than just producing good software? What are your working conditions like? Does the company use standard good development practices like version control? Can you talk to your manager about personal issues?

The answers to these questions are likely to be more relevant than the detail of whether your manager has done your job in the past...

How can being a crack developer hinder you when you're promoted to manager? There are several ways:

Thinking that it's all a technical problem. As individual contributers, we're primarily rewarded for our expertise in solving technical problems. Projects, however, are a mix of technical problems (most of which should be delegated), time and resource management problems, and political problems. If a manager keeps expecting to be rewarded solely for solving the technical problems, they're not going to be effective.

Tunnel Vision. We see things through the filter of our experience. A manager who was successful as a developer using a particular bag of tricks can expect that same bag of tricks to work for a new group under new circumstances, and can block the examination or adoption of new tools or techniques. "Why, back in my day we all made flowcharts and were happy with them. Quit all this talk about UML and get back to work."

Failure to account for individual differences. Developers sometimes have trouble imagining what it's like to live inside someone else's head, and thus have trouble imagining how other people's approaches to problems can be so... wrong different. This can be a hindrance for an individual contributer, but can be a disaster for managers. If you can't understand and work the different viewpoints that members of your team bring to the table, you're liable to commit any one of a number of grevous management sins.

Failure to estimate. A manager who can't get outside of their head, to distance themselves from their past development experiences, risks the sin of estimating on the group's behalf based on how they would do it. This gets compounded when a freshly minted manager is working with a larger team, and doesn't yet fully understand how the added communication overhead is non-linear. "Well, if there were six of me we could do this in six months."

You're right I would just add :

Inability to delegate. A bad technical leader think that as he can do it better, he should do it.
This prevent him from doing his jobs (make his TEAM produce better) beccause he will have less time to transmit his knowledge, plan/coordonates things...
The worst effect to this behaviour is to my mind that the coders feel under-estimated (and in a sense it's the case) and this tend to act on their mood and so on their productivity...

NOTE : I just like to precise what I said earlier, I don't think that technical manager are better, I say that I met more tech-manager in the good managers group than non-tech ones.
Of course a good tech guy won't automatically make a good manager, but I still do believe that it will be even harder for a non tech one, and I guess that you all know why (haven't you deal with commercial manager ? Financial one ? ;-)

"Only Bad Coders Badly Code In Perl" (OBC2IP)

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

This is a hard lesson for managers-in-training, basically that the best people to hire are the ones that you think are smart enough to challenge you. Would you want your staff dumb enough to do your bidding without question? That only works for manual labour, where staff are extensions of the manager's body, but in technical work the staff are extensions of the manager's brain. The staff must know more than the manager for the manager to be effective in carrying out his group's tasks (and make him look good).

Unfortunately this is not how it works in real life, as managers do tend to feel threatened by smart people. You will find plenty of stories in which the manager did things that clearly demonstrated a lack of knowledge, and impeded the work as a consequence. A good manager need not have all the knowledge, but he needs to trust the knowledge of the staff and use that to make decisions.

In summary, the best managers are the ones that listen, think, and act. The annoying ones do only the latter two, and the worst just act.

As an aside, a big hear hear for The Mythical Man-Month as a great book to recommend to any manager.

--
I'd like to be able to assign to an luser

I've done minor management and I've worked for people who knew more than I did and some that didn't.

One manager I worked for had much less experience than I had in terms of programming, but knew more of the business needs. She would tell me what the customer wanted, I'd give back a technical answer and if she didn't understand, she'd have me explain again until she did. We also had some arguments that would get one written up in other companies. All in all a good working relationship.

Another one didn't have a clue about people, the technical aspects, or anything that related to the job. I suspect she had been hired to axe most of the staff (which happened). All in all, the worst management I ever had

One of my first jobs was with a technically brilliant programmer who was a good manager and mentor, but he didn't have time to do any managing.

When I managed, I preferred hiring people who knew more than I did technically. I was trying to hunt down people to fill some knowledge gaps in the team. That worked well since I spent half my time fighting upper management and shielding my team from bullshit. Though myself and one other person spent a lot of time doing the work that another member should of been doing. ( Long story, I wanted him gone, but I stuck at the time )

My views after all this: People need to be able to work together. I think the manager needs enough tech to know the basics, but they need to be more socially knowledgeable the more people they have to manage. Like most things in life, it's a balance.

André Weil observed a similar principle in mathematics. I have yet to find a subject where this fails to hold true. (Conversely how do you think that first-rate people get to be first rate?)

I am a middle level IT manager - reporting to the IS manager or an organisation - and I have always made it a point to get the best technical people I can working for me. They know more than I ever did about their fields of specialisation - but I know (at least I hope I do) how to get the best out of them, to make sure they are working towards the business goals of the organisation, and that they understand why things are being done (or not done). Can I rebuild a Netware server install? Nope. Can I transfer an Informix database from one machine to another? Nope. Can they run rings around me technically? Sure can.

The Dilbert stereotype of the "pointy haired boss" would be just as incompetent as a manager if he could write Perl code like the best of the people here.

Note: Thanks to dws for pointing out spelung erorz.