You can have a completely non-technical PM, I've found, as long as they still get to know their teams, the problem domain, etc... The type of person who proudly

You can have a completely non-technical PM, I've found, as long as they still get to know their teams, the problem domain, etc... The type of person who proudly professes their ignorance of something is not cut out to be a PM. But much of what a PM does is take the bookkeeping off the backs of the developers so they can go to the issue manager and just read what pertains to them. A good programmer should never need to lie to his PM to push-back. Knowing how to put your foot down is an important part of delivering a working product. And a good PM should never need to browbeat or threaten the team. If, for instance, they feel a quick release is essential but the developer feels the product isn't stable (race conditions under customer-levels of load) neither is flat-out wrong. Even with the CEO yelling at the PM yelling at the developer they shouldn't bend - if the developer can't deliver what they been asked for they shouldn't pretend they can. But this tense situation can be solved by working with the developer to clarify requirements. Perhaps a lite-version could be released that was hard-limited below the danger zone, or with a problem feature left out or set to use offline processing to avoid the race conditions.