Let me speak from personal experience first.

The single manager that I felt was most effective in dealing with me did not have a programming background. He was way out of his depth - and knew it. Which motivated him to be really conscientious. Furthermore he knew the audience that I was developing for far better than I possibly could. He had to depend on me to lay out technical alternatives. But he also gave very valuable feedback on exactly what I was weakest in.

The single manager who did the worst with me also did not have a programming background. But his problems were unrelated to that fact. Since I don't want to rant, I'll skip him.

The second-worst manager that I had was previously a programmer. He constantly got into trouble by trying to micromanage and compartmentalize people. He wanted all lines of communication to go through him so that he was always in the loop. Unfortunately this caused constant miscommunication and conflict between people.

So developers are not necessarily better than non-developers at managing developers.

That said, there is no shortage of management traps that are specific to developers. For instance people who are used to dealing with operations are used to having straightforward metrics to measure progress by. How many phone calls were made? How many tonnes of steel were produced? This is easy to track, and there is a fairly straightforward correlation between effort and output. By contrast measuring progress in programming is very hard, and unless management is very careful they will never have a clue about what is really happening. Furthermore there is no simple correlation between effort and output, in fact most programming teams wind up going past the point of diminishing returns.

For a simple concrete example, take the nature of "mental flow". A good portion of what programmers do can only be done when you have reached a state of sustained concentration called "flow". This state takes 15-20 minutes to achieve, and once achieved can be shattered by one off-topic interruption. At the average organization, interruptions come every 10 minutes or so. This keeps people from ever getting to a point where they are productive unless they work when nobody else is around. Which is one reason why programmers like to keep odd hours.

This need is absolutely necessary to successfully program. It is also very difficult for someone to appreciate it if they have never had a job with this need. Two examples of such jobs are management and service. Which, not coincidentally, are the jobs of whoever will wind up in charge, and the background that that person will likely bring to the table.

Facts like these are widely understood by programmers. If I had to start with one reference, it would be Peopleware. * Observers attribute some of Microsoft's success to the fact that their management was very concious of everything that Peopleware said.) You could also recommend something by Steve McConnell like Software Project Survival Guide or Rapid Development. Or grab any of the many other fine books that have been written on managing software projects.

But the story doesn't end there. It is easy for books written by and for programmers to talk about all of the important things which programmers find easy to get right. It is much harder to talk about all of the important things which programmers tend to get wrong. Even reading about that poses a challenge for us. As I brought up in What you refuse to see, is your worst trap, that kind of criticism becomes a challenge to our egos. And those challenges are always hard for us to hear.

Few books that are popular among programmers address that. I'm in the process of reading one that does right now, The Inmates are Running the Asylum by Alan Cooper. (Note: Scanning through the reviews at Amazon, some of the criticism is justified, but most of it seems to me to be the result of developers reacting to perceived criticism...) He talks a lot about the ways in which developers manage to drive the design process towards directions in which developers have an easier life. We naturally gravitate towards interfaces that mirror the hierarchies of the implementation with little thought about whether that will make any sense to the user or address the user's needs. The simple act of overestimating the technical difficulty of taking any other approach makes it hard for anyone else to challenge our control.

Take a look back at my description of the non-technical manager who I worked with best. Look at what I said that he brought to the table. I can see how easily a developer could choose to dismiss what he had to say, and the resulting conflict would have made him ineffective. Luckily I didn't make that choice and things worked out very well. Conversely it is always going to be very hard for a manager who was a developer to bring that perspective to the table.

Hmmm...in the process of writing this post I seem to have come to an opinion on the topic. I think that both technical and non-technical managers can be effective managers for developers. The two groups both face general challenges that have to do with management, and slightly different sets of challenges from the unique demands of software. The specific problems that arise for managers who were developers are going to be less visible to developers because developers share the same blind spots. Conversely managers who weren't developers have challenges that are very visible to the developers that they manage. One of the worst of those challenges is the ease with which the managed developers can choose to subtly (or not so subtly) guarantee the failure of any manager that they don't respect. Often without conciously intending to do so.

With that in mind, I'd say that you can choose to make the business case that you'll guarantee the failure of non-technical managers until you get your way. Or you can instead make the business case that there are a lot of issues which are specific to development, and it is critical that any managers understand some of them.

* I like presenting Peopleware with the factoid that in the early 90's standard practice at Microsoft was that anyone who was promoted to manager was handed a copy of Peopleware, and then was quizzed about it in the halls until they were guaranteed to have read it. Observers attribute some of Microsoft's success to the fact that their management was very concious of everything that Peopleware said.