The Velvet Glove
On Actually being a PM
I’ve been asked occasionally by friends and associates what it’s like to be a PM, specifically in the software development game. Whether it’s a good job, if I think being a PM is a good career path for him or her, etc. I love answering this, because it’s a profession and set of philosophies I’m very passionate about. It can be a really fun and rewarding job—for the right person. You have to feel good about the team winning and be comfortable with personal accomplishments that are less tangible than creating a sculpture or writing a distinct piece of code. There’s a big difference between managing a project and being a PM. You have to feel it in your bones—people can smell it on you if you don’t.
Here are some thoughts and, as we say in the biz, “lessons learned” on actually being a PM.
The Hard Skills Are Easy
The worst-kept secret about being a PM is that the nuts and bolts of the job are important, but pretty easy. The schedule calculations can be done by anyone who isn’t an idiot (and even by a few who are), and it’s even easier if you have good PM software to do it for you. Maybe you’ve always suspected this. Maybe you’ve even asked a PM what his or her job consists of, and he or she told you that it’s managing the “iron triangle” or “triple constraints”:
Scope — what needs to get done
Schedule — when it needs to get done
Budget — how much it will cost
Easy, right? But, how much direct authority does a PM have to control these? Oftentimes, very little.
The Soft Skills Are Hard
Have you ever seen a project go perfectly according to plan? Probably not. If you want to know what being a PM is like, don’t ask him or her what the job description is; ask what is pissing him or her off right now.
PMs can’t make unilateral decisions about any of the three corners of the triangle, even if they are the right ones. In most organizations, PMs don’t have the authority to hire and fire. Decisions are made and overturned by senior leadership, which oftentimes run contrary to the PM’s plans—in the most frustrating cases, this happens without his or her knowledge. The truth is that while the PM position does not have much granted authority, it does have very real accountability for the success of a project.
I struggled with these concepts for a while, way back as a junior PM. “If only these people would stop messing with my project, everything would be perfect!” The epiphany came when I figured out adjusting to these imperfections without negatively affecting the project and the team is the job.
Some PMs want to solve this problem by being granted more authority, as if to wield the iron triangle like a fist. I prefer to be the velvet glove. A good PM doesn’t need to be granted authority to have the power to help ensure a project’s success. As a wise man once said, “power resides where men think it resides.”
People Do The Work
Many PMs get caught up with the process instead of with the people. The schedule isn’t magic. There are best practices, sure, but hammering them down the throats of intelligent people who just want to do their jobs without impediments will hurt your project rather than help it. A project that emphasizes people over process fosters an environment in which it’s fun (or at least tolerable) to work.
Software development, for example, is a creative job. Most of the engineers I know actually love writing code; many of them hate everything else that goes along with it. Constraints like in-your-face deadlines shift an engineer’s focus from the code to the clock, which hampers creativity and can encourage cutting corners. Administrative tasks and meetings are distracting.
People want to get to a state of flow. This means that you, as a PM, need to remove obstacles before they pop up, while not getting in the way yourself. You need to do everything that isn’t the measurable work, so that people who are doing that work aren’t distracted with unimportant minutiae. Learning when to intervene and when to stay out of something is a delicate dance. As god once said (in Futurama), “when you do things right, people won’t be sure you’ve done anything at all.”
If that all sounds too touchy-feely for you cynics out there, just remember this: processes don’t do the work, people do. Happy people do more work, unhappy people do less, or leave.
People Hate Meetings for a Reason
If you’ve worked in an office setting, you’ve been to a boring meeting. This is epidemic. I’ve actually seen people cringe at the sight or mention of a PM because of their association with terrible meetings. If it’s for you, then the team won’t want to be there—they want to be working, not herded into a room to give you status. If the meeting is for the team, where relevant problems are identified and good decisions are made, people will usually recognize it as productive. Administrative tasks are the same. Do you create reports and schedules because you have to, or because it’s useful to the team? When should you involve them? A good PM edict regarding engagement with his or her team can be summed up thusly:
“Everything I do with the team is for the team. Everything I do for myself, I do by myself.”
Certifications are Just Checkboxes
Obtaining your PMP, CSM, or other certification is great for learning about the craft, but it doesn’t make you a good PM, nor will it guarantee you a job—just like creating a perfect project schedule doesn’t mean your project will be on time. Yeah, sure, if you learned something by studying for a test, great, but there’s no direct causal relationship between possessing a certificate and managing a project well.
Here, too, people are the key to success. Build relationships; network. An impressive CV is less important in the hiring process than connections and cultural fit because a PM is a personality driven job. No one chooses to work with the iron fist PM.
Bring Donuts
You can probably ignore the rest of the article and still be alright. Seriously. Bring donuts.
