The Velvet Glove
Originally published on FNX Studios Tech Log, May 14th, 2012.
The Velvet Glove
I’ve been asked occasionally by friends and associates what it’s like to be a PM* 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 teamwinning 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.”
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). Maybe you’ve always suspected this, too. 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 actual authority does a PM have to control these? Oftentimes, very little. 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 as a junior PM; “If only these people would stop messing with my project, everything would be perfect!” But, 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.”
Do The Right Nothing
Many PMs get caught up with the process instead of with the people. 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 to work.
Software development 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.
“What’s the Point of this Meeting?”
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.
Some meetings, of course, are necessary—and even beneficial! How do you know? Ask yourself:
Is this meeting for me or for the team?
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, such as a planning session or to whiteboard a problem, usually people will recognize it as productive.
Administrative tasks are the same way. 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.”
A Professional What?
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.
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.
You can probably ignore the rest of the article and still be alright. Seriously. Bring donuts.
*I’m using the term “PM” as a blanket term for various flavors under the project management umbrella for software dev–Program Management, Project Management, Scrum Mastering, etc. There are differences between those roles, but not relevant to this discussion.