Ode to Project Managers
A lot of time, management can just get a bad rap, specifically project & product managers. If you're a developer or designer for tech stuff, your vitriol will often be pointed towards the project/product managers. I think a lot of this has to do with:
- Often the underlings feel like the overlings "get in their way"
- Often the underlings feel as though they are out of the loop, and have arbitrary constraints, deadlines and requirements thrust upon them
- Often the underlings feel as though the flow of information is one-way
- Often the underlings come to view their product as "theirs" instead of part of a cohesive whole... and many project managers inadvertently encourage such thinking
- Good project managers often are not intrusive to the various teams as a whole, and are only noticed through their absence, and therefore often aren't appreciated in the moment. You get a lot of people saying "I could do that", and often times its true, they could, just not nearly as well.
- To the underlings, managers often aren't perceived as adding "direct value" to the project... they aren't contributing code, or graphics, and therefore are a "luxury"
Of course there are a whole lot more, and if you've been doing tech stuff for awhile chances are you've been involved with a project manager who is all of the above and more. Most of us have been exposed to "the poller" PM (my personal favorite), who views their job as constantly polling the various teams or individuals and updating their spreadsheet to give to their boss. As long as everyone says their stuff is fine, or is "on schedule" they're good to go. Or the ones who are insecure about their own knowledge of what they're managing, and either dismiss their underling's advice altogether or (equally as bad) are afraid to take issue with what they're being told by their underlings so as not to appear ignorant.
If you are a designer/developer trading up from smaller, more cohesive groups, to larger development paradigms... having to reorient yourself to the new paradigm can be difficult, and feel very restrictive. Then again, if you're trading up from a small shop, even having something like lead developers could through you a bit off course.
But here's the thing- a good project/product manager is worth their weight in gold to a project/product. Some would take issue with that- the "luxury" crowd, so I won't say they're absolutely required to have a successful project: but I've come to the conclusion that having one makes it that much more likely. To throw around buzzwords, they're a catalyst for success.
- They keep the right & left hand in sync.
A lot of people don't realize just how easy it is for disparate groups to get out of sync, or how much effort you save by catching potential issues early. Often you won't notice this except through its absence, when you go "I wish we would have known..." or "In hindsight..." or my favorite, "Well, if I'd have known, I wouldn't have..." - They run interference
They're often a groups' buffer between other groups (including upper management), letting them get their work done more efficiently and doing what they excel at. When marketing calls a developer and says "Our competitor is doing this, how long till we can have it?" the developer gets thrown wildly off course from their current task. An answer to a question like that isn't something you just throw out to the wild without thought, backgrounding, and knowing the implications to the project as a whole. - They're the grease on the rails.
Some of this goes back to the left and right hand, but not all. Often a good PM is faced with "we might have a problem here" issues, which they take care of instead of the initial findee. A decision is going to have to be made there, and in order to make a good decision one has to educate onself on the possible ramifications, and often a PM is going to be in the best position to grease the rails for the project to get out the door.
People often don't fully appreciate how much interpersonal problems can cause problems within a group: an example would be a prima-donna developer or designer. This can very, very quickly eat away at efficiency and morale at a frightening rate. Beyond the time wasted bitching and illy feelings, these can start to have a real tangible effect on the project: IE, one developer not doing something because they don't want to make the jerk's life easier. Good PM's catch onto these things really quick, and lift the burden of the burgeoning mob (the rest of the group) of dealing with the situation. - They often are an instant spreadsheet
This ties into the one above- but the best ones often have an uncanny birds-eye view of the project that won't be available to others who are focused on their specific tasks. They juggle many disparate variables and have an affinity for finding relationships between them, seeing where they interact.
Sure, its great to have this on paper- but the best PM's know what the paper really means. They end up becoming the project oracle, in a good way. "If I do this, will something bad happen?" You'd be surprised how often in groups where, if that question gets asked, it becomes a huge process to find the answer. A good PM can usually do the math in a small fraction of the time, simply by juggling the project variables in their head. If you live in fear of your PM being hit by a bus, chances are they are doing something really, really right or really, really wrong. But probably the former. - They speak multiple languages
Wildly disparate groups often don't understand each other, even though theoretically their goals should be the same: getting the project out the door. They use a different vocabularies, and often just think in completely different ways. They could be telling each other the exact same thing, but believe the other side just isn't getting it- simply because the information hasn't been presented in a way the other side can grok.
Try it- throw a marketing person and a developer into a room and see what happens. Unless they're exceptional individuals, you'll often deer-in-headlights-stares until they're gratefully let out of the room, or worse yet you'll have to pay a pricey cleaning service to get the blood out of the carpet. - They balance disparate goals
Fiefdoms just suck from the standpoint of actually getting something out the door. They're normal by and large, we're territorial by nature, so there's nothing necessarily wrong with it, its just often a detriment instead of being directed into a positive.
Two teams (lets say the designers and developers) may both have wholly independent goals in regards to a project: a good PM is able to see where those goals align, and where they don't, and where the different responsibilities are going to lie in order to accomplish the goals most efficiently. If left up to each camp, responsibilities are often adopted inappropriately when they could be done more efficiently by the other, or pushed off inappropriately.
A good PM is able to get past what each of the groups are saying, and actually getting down to what people want, and then figuring out how to align those goals. In usability this would be making sure each group's flow has minimal disruption due to the other. - They understand delegation
Often when looking at the org chart, its tempting to say "You know, we really don't need someone who's position is devoted towards simply making everything run", or a designer/developer will say "You know, I could do that"... and they shift some of the PM responsibilities onto the lead developer/designer. This works for awhile, until the lead realizes they're spend more and more of their time doing PM work, and less and less of their time actually being what a lead developer/designer is supposed to be doing... and one of the other designers/developers eventually either has to adopt those roles or they are lost. Inefficient as hell.
A good PM understands delegation- if thought of in a military sense, the PM is the general, with lieutenants in each of the camps. They don't micromanage, and aren't a checklist for every single question: They're a catalyst for success, just as a lead designer or developer is once a group has reached a certain point. They understand that having all the groups working as symbiotically as possible is going to bring the highest chance of success to the project, and culling a system of delegation is part of that. - Good PM's are cautious sponges
They absorb everything told to them from all sides, but filter it for truth & context. It's a scary PM who believes everything told to them by a developer or designer, or everything told to them by marketing. At some point you've probably encountered one: they're regurgitating a whole lot of information, but they don't seem to understand how it all is connecting.
Good PM's seem to understand when they need more information in order to make an informed decision, where to get that information from- and then they make up their own mind with all the information available to them. They don't, for instance, simply ask their lead developer "what do you think we should do?" and go with it. They ask their lead developer what they need to know to get to the heart of the matter, combine it with all other applicable information that the lead developer doesn't/shouldn't have access to, and make their own informed decision. - They're pro-active, not reactionary
This is just one of the aspects I've noticed about a good PM. From a bean-counter POV, its often very easy to say "If the user/customer isn't bitching, there's no problem", which is reactionary. They wait until they have a real problem to try to fix it, rather than trying to head it off before it becomes something that "has to be fixed". They're good at prioritizing problems, which also ties into into dealing with the various groups. - They bring a unified vision
Every project has to have real, concrete goals, and a real, concrete vision of where the project is going. It's often going to be the PM who shapes these aspects through their lieutenants: if it's not them, the fiefdom problem sets in, with each group having a different vision both in how they relate to the other groups and the project at hand, and how their piece fits into the puzzle as a whole. The PM's ideally create and disseminate the big picture.
This goes beyond being a "product GPS", this is about defining the real goals of the project, and communicating those and making sure they're being met- not just making sure bullet-point features are being checked off.
Another area where a lot of people fall down in is that they'll see the above list and go "Oh, I have that". And they might- I can recognize a few of them in myself, but a whole lot of others where I'm lacking.. especially in scale & scope. (Note to brain: this might be one of the core problems... a lot of people have these abilities within their own domain, but they fall down when scaled up)
But its very rare for a person to be very, very good at all of them. Especially in scale and scope- and when you've left the domain of your particular knowledge base & skillset. And perhaps it's why very, very good PM's seem to be so rare.
You also have a problem where being very, very good at one of the things I've mentioned above requires high marks in several different categories due to how they interrelate, or have dependancies upon one another.
If you're good at a few of them, you're probably better suited for a lieutenant role, not a PM. You might qualify in a pinch, as I and others have in a pinch, but you're going to have a real hard time excelling at it, and an even harder time being happy while you do it.
I'm actually writing a lot of this out to try to wrap my head around the problem, due to some issues I'm being faced with. I know the above list isn't all-encompassing, but hopefully it's a start.
Posted by drunkenbatmanDecember 24, 2003, at 11:33 PM
