I'll also point out that a technical PM need not even be a developer, necessarily. I've had some PMs who were from an engineering background. They still understand the process and mindset of a developer fairly well, and they are usually confident and experienced enough to not fear when the technical aspects are over their head. They know when to trust their developers and back them up to management, but they can also grasp enough of what's happening technically to keep up and know when to pull in a senior dev or lead dev for planning. Experienced engineers also often make excellent liaisons between technical and non-technical people, just because of the nature of traditional engineering.
BTW, are you familiar with the idea of the "tact filter"? The (very short) article has been around for a couple decades now, but it's still pretty accurate -- though I can't say his explanation for why people have different types of filters is right (or wrong): mit.edu/~jcb/tact.html
I'll also point out that a technical PM need not even be a developer, necessarily. I've had some PMs who were from an engineering background. They still understand the process and mindset of a developer fairly well, and they are usually confident and experienced enough to not fear when the technical aspects are over their head. They know when to trust their developers and back them up to management, but they can also grasp enough of what's happening technically to keep up and know when to pull in a senior dev or lead dev for planning. Experienced engineers also often make excellent liaisons between technical and non-technical people, just because of the nature of traditional engineering.
BTW, are you familiar with the idea of the "tact filter"? The (very short) article has been around for a couple decades now, but it's still pretty accurate -- though I can't say his explanation for why people have different types of filters is right (or wrong):
mit.edu/~jcb/tact.html
I hadn't seen that tact filter idea, but it makes a ton of sense to me.