Dion Almaer

Software, Development, Products

Project Management

Project Managers Are Underrated

Leave a Comment


I just overheard an engineer teasing a buddy about being a project manager.

“Work should be done in small teams. There is no need for a project manager if you get that right.”

I have often heard this, and I feel bad because it shows that many people haven’t experienced the liberation that an amazing project manager brings to a team.

I get understand why you may not have worked with one, as they are incredibly hard to find. They fall into the hot masseuse paradox.

A rather sexist older man once explain this problem:

“Everyone wants to get a massage from someone smoking hot of the gender they are attracted too. Have you noticed how hard they are to find? I have a theory: if you are hot, you have probably worked it out that you don’t need to do that job!”

He then went on to more detail of hands touching his sweaty hairy body, but let’s leave it there.

The analogy has many flaws, but bringing it back to roles such as project management, often if you have the skills to be a great project manager you could also be a great engineer.

Great project managers are problem solvers. The problems can revolve around implementation issues, but they also include social and organizational problems. Those can often be more nuanced and trickier. People are weird.

What do you need in a Project Manager?

The title Project Manager is awful isn’t it? You aren’t going to just focus on projects, and the manager piece gets people into trouble.

You have ever seen tension between some of the roles? Let’s say you have actors such as a product manager, engineering manager, and the project manager. Who is responsible for resourcing? If an effort isn’t working well who is handling what?

Let’s say that our organization has a functional hierarchy (people report to others who understand their function):

  • The product manager is responsible for business outcomes (e.g. how are we doing against KPIs vs. how is software product delivery going right now)
  • The engineering manager is responsible for the delivery of the engineers on an effort. Engineers actually report to them and thus they are also charged with growing the careers and craft of the engineers, which creates a different dynamic
  • The project manager is responsible for unblocking the team and making sure they are as productive as possible.

If issues pop up it is natural for there to be tension between some of the roles and it is incumbent for all actors to listen to each other and accept input, whilst also understanding who has the final responsibility.

With agile approaches and some pushing away from strict projects, some pushed for a new name for the role, including Scrum Master, which is even worse.

Not only is the term very proprietary, but I have seen many use it as a way to lose their way on what the job actually is.

Let me put it in a form that may be familiar to the certified scrum master. The following is an invalid user story:

“As a scrum master my only real job is to run the daily stand-ups with an iron fist so as I can feel like I am adding value”

Have you seen this before? These people stop interesting conversations because of some dogma on time. They keep things moving irregardless of the context. For the kicker, they don’t share what they are doing with the scrum (as they don’t do things).

You will sense a great project manager when it comes around to them and they talk about work product:

“Frank and Jill were blocked by a misconfigured firewall. I went over to ops and kept pushing until the issue was fixed. I personally verified that everything was working well before bringing it back to the team”

or:

“I heard that the authentication team was finishing a sprint that had a chance to the tokenization. I met with the team, helped document the changes and created a PR with changes needed on our side. The tests seem to be running but I would love another set of eyes.”

or:

“[insert team that we are dependent on] had some problems and had to change course. I sat down with them to make sure that we could accelerate the mock environment so we could at least keep working against an endpoint while waiting for something more real to integrate in the future. I am concerned against hitting mocks but we made sure that they were running their tests against these and I will update the teams when I see something becoming real.”

Anyone can run the scrum meeting. That isn’t your value. Unblocking the team is what matters.

One simple way to get a pulse on how good a project manager is, is to ask them team “if Lindsey wasn’t here, how would you feel?” The team will start to panic a bit if they are really good 😉

In silicon valley startup culture people often think like the person I overhead in the cafe, that we should just keep teams small and not bother with a PjM. That can work for awhile. I tend to over index on hiring the concrete do-ers (engineers to sling code, visual designers to paint pixels) and pushing them to wear other hats (not that I don’t think the other roles are vital, or that “any engineer can do the job of an expert in another field).

I have also seen there be a small percentage of project managers and having them spread too thin. I would rather dedicate a project manager to one complex problem vs. have them context switching and just running scrums for four different teams.

Helping the team run efficiently is important, and the Project Manager can act as a Switzerland between the various roles. If you have worked on larger efforts that transcend one small team though you see how a great project manager can be the glue, connecting the right people at the right time, and solving issues themselves where possible.

I raise a glass to the indispensable project managers that I have worked with over the years. To those who haven’t memorized dogma, but rather understand the why, and how the context of a particular team or problem requires divergence from the text book.

Others in the series:

The right thing to do, is the right thing to do.