Leadership

The weaknesses of a technical project manager


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.

18 comments
jsicuran
jsicuran

You need a balance. And as a consulting engineer and PM for over 15 years a technical PM for technical projects is the best of both worlds. He/she can understand the impact of technical based tasks and deliverables, and what is involved behind them to properly manage risk and keep any scope creep at bay. By having that understanding he/she can ward off potential problems across all aspect of the projects, personnel, etc. He/she does not have to be hands on or partake in technical discussions but having the understanding is a key factor. Look at it this way. You can take a newly minted PMI PM for example, they have the PM methodology down but throw them into a construction project and without any experience of ever managing a construction project or working in construction it will not be easy for them. But if that newly minted PM was an architect or construction manager/foreman/tradesman prior, he/she knows what to expect in planning and managing their project from their "technical" background. Or guess what, that newly minted PM with no construction experience, after his/her first construction project gained some "technical" insight for the next construction project.

Paul315
Paul315

Project managers save projects...but technicians save project managers. The duct tape and baling wire thinking the author so decries in technicians is the result of dealing with one penny-pinching, deadlines-uber-alles project manager after another. The guy who said, "After me, the deluge!" was a project manager with a boss to impress.

Paul315
Paul315

Project managers save projects...but technicians save project managers. The duct tape and baling wire thinking the author so decries in technicians is the result dealing with one penny-pinching, deadlines-uber-alles project manager after another. The guy who said, "After me, the deluge!" was a project manager with a boss to impress.

sganapathy
sganapathy

I agree completely with the original post. But can some one advice on how the technical PM can work to overcome these weaknesses he/she has?

Labrat636
Labrat636

Here, all projects are led by a senior "project manager" - this may or may not be the same person for different projects, as it depends on the project's scope. The Senior Project Manager always has his eye on the "big picture" and makes sure that all projects suport the business strategy. The SPM will delagate all technical aspects of the project to the Technical Project Manager (me). Other aspects of the project, such as funding, purchasing of equipment, training, staffing, etc. are distributed among the other project sub-managers. Everyone is responsible for their part of the larger project, and we all depend on each other - communication is very important, of course. All managers, technical or not should have the ability to lead others and provide direction and guidance.

pmaina2000
pmaina2000

As a PM with a strong tech background, my biggest challenge has been how to get my objective without upsetting people in the process. I have realized that *How* I communicate is often much more important than "what" is contained in the message. Upset somebody and it doesn't matter how well reasoned your argument is - you will simply not get the desired results. Having grown accustomed to using "Commands" to get things done on the computer, it takes a while to learn how to build "relationships" - the key to getting things done when it comes to people. It's tough - but I'm working on it...

michael.crocker
michael.crocker

Since I am a technical project manager, I found the comments and replies interesting. Recently on a contract at a small company, the management knew that not every project needed a "Project Manager" (which was a good thing since they only had one full time Project Manager and me). For the smaller, less complex projects, the lead engineer also served as the ?project manager?. A study sometime ago tracked managers at a large company to find out if having a technical background made a difference. While, depending on the function, it was helpful at the first level, as they moved up the ranks, it soon did not play a part in the ability to be a good manager. The same is true with the project manager. If management expects them to ?jump in? and work on a part of the project, then their domain expertise is important. As projects get bigger and more complex, it is the ability to see the whole picture and how all the parts fit together that becomes important. I believe the statements and criticisms relate to the people skills and the ability to resist dropping back into the technical lead role. Every Project Manager should be solution focused. Having a technical background can be helpful working with the stakeholders during the requirements collection and analysis. It can also be a disadvantage if the person wants to jump quickly to a solution or if they substitute how long they think a task should take for the estimates form the team performing the task. The same is true for any project manager, regardless of their area of expertise. Collaboration and communications are the key skills. That includes filtering and content setting so that the message is at the right level of detail and presented in the right way. One of the biggest mistakes of the technical person turned manager is to want to flood management with all the technical details.

jfederline
jfederline

This article is built on stereotypes, take it for what it is worth, since not everyone fits stereotypes. We could pick this thing apart from all directions and play devils advocate, but the plain truth is that some PMs are better than others at certain types of projects. The lesson hidden somewhere in the intent of this article is to be smart enough to hire the right kind for the role.

gshume
gshume

As with the analogy, there are pro's and cons for choosing either a technical or non-technical PM. While it is true that a tech PM will often out perform a non-tech PM in a tech focused roll, the same is often true of a non-tech PM when the situation is reversed. Inside knowledge versus fresh eyes is always a contentious hiring point. While certifications such as PMP show that a PM has core skills, it certainly doesn?t show where their skill set is focused. Only a poor manager would hire a tech PM to manage a culture change project, just as it would be crazy to hire a strategic PM to manage a hardware upgrade project ? it would be like hiring a carpenter to install plumbing, he?s seen it enough to make it work but why would you risk your project when you can get a specialist. Project Management is as diverse as any field of endeavour out there and all you need to do is take a look at the job postings to see that most people want a PM with a specific set of skills or knowledge, be it tech or finance. Just as an organisation needs to match its PM?s to projects, so too do PM?s need to make sure they are selling the appropriate skills for the job. To tech or not to tech, that should be the PM question. So lets take another look at those problems: 1) Environmental Knowledge. If your tech skills are sound then taking them with you isn?t a problem. The basis of IT troubleshooting is being flexible, adaptable and open to that left field thing that always crops up. Hell, they could probably take a Navy Seal with a paper clip and a well written batch file. 2) Solution Focused. If you don?t have a problem to solve, they why do you have a project? True, this isn?t always the case, but lets face it, 99% of the time it is, and most people want it faster and cheaper. Tactical and guerrilla project management is as viable a technique as the next, experience tells you which to use and when. On a more structured path, then many tech PM?s will be well versed in a logical systems approach to finding those elusive problems. 3) Not great communicators. How many times have you been to a meeting where everything under the sun is open for discussion except the things that matter. Communicate when its important rather than filling someone else?s inbox with issues to worry about. Those bits about experience, great team workers and complicated problem solvers should set a tech PM in good stead to work out where the magic line between not enough and way too much is.

geoallen
geoallen

In my experience, technical managers are generally not good at managing people. I appreciated the '"Oh! Shiny!"' reference in the arrticle because that is really a big tendency among technical folks as well as the great unwashed who are directing everything. Managing a technical project requires the skills of a manager, not a techie. Having that technical underpinning is important, but a great level of detail is not critical. Managing well is the point. Trusting the people who are doing the technical work is imperative. Keeping on task, no matter the "shiny objects" is the key to success.

skicat
skicat

I actually had one PM ask me what a switch was and how it worked. I could tell he was embarassed even asking the question (and he should have been).

Wayne M.
Wayne M.

I guess I don't see the purported weaknesses the article attempts to associate with technical project managers. I can only respond one by one. 1) Relying heavily on environmental knowledge I would view this as one of the major strengths and rationales for rely on technical project managers. It is by having intimate knowledge of the work that is being performed that allows the technical manager to be a leader for his staff. Having connections allows the manager to point staff in the right direction, "Go talk to Al, he knows the ins and outs of that system." Without this underlying knowledge, the manager can only observe the staff's difficulties and create reports. Yes, this type of knowledge does not completely transfer between companies, which is why it is advantageous to promote from within, rather than bringing an unknowledgeable outsider. 2) Focusing on solutions rather than problems This seems like word play more than a meaningful description, and in fact the second sentence contradicts the title, "they seek to solve whatever problem is sitting in front of them at the moment." It is the technical understanding of the problems facing the business as well as knowledge of potential solutions that allows the technical project manager to address the big picture. 3) Tend not to communicate about every issue they encounter Poor communications skills are a trait of a poor manager (and a poor employee in general) and are certainly not confined to those who have technical knowledge. If technical people are not communicating the issues they encounter, where is the non-technical project manager getting his information? Technical project managers have a clear advantage over their non-technical counterparts in a technical environment, their technical knowledge. Having technical knowledge, however, does not drive out other managerial skills, it augments them.

MentorCtl
MentorCtl

One of the hardest lessons to learn is that most supervisors (bosses) DO NOT want to hear about problems except to hear: "Solved!" Most problems are not simple "widget was wrong" situations. The quick fix which looks great is rewarded; however, the long-term resolution of the true underlying problems are often seen as unnecessary by the boss (or bosses.) Taking time to examine the full problem is normally not appreciated immediately, if at all. Much preferred is the quick band-aid over the compond fracture, not the bone setting and clean-up required.

prosenjit11
prosenjit11

It is important for the Management to have a detailed picture sometimes. No matter they are busy with their schedules on meeeting the revenue targets of the organisation. Getting the Business rolling and lay the Road Map for the next Financial Year. But sometimes, if the detailed information is missed out a point to point picture is depicted it could be that the entire history is missed out. This could result in blunders and no matter the Entire Technical Staff has worked on different tests and trying to come to a solution, the root cause would be ignored. There are two types of communication while performing the task. First is to whom you are addressing and why. Second what is the root cause and what is it to be delivered, is it a document, a report, a detailed mail or one line sentence. The priority and the timing is important here.

Wayne M.
Wayne M.

There seems to be some sort of implicit assumption going on that a technical project manager is some how deficient relative to a non-technical project manager. I fail to see why a technical project manager would do worse than a non-technical project manager when faced with a non-technical effort. Some how people coming up from financial or marketing backgrounds do no face this prejudice. No one would say that financial project manager is worse suited for a non-financial effort than any other type of project manager. If I were introducing a culture change in a technical organization, I would look first for a technical project manager within the organization to lead it. In this environment, the technical project manager has the base line knowledge and understand to explain and lead the change. In fact, it would take an exceptional non-technical project manager to do as well. Having technical skills and knowledge do not drive out other managerial skills. There are managers from all backgrounds who communicate poorly and lead poorly. There is nothing unique about a technical project manager in this regard.

Wayne M.
Wayne M.

Even a technical project manager will not be able to keep up with changes in technology, even the technical staff will probably not be conversant with technologies outside their current field of work. So never be afraid to admit that you do not know something. That is the first step to learning something new. Trying to fake the knowledge inevitably leads to disaster.

jreavila
jreavila

I'm what here is call a Technical PM, and can tell you that what is pointed here as "weaknesses", I see as oportunities. Let me explain it. 1. Relying . . . Well, when you face a non-technical issue, you are kind of lost, and find a solution, will be in the first place, a little bit frustrating, 'cause you are used to have all the answers, and second, will take you more time to solve than it takes to a non-technical Pm. 2. Focusing . . . To see the whole forest and not the tree was a hard learned leasson, and I'm not talking about technical issues, I'm talking about budget, voice of the customer, legal issues, stake holders, etc. 3. Tend not to . . . When I learn to make a communication plan, it was clear that communicate is not an easy thing, and for engineers, it is harder. Now I understand that what needs to be communicated is not always what I think should be communicated, there are other needs that have to be covered in order to have a healthy communication in a project. This is not the word of God, it is just my experienece, holpe it helps as a bit of someone else's view.

prosenjit11
prosenjit11

A real time situation is what is described and is a real life experience wherein a temporary fix could be just a momentary relief meeting the project delivery or the sales targets. But, this could be a big disaster if the product is shipped with a workaround and then the cumulative effect of the Bug with a workaround starts backfiring. A situation of this nature is dangerous and could result in terrible impacts on the future development and reputation of the company. A mistake could always be pointed out but if not been worked on with the root cause analysis would sound like inviting Pearl Harbour. It is important to sound it to your immediate Boss even if it is refuted and he feels it to be quite irrelevant to the existing circumstances. Honesty and experience counts no matter one could loose his reputation and be marked A Late Comer.