How Technical Does a PM Have To Be?

Ever volunteer to speak at a school "career day?" Try this some time if you want to test your presentation skills in front of a demanding audience. These events feature everyone from chefs to cops, all of whom try and explain their job routines to 7th and 8th graders. Trying to engage these kids with a discussion of IT project management can be a tough sell.

My approach was to lead off with a slide showing a firefighter, a baseball umpire, and a symphony conductor. I would then explain how a PM's day was a mix of troubleshooting, coordinating, and mediating. But the conductor, I would add, is the best metaphor for the job. You don't necessarily need to know how to play the violin or the trombone. But you have to make sure everyone is playing the right notes and at the right pace, for starters.

In retrospect, I should have added more to this. The conductor who can grab the bow and nail Shostakovich's Violin Concerto No. 1 is indeed a rarity. There are still certain expectations, however, for the guy who waves the little stick. Conductors need to know the technical terms that the violinist uses (which are different from those of the cellist or trombonist), proper bow and finger placement, perhaps even the application of the Suzuki method and how often to apply bow rosin.

And so it is in the IT world. Never wrote a line of code, set up a server, or designed a user interface? Well you can still be an excellent project manager, even if you've never programmed anything more complex than a VCR. You simply need to have a base level of knowledge that can give you credibility with the team and allow you to make informed decisions.

Your credibility begins with simply getting things done for the project team. If you can successfully escalate issues, drag in needed new resources or information, and smash through bureaucratic logjams, you can win respect from most. But dedication and problem solving is only half the equation. You also need to speak the language of whatever architecture/technology/domain you are working with, know the common issues and risks, understand requirements and design docs, and be able to diagram the workflows and how the pieces fit together.

The depth to which you need to know all this may depend on the size and complexity of your project. In larger projects you'll probably have lead designers and architects to lean on, for example. But the one constant is that you will often need to mediate team debates over technical approaches, and explain to your boss the pros and cons of each angle. You'll have to write cogent minutes and other communications that accurately reflect technical decisions and issues. You'll need to identify when a design approach may have upstream or downstream system impacts (this is crucial, since your team members may only be thinking of their own application realm, not the big picture....that's YOUR job.)

Over time and through osmosis, you may learn just enough to be dangerous.