“The other half of real time I always assert is you have to be in the circuit. The metaphor is that if I’m watching cars drive around a racetrack at 150 miles an hour, I can take a picture of one that was about to spin out …. The problem is I’m sitting up in the stands, I’m not down in the driver’s seat where I can do something about it. Unless you’re in the circuit, even actionable information isn’t real time enough.” The added dimension to SOA, David Rubinstein, Software Development Times, June 2012.

The problem is not that I’m not in the driver’s seat but that the driver is there and trying to do her job. The notion that I need to replace or look over the shoulder of that driver and tell her how to drive is, in my experience, a typical thing we do wrong as project managers.

I talk a lot about immersing ourselves in the project data and action so that we truly understand what is going on, what the data means, and when to take an action. This however doesn’t mean our goal is to have all the information at our fingertips and then be able to tweak everything going on like a puppeteer.

Instead, the insights we gain from immersion are so we can plan, organize, train and equip our team so that they can react and stay on top of the issues. If I find I can’t fix the problems because I can’t get the information fast enough to act on them, then I suspect there is a more fundamental problem that needs to be solved first.

Often, we are not trying to fix the problems so they don’t happen again. Instead, we seem to be trying to set it up so we can quickly fix the same old problems as they happen again. This is a bit backwards. The project manager’s job includes responding to and remedying problems, but the art of good project management is that the project manager rarely has to do just that.

Are you organizing your project so your team can respond appropriately or are you organizing it so you can make all the decisions?

3 thoughts on “Project Managers We Can Get Too Close to The Action And That’s Not Good”

More comments from around the web:

Shekhar Chandra V.V. • Bruce it is an interesting topic. I would say it actually depends upon the project, the size of the same and finally the competencies of the team – once can be hands off provided either the team already has an experience and has the confidence or the Project Manager has developed that kind of expertise in the team.

However as rightly mentioned by you, in most of the cases PM prefers to be involved and loves to be a “Hands On” person

Bruce Benson • Shekhar,

Agreed. The team makes a huge difference and our goal as a PM should be to get to where the team can handle most of the challenges they face. My cautionary note is based upon experience with working with PMs and managers in organizations that are not doing well. I try to remind people to take a look at what they are doing and see if they approach is really appropriate to the situation.

Good feedback, thanks

More comments from around the web:

Thomas Ronholt • As PM I see it as one of my principal functions, to act as a facilitator that enables everyone on the project team to give their best and perform their designated tasks. Take the typical hierarchical triangle, turn it up-side down and you should get the picture! The PM is at the bottom angle of the triangle.

Comments from around the web:

Alejandro Varga Meder • Unfortunately a PM needs to be in the drivers seat, since he is driving the project. That said a good PM will delegate such that he can get the overview of the project without micromanaging.

Bruce Benson • Alejandro,

Before I became a manager (project and line) I was a software developer. Once I started managing the efforts of other developers, I had to recognize that I had to let them do their job, even if I knew I could do it better than they could. I came to realize that I needed to teach/coach/train my folks to do things well — in the way I wanted them to do it — and then let them get to it. I’ve seen too many managers who never made the shift from “doer” to “manager” and didn’t do real well at getting the most out of their team (i.e., projects late, buggy, with poor morale and high turnover) because of over-managing.

I’ve also seen project managers, who’ve never done the job of the individuals they were managing, who felt (and were often told) that they needed to “actively” manage these efforts. I had a boss who while very smart — and had a phenomenal memory — and could “drive” people to do what she wanted them to do, who then drove the projects she “managed” into the ground because she thought her job was to tell everyone what to do (which clearly exceeded her expertise).

So like so many things, we have a balancing act to do. I see the PM as often more the captain of the ship rather than the guy with his hands on wheel and the rudder and the throttle and the loading dock crane and the …. Smaller projects the PM might in fact do many of these things. Larger projects the PM will often need to step back, keep a bigger view, and send out appropriate “big picture” guidance to everyone and ensure they stay on track overall.