1) A technical project manager knows when to wait
The hardest thing to do when working with technical problems is to know when to hold'em and know when to fold'em. He knows when to walk...ahem. Sorry, flashback.
It's tempting, especially in what looks like a crisis from one or more angles, to put pressure on the technical team for "answers" or "solutions". However, a good TPM knows from his own experience just how dangerous that kind of pressure can be. It can take a good technical team from overburdened to completely useless and send even experienced problem solvers deep into denial. His own times spent hacking together code on release day or keeping servers up with bailing wire and good intentions allows him to judge when to push and when to sit back and wait.
2) A technical project manager knows when to move
Sometimes waiting for the team to come up with the solution, or for the paperwork to get finished, or for good sense to assert itself is the surest way to failure. There are times when the people and the solutions line up just right, and someone needs to make the decision to move. That person is usually the technical project manager, who draws on a long history of understanding technical systems and the people who work on them to make the right call.
Unfortunately knowing when to wait and when to move is as much an art as it is a science. It comes from being able to read the system, the environment, and the team and combining that information into a view of the tactical situation. Unfortunately, this ability to read the tactical situation does come at the price of occasionally obscuring the TPM's view of the greater picture.
3) A technical project manager can build a technical team
A project manager generally gets decent work out of his team. However, he rarely understands the ins and outs of the technical mindset. He doesn't talk the same way, use language the same way, or have the same deep seated addiction to puzzles and intellectual contests which make technical teams so much fun to work with. A TPM, on the other hand, is a technical person. He honestly cares about things like optimizing code, processor architecture, and the latest developments in the Linux world.
More importantly, the TPM knows what it's like to work as an IT person in today's business world. This knowledge allows him to both help the technical team perform well and to translate the team's needs into language a business people can understand.
In the next few weeks I'm going to explore these concepts a little bit more. I've got some heavy-duty thinking to do about the translation of business interactions into technical direction which, if I can properly articulate it, might actually be useful at some point.