Today I want to tackle a couple of typical questions I hear about what a great PM needs to be (or not) and do.
1) Does a PM in a technical environment need to be “technical” themselves?
2) Does a PM need to be a charismatic leader? (Or what DOES it mean for a PM to be a “leader”?)
On item #1 – here’s one of the executive quotes from yesterday’s post: From a VP of Engineering: “She commands the teams’ respect across functions: she is respected for her knowledge of customers and our system and is proactive on cross-functional issues such as deployment that can cause big problems after delivery. She is also a vocal “teacher” about how to do it right which helps bring our developers up to speed (and they accept her knowledge, even about “dreaded process”, because she’s respected.)”
I knew this PM. She was “technical”. She was a software developer by background. She was not, however, writing code on her projects at this point. But she WAS perceived as suitably “in the trenches” in key areas in terms of value-add coordination and problem avoidance.
She knew from her development experience, and what she had learned managing projects or pieces of projects, where the particular problems were hiding for this company’s type of projects. She knew what to ask, she knew what the design reviews should cover, she knew what kinds of things might get left out of specs, she knew what integration testing should look like. (This was one of her interesting strengths – she was an integration testing goddess- test strategy, preparation, coordinating fixes). By the time I met her, she was not handling all the very detailed aspects of roles such as integration coordination herself. But boy she new how to work over the plans and stay on top of the status in a way that was MEANINGFUL to her teams.. She was not asking for “what is your percent complete”. She knew how to ask about progress and judge what was really going on, in a way that helped find problems others might not have seen yet, and ultimately help avoid or fix issues. Contrary to being seen as a meddling micro-manager, she was counted on to be a great extra set of eyes. She was trusted, sought after, counted on. And remember – she was NOT considered a developer anymore. She was thought of as a project manager. But her knowledge base and how she used it was a key source of her PM credibility.
I experienced this unexpectedly myself teaching a project management basics workshop to 120 engineers. The room was split roughly equally into 3 types of people: individual contributors whose bosses thought or who thought themselves that getting some PM basics would be a good skill set addition; engineers managing projects part time and/or occasionally with having a PM title; and actual full time titled PMs. I did my thing, covered practical use of PM techniques on technical projects, wove in stories from my tech project experience about particular scheduling challenges, risks etc., all very real-world examples of typical tech project issues, nuances, layered on top of the basic PM tools. After the class, one of the people who came up to talk to me said this: “My boss suggested I come to this and I was skeptical about all this stuff. But as soon as I heard a couple of your stories I knew it would be OK. You’ve obviously been there, done that, used PM in the real technical world.” I found that very interesting – it was like he was almost *suspicious* of PM until he got some real-world indication of credibility.
I actually think that’s fairy common – the people on our teams DO look for domain credibility in their PMs. After all, they spend their days in the domain – IT apps, embedded system development, biotech, whatever. Why would we expect them to be happy about being instructed, monitored, coordinated by someone who doesn’t understand the world and the details and the issues they deal with everyday?
One last story about being technical or not as a PM. A friend of mine is an IT director at a major computer company. He has a phrase “I have no use for content-free project managers”. He has a group of 300 developers and works with project managers both inside his group and outside. His pet peeve is “project managers who come and say things like ‘the schedule says you’re supposed to be 40% complete by now but you marked your task 35% complete. When are you going to be back on track?'” In his mind, that project manager is doing no one any constructive good – and they get a reputation as being paper pushing status person. Even if someone else in the company has set that poor project manager up in a status-reporting-only role, that PM has lost all credibility with this pretty influential IT director. My friend stated further that he ends up with a real staffing and resourcing problem with content-free PMs. “We have to attend intense planning meetings where we’re mapping out releases that touch 30 different systems. We’re trying to budget and coordinate and plan releases that make sense. Sometimes the architecture and interrelatedness of these systems dictates what can and can’t be put together into a release. If my PM doesn’t understand at least enough about the systems to understand and speak up about potential mismatches, release plans that wouldn’t make sense, then I have to put TWO people in that 4 hour planning meeting, the PM to understand the schedule aspects, and someone else to cover the “release plan sanity check” stuff. I don’t have 2 people!” Now, you may argue that a company should expect to put 2 people in, and big companies have the different roles like architect or systems engineer to do it. But this guy IS in a big company, and he’s saying that with staffing the way it is, even his big company is not staffed to do that. (Ha! I smell an opporunity for PMs to differentiate themselves (more on that tomorrow when i talk careers).
Now – does all this mean you can’t be a great project manager if you’re not an engineer? NO, in my opinion. I think the key is not necessarily exactly what type or how much or even whether you’ve personally done technical design of x, y, or z type systems etc. It’s whether you understand enough about the particular kind of development, or systems, or customer applications, or whatever, to understand the team’s issues- an truly able to help ward off problems without them spoon-feeding you information. Like my IT friend says: “Content free project management is not welcome here.” – because it’s not efficient and it’s not value-add (enough, anyway). And the key is, you DON”T have to have done every type of development to be able to MAKE these kinds of deeper contributions. I know this from experience. All of my direct development experience was embedded systems hardware and firmware and some software. But since my direct development days, I’ve managed projects or consulted on things ranging from IT data warehouse projects to medical devices to software games to websites to factory automation equipment to biotech drug development and launch. Each time I had to learn new things, lots of new details about where the risks hide for this of development, or what reasonable estimates are for this kind of work, or what testing is needed or what regulatory issues there are. But the fact is, my understanding of basic development lifecycles and project management principles, and my desire to learn, and my willingness to get on top of enough detail for a particular industry, and add some value to a new type of team, were enough. That means (good news), I truly do believe you can be a ‘technical enough’ PM even if you were never even a developer yourself. It’s all in where you put your attention to add value to your team’s work.
On to a few words on the charismatic leadership aspect. The PM in the first example – highly respected – was very interestingly, NOT a charismatic leader. She actually totally hated “doing the leader thing” as she put it, in terms of what she thought that was supposed to be. You know, rah-rah on the project, standing up in front of her team, keeping them motivated. She was a more quiet person, not an extrovert in terms of being highly verbal and liking to speak in front of people. Quite the opposite. However, watching her in action, I felt she led by “leading the way” in a very effective, on-the-ground credible manner. Everything she said and did with the team was aimed at getting the project requirements right…. watching out for pitfalls in the develpment…. keeping people in sync technically and cross-functionally (sometimes simply by having the right conversations with functional managers, sometimes by working the issues herself.) She relentlessly led the team forward by doing doing doing and demonstrating the right things to do just by what she focused on, prodded for issues, asked hard questions about. She eventually realized that when the team needed some emotional uplift during tense times, she didn’t necessarily have to turn into some back-slapping hearty person she wasn’t, or become a serious ‘selling’ type executive presence. She had the respect of the team and she could be herself and speak in her own style to voice support for them, appreciation for their work, desire to solve their problems, underscore how important what they were doing was for the company… Her style of ‘leadership’, based on her credibility and her actions, was enough.
So as I say in the title of this post – another thing I’ve come to believe about PM greatness is that there is no one “right” definition of what a great PM is. You don’t have to be perfect, you don’t have to be the same as someone else who’s considered a great PM. But I do think you have to be willing to read the situation you’re in, be flexible enough to learn new things and provide what the team needs, and do it in a way that fits the company culture and team environment and what that particular group of people needs from you in that project situation. I actually find this to be exciting and liberating — an opportunity to make a difference as “me”, an opportunity to exercise some creativity and define a PM role that works for me and for everyone else.
Tomorrow, a few thoughts on what this all means for maximizing our career opportunities.
Cinda Voegtli
www.ProjectConnections.com
