Are PMs normally hated?

Question

I have had limited exposure to PMs, and the last one who was in her 60s used to always refer to her previous experiences with: "At the end of the project, I was the most hated person, but the project got done."

She was a very experienced having done two SAP implementation, and many projects in the banking industry. She also mentioned that after a big project she'd leave on a good severance package until the next project.

I am planning on moving more towards a PM role and currently as a tech lead my experience has been very positive maintaining very good relationships with other devs. I don't really want to lose that. Does it mean that moving towards a PM role will create more antagonisms with other devs? I've read parts of the Guide to the PMBOK, and the CompTIA Project+ manuals, but nowhere are mentioned the emerge of adverse relationships.

Does becoming a PM mean that I will deteriorate my relationships with other devs, or am I drawing too much from one person?

Answer 1

People Who Add Real Value Aren't Hated

Good project managers are generally liked by the team as a whole, and by the organization in general. This is not only because they get things done, but because they act as facilitators for communications between parts of the organization such as stakeholders, management, and the development team.

In addition, the best project managers aren't just paper-pushers. They foster teamwork and cooperation, champion process change within the organization, and remove impediments that negatively impact those associated with a project.

Avoid Being Hated By...

1. Valuing individuals and interactions over processes and tools.
2. Ensuring that stakeholders and developers are educated about the project management process, and are able to see how it benefits them.
3. Not treating the development team as fungible resources, or stakeholders as obstructions or obstacles.
4. Making your methodology and its metrics both honest and transparent. This includes process failures, too!

People tend to act in their own self-interest. Projects where the management process is in the self-interest of the participants leads to engagement and appreciation; projects where the process leads to disenfranchisement or depersonalization may still be technical successes, but will inevitably be culturally toxic to the organization.

Answer 2

I don't believe that PM's are normally hated; I can't cite any evidence to support that notion. PMI has lots of evidence that indicates that strong PM practices are associated with successful projects, and all other things being equal, people prefer to work on successful projects than on failures.

I admired the good PM's I worked for even before I knew what a PM was. I worked with a couple of very effective PM's. When I started studying the PMBOK (et. al.), I recognized why they were effective, and why I was glad to have them on the project.

You can be effective as a PM by being a jerk. I'd argue that you're more likely to be an effective PM if you aren't a jerk - if you communicate to your project team the value you bring.

Of course it is possible that the dev's are going to hate anyone who isn't a dev; there are devs who believe that all non-coders are subhuman. Nothing you can do about that.

Answer 3

Yes, ignore her. There is no reason to be hated after a project. Mutual trust and respect are what you are aiming for.

That's the thing about the limitations of using experience to try to determine how good someone was. The worst of the worst will have experience.

Answer 4

While I agree with David and Mark that trust and respect should characterize the team's attitude toward you, must warn you that by becoming a PM you will gain more visibility; you will be judged more severely - such is human nature, as always, it's "Us vs. Them" and "we" get some slack while "they" are censured for the same mistakes.

Fortunately, as a technical lead you're at least as competent as your developers; don't let the margin of competence erode until your professionalism as a PM becomes the source of respect of your colleagues.

As for the lady whose experience you cite, she may have a point. Not about "hatred" since this is a feeling engendered by lack of leadership and "slave driver" management, but about putting the project to the forefront of your priorities - getting it to completion may involve stepping on a few egos, for sure...

What is more, you have to learn from her experience - was she fair or arbitrary? Did she practice what she preached? What negative personal traits did she have? etc. etc.

Answer 5

There is a chance of deterioration of relationships with other developers if you are now 'managing' the work of the same developers whom you have had earlier 'lead' as a technical lead. It also depends on your current relationship with the team and how they perceive you now as a 'manager' and they will now compare you with your earlier role as a technical lead.

But imagine if you were asked to manage a project with a completely new set of people, then it all depends on you on how you bring all the people in the project to work cohesively as a team. There could be some team members (for e.g. enterprise architects) who will have more experience than you and will be needed to report status to you as you are the project manager.

So it (project management) all boils down to how to manage various stakeholders to work towards a common goal (the project) and your skills of managing technology might not be something you can completely count on when you are a project manager.

So, yes, in some cases you will be required to act tough with some team members to keep them from jeopardizing the project and this will definitely deteriorate relationships with those people. But please also note that these instances will be few. A good project manager will also need to act in a transactional mode and should not permanently burn bridges.

A successful manager will ensure that his team does not have any roadblocks in doing their tasks and will step in to make sure that the project is successfully completed with the required quality, in the time planned and does not go over budget. A successful manager will manage risks very well and sometimes will be almost invisible to the team.

Answer 6

Adding to the arguments already mentioned by others, I think this depends on several factors and overall — organizational culture has a significant impact on how PMs are perceived.

There are places where it's "more OK" to be against the Project Manager than elsewhere (it's that guy who's poking his nose into everything — from one point of view). By the same token, an organization might have capacity problems, the tendency towards 100% utilization (effectiveness myth) — expect the relations between you and the team to be more tense over there.

Then, there are projects where out of the three — goal, team, individual — you absolutely must put more pressure on the former (or so it seems).

With time, everything seems to be like a tool, even the way you build the relationships with your team members (makes one feel uncomfortable?). You learn to adapt to the specific purpose and context.

Answer 7

I can say in one phrase why I don't hate, but am skeptical of certain PMs:

lack of domain knowledge

It's easier to sound to management like you know what you're talking about than it is to know what you're talking about. It's easier to use management as a bludgeoning tool than to listen to your teams and remove obstacles to their success.

To avoid being hated...

• Learn, learn, learn till your head hurts. Get reading recommendations from the teams, and then read them.
• Go to their meetings, listen, take notes.
• Know the bug tracking and version control systems inside and out. Look at them daily. Learn them better than the team members do. Get the access needed to check out code and look at it yourself if possible.
• Have the courage to be the reality check on the expectations of non-technical upstream decisionmakers.
• Understand both worlds enough to be able to translate high-level goals into concrete, measurable targets. If a high-level goal is vague or incomprehensible have the guts to politely but firmly keep asking for a clarification until it is articulated precisely enough to be actionable.
• Keep management overhead as small a part of your teams' lives as you humanly can so they can spend as much of their time as possible doing the specialized tasks they were hired to do.
• Read Joel on Software
• To the extent you have influence on who does what, and to the extent that external constraints permit, try know what each team member loves to do most, and try to match them up with it. Free boost in performance and morale.
• Never, ever, act like you know something you don't. Say "I don't know" and then find out. If you need to make a guess, state that you are making a guess. Make it safe for others, above or below you in the food chain, to admit ignorance.

Answer 8

In my experience project managers are disliked if they get in the way of what developers are trying to accomplish. Trust good developers to do their work without any micro-management, and ensure they understand why taking their time on seemingly useless tasks is truly important, and ultimately good for them. For example: understanding the status of the project requires taking time from development efforts, but explain why project visibility is critical to a project's success.