Technical project managers come, by and large, from a “technical” background.  In IT that means they were system administrators, network operators, analysts, or programmers who by effort and communications skill clawed their way up to leading teams or projects.  In the process they learned a great deal about how IT teams work, how to keep them moving, and how to stay on target though even the most complicated projects.

This background allows the technical project manager to deal easily with IT teams.  It also means that they suffer from the same kinds of weaknesses as a technical person, including:

1) Relying heavily on environmental knowledge

A technician relies both on his technical knowledge and his knowledge of how an specific environment works in order to resolve issues in a timely fashion.  He knows what workarounds will get the user back in operation, where the bailing wire and duct tape are likely to come apart, and who has the magic USB drive with the banned but highly effective utilities.  

A technical project manager uses the same approach.  He knows the technical systems inside and out, he helped to write the company standards, and his friends wrote the systems which support everything he didn’t make himself.   When a technical problem comes up on a project, help is just a phone call away.

Unfortunately, this knowledge does not transfer from one company to another.

2) Focusing on solutions rather than problems

IT people are, as a rule, solution-oriented.  That’s not to say that they come up with the right solution, or address the correct business problem, but rather that they seek to solve whatever problem is sitting in front of them at the moment.  This tactical approach serves a help desk analyst or a network operations technician very well, as it allows them to get though the day without screaming.

However, the same tendency in a technical project manager leads to missed deadlines and eventual project melt-down.  A project manager, technical or otherwise, needs to keep his eyes on the bigger picture.  Giving in to the “oh, shiny!” problem-solving mentality reinforced and supported by IT culture does not allow him to plan his team’s work tomorrow, or next week.

3) Tend not to communicate about every issue they encounter 

One of the first things a technician learns on the job is that, for the most part, no one really wants to know what’s wrong.  What they want to hear is that the problem is both under control and will be resolved soon.  Generally, the people suffering from the problem do not even know what the problem really is; they just describe a handful of the symptoms and the technician has to wrestle with the “reality of the situation.” This makes IT people a closed-lipped and somewhat surly lot at times.

This tendency, unfortunately, bleeds into the approach technical project managers take.  They rarely share with executives or peers everything which goes wrong.  Instead, they handle what they can, minimize what they cannot, and pass on only the really ugly bits.  This leads people who expect them to act like standard project managers to become first concerned, then deeply troubled, and eventually enraged by the technical project managers tendency to “go rogue.”

I’ll explore strengths next time; technical project managers are not the same as their more communications-oriented cousins.