The way I've addressed this issue of technical and non-technical managers is to try to champion Brooks' The Mythical Man-Month. Despite the age of the book, his conclusions are as amazingly relevant to coding today as they were when he wrote them.
in reply to Re^2: Why Perl is a Valid Choice
in thread Why Perl is a Valid Choice
The bit that I've pulled out and harped on is that there should be two advancement paths within a technical department: project manager and technical manager. Both need to be equal paths, and people with equal experience and skill in each need to be treated equally in the company (authority, pay, etc.). Each significant project should have both a project manager and a technical manager assigned and they work together, each focusing on their expertise.
This has been very successful in our shop. We have several people who are certified project managers and do their job very well. They handle allocations, schedules, and dealing with stakeholders. I work as a technical manager where I keep my hands out of the project management software and make sure the technical challenges of the project are taken care of. I know about other projects going on, I help with code reviews, and I make sure coders know about all of our shared code and best practices.
You can't get this to work everywhere, but I feel rewarded for plugging away until we tried it. And the success has kept it going. The project managers really like having someone on the project whose job it is to know the technical bits. And I feel my time is better spent away from Gantt charts.
As for you other point, I thought about working this into something that we could share somewhere else. I just wanted to vet it through perlmonks first. I'm in The Perl Foundation, so maybe I can ask about throwing up a page on the TPF site somewhere.