What we've got here is a case of premature optimization. You've stated the problem in terms of what you think should be the solution, and if you keep heading in that direction, it will bite your ass.

The real question here isn't "which one can we do without -- the generic manager's skillset or the experienced developer's skillset?" The correct answer to that question is: "neither one." You need both generic management skills and specific domain skills to make any technology project run. The real question you need to answer is, "how do we balance those two skillsets to get the project done?"

Strictly speaking, any generic manager worth a damn should know that, and should already have a solid grasp of the generic management skill called, "listening to the people who actually know what they're talking about." Unfortunately, a lot of generic managers suck at that particular skill, which leads to situations like the one you're in right now.

With regard to the actual business case, the arguments run as follows:

First of all, you're never going to convince a team of high-level professional managers that their skills aren't necessary. You've lost that fight before you even started it, so don't waste your time and antagonize the people making the decisions by pursuing that agenda. You're gonna get a generic manager no matter what you do, so just accept that fact and move on.

Once you accept the fact that you will have a generic manager, you can focus on creating a department structure that uses that manager's skills in the way that's best for the company.

For the sake of a quick lesson in managing your managers, I'm going to stop here and dissect what I've just done. I've re-cast the issue from being a question of whether generic management skills are even necessary (which you're guaranteed to lose) to being a matter of negotiating an allocation of responsibilty that's best for everyone. That simple change guarantees your first win, because managers are negotiation geeks. Their whole mindset makes them unable to resist an idea presented in those terms.

Getting your managers to negotiate at all is your first win. The next job is to win the negotation itself. You do that by showing that making a generic manager responsible for certain issues will be bad for the company, while making a developer responsible for those issues will be good for the company. I'll give you both the strategic and tactical breakdown for how to do that.

Strategically, you need to focus on one key issue: estimation. You want absolute control of the estimation process to be in the hands of a developer, and for that power to include veto power over the two child issues of the estimation process, scheduling and resource allocation.

Your first objective is to establish the fact that bad estimates are bad for the company. There are a couple of simple points to make there.. that bad estimates mean overcommitment of resources, slipped schedules, and the risk of failing to deliver a product at all. Slipped schedules and broken promisees piss off your customers, so nobody wants that. Overcommited resources translate to missed opportunities, becase eventually chasing an opportunity means slipping a schedule or breaking a promise to a customer.

The more advanced argument, which will be harder to sell, is that bad estimates, bad schedules, and bad resource allocation can increase the cost of development by a factor of one hundred. Yes, that's a hundred. A well-managed project can do in four man-days and $1k what a badly managed project will do in one man-year and $100k.

Your managers will choke on that number the first time you present it, but you can back off and establish that bad organization can at least make things take longer and cost more.. maybe not by two orders of magnitude, but by some amount. Then you present the argument that every phase of development:

1. Requirements gathering
2. Design
3. Specification
4. Unit coding & testing
5. Integration & integration testing
6. Post-release debugging

costs roughly twice as much as the phase before it. A problem you fight with for two hours during spec time could be eliminated by an hour of negotiating requirements. The worst and most expensive time to find a problem is at the post-release debug phase, because the problem that could have been handled with an hour of requirements negotiation now takes two programmers four days to fix.. and then you have the cumulative cost of any work that went into the release product which had to be thrown away. The result adds up to a 100:1 difference pretty quickly.

Requirements, design, and specification are the three most cost-effective areas of development. They all tend to require small teams, and they save you from big losses down the line. That frees up your labor to work on other projects, and to catch those opportunities you would have missed if everyone was doing a death march.

Requirements, design, and specification are also the three areas where a generic manager is least qualified to make a definitive judgement. That's why you want the power to make those decisions in the hands of a developer who does know how to get those jobs done.

Now.. tactically, you should handle your negotiation using a technique Barry Boehm (Google the name) developed while working for the DoD, called "win-case negotiation." The idea is to go around your circle of negotiators having everyone state what the condition they need in order to feel that they've won. In most cases, you'll find that a lot of the win conditions are orthogonal to each other.. the developers want control over estimation, while the managers want to be sure there's a good hand on the wheel once the schedule has actually been set. The goal is to establish a solution that allows everyone to feel that they've won what they feel is most important.

Getting down to specifics, you might want to float the idea of a department where the big-picture work -- deciding what's possible, what resources are necessary for any given project, and what schedules are reasonable -- belongs to a developer, or a small team of high-level developers. But the department will also have a small team of generic managers who work for the managing developers, taking care of the strictly management end of running the teams -- budgeting, paperwork, creating teams that gel, motivating and managing egos, managing communication with the rest of the company. The managers would end up 'running' the teams the way your sysads 'run' the computers. They'd maintain things and keep them operating, while not having complete say over what should be done.

One last piece of advice: If you really want to win this, blow a hundred bucks or so and buy copies of:

• Why Does Software Cost So Much?: And Other Puzzles of the Information Age (ISBN: 093263334X), and
• The Deadline: A Novel About Project Management (ISBN: 0932633390)

both written by Tom DeMarco, for every high-level manager you want to convince. Read them, and you'll understand why.