How do you get the most value out of a PM who can do everything?

Question

This excellent post by Joel struck home (The gorilla with too many hats), and made me think.

Many project managers started out as individual contributors, and may have strong technical skills in a given domain. In an era of "do less with more", it is tempting for a project manager to step in and "just do" a few tasks for a project.

From the perspective of management, it may be tempting to solve resource gaps by asking the project manager to do some coding, build a quick prototype, perform some research, make some decision, run the project server, serve as a technical backstop for escalations, send newsletters, provide technical support to a customer, help close a sale...

As Joel mentions (and as I keep seeing whenever I read about how the mind works), "interruptions seriously affect performance. A single 30 second interruption can result in a 15 minute work loss." When the project manager serves as the focal point for communication and multiple projects and multiple stakeholders, randomization can end up killing as much of your day as meetings.

How can a project manager identify where they add the most value to their organization, set clear boundaries about what they will do (which is only a subset of what they can do), and protect those boundaries?

Answer 1

I would refer to the PM job definition I really like, which is: "get the job done."

Actually I believe your question can't be answered a single good way. If we think about what project manager should do to use their skills most efficiently we go to an area which is very, very individual.

However referring to a definition I shared above you could easily reduce it to a couple of rules:

• Find people who can deal with specific tasks in a project and delegate those tasks to them.

• If you can't find, or get, anyone who can do some work it belongs to you.

I'd say it works the same with team managers. First thing you're trying (or should be trying) to do is to delegate as much work as possible to other so you have enough time to deal with the work no one besides you can cope with.

Now the whole trick is with defining which is which, but then again that's totally individual. If some coding is what it takes to get the project done, where's the problem? If you have someone who can give you a hand when it comes to do some project management stuff what's the point in rejecting help?

If basic PM's responsibility is get the job done they should use people's strengths and avoid weaknesses even if that means some counterintuitive actions.

Answer 2

Sean, thanks for the great question.

Since writing that blog I've read Peter Taylor's book, the Lazy Project Manager. Reading it inspired me to finally write a blog on the differences between efficiency and effectiveness and of course to do a blog review of Peter's book.

One of the things in Peter's book that just jumped out screaming at me, was the base premise of the book. That of Pareto's 80/20 rule. When 20% of your projects problems cause 80% of your projects work, then focus on that 20%. If you then take this and look at many studies on failed projects, you find one of the key places projects fail is in the beginning. A failure to define the project right, to get the right sign off/buy in, to get the right resources, to get a mutual agreement on what "Done" is, are all major issues raised as the cause of a projects failure.

So like Peter suggests in his book, I advocate a PM focusing on the beginning and the end of project, based on those two areas being where the majority of problems arise.

Best,

Joel

Answer 3

I agree with Pawel that this question doesn't have a single good answer. I want to share some ideas and experience in this situation.

In my company, it's totally like the situation in the blog post. Yes, Project Managers also code code as well as any senior developer.

The reason is simple: my company size is pretty small, so one person needs to be able to do many kinds of work. I think it's reasonable.

Personally, I don't fully agree with "interruptions seriously affect performance. A single 30 second interruption can result in a 15 minute work loss." Yes it is, if that are unplanned interruptions. The PM can set up their time: how much for managing things and how much for other works.

With some people, a little break from tedious duty is necessary to renew ideas. With others, it's unacceptable. So, at the end, I think it's highly dependent on the PM personality to decide which should be done. Often, I see our people defined it by experience, try-and-error: take a little more work, then if you feel that's too much, step back and see what's wrong.

Answer 4

I think it's less asking the question of what should the PM be doing, but more asking what can only the PM do. Assuming that the PM is well-versed in it all, and that he has an equally capable team, then he should focus on those tasks that only he can do, or are his sole responsibility. Part of being a PM is knowing how to delegate.

Answer 5

The first lesson I was taught by my mentor (trained by IBM) when I started my PjM career was:

Project Managers don't do anything; they only manage.

As tempting as it is, the PM has to keep their eye on the ball all the time, and getting distracted by having their own work to do harms their efficiency.

That said, sometimes it's simply more efficient for a well-worn PM to take on some tasks; especially non-engineering tasks, so that the team can concentrate on what they do best.

^{By well-worn, I mean a PM who has experience and has been working with the team for a while, and doesn't have to babysit the project every minute of the day, or continuously fight with PM software to make it behave.}

But, that's only if these are short tasks, so that there's no risk of the PM getting involved in non-PM work for hours (or days) at end.

E.g.: As PM I often dealt with the translators, sending them the originals and formatting the results so that they could be used by the project. I had some Excel macros set up and it would take my 15 minutes a few times a month. (Writing those macros distracted me for days on end; not good PM'ing)

What you do hint to is a variation of the Peter Principle (an employee is promoted based on their success in previous jobs until they reach a level at which they are no longer competent).

Some people need to be promoted for various reasons, but we really want them to continue in the job they do best. Often, the solution is to give them the title but not the actual job. Or, in the case of Team Leader, make them the de jure Team Leader, but de facto have somebody more efficient lead their team.