Why are soft-skills important for project managers?
I’d argue that soft-skills are what separate good PM’s (project manager) and the people that everyone hates: “middlemen” or “middle management”. All too often, people take on PM positions because it is the only step upwards in their career path. Technical people often can only get decent pay increases by taking on PM positions and there’s also a lot of people that get thrust into the position for a variety of reasons. This leaves people in a position where they’re scrambling to figure out what a PM actually does. In most cases, no one tells them, and they think booking flights, answering emails, and sitting on conference calls trying to make people happy is their job. While these are very useful things to do, the PM’s real job is much more subtle. The PM of a project needs to protect scope, listen well, and become comfortable with a bit of tension! Let’s dive in.
Scope creep is a well known concept. I’ve talked about scope before on various other blog posts of mine. In a nut shell, scope creep is when you and the client decide on what the project’s goals are, but then along the way new things get added or things change in big ways. So it seems to make common sense that the project manager would be useful in preventing the scope from creeping…but in reality most project managers might feel like they don’t have the detailed/technical/business know-how to step in and stop the scope from creeping (everyone’s got one excuse or another). When I’ve previously spoken about scope creep (and buy-in), all aspects of business have some give-and-take. There are some cases where client asks for something and you can flat out say “no!” but in most cases you’ll have to find the easiest solution that alleviates whatever the issue is (or even better get them to pay more!).
Now this becomes especially difficult in the technical fields like ours, because it’s not common for developers to step up and say “no!” because in most cases they don’t have the authority and would be a partner of a partner of a vendor, so it’s really not the place of developers without some perceived seniority to step in and block scope creep. That’s where the PM comes in! If you know your scope well, and you start to see scope creep, just make it known right then and there that it’s scope creep, and you’ll need to regroup with the team afterwards to figure out a solution or additional cost for the ask. You’ll forever be a hero to the people around it. And remember, you’re not being rude or saying “Oh hell no!”, but you’re just making it clear so the client knows what they’re asking for is outside of the original agreement and that you’ll do your best to find a solution for them.
Listening (and read between the lines)
This one is simple but has a few parts. The first is listen, for real. Often times, you’ll have the developers or team members working under you who will come to you with a problem. The middle managers we all hate, just kind of hear it and that’s it. The great project managers are the ones that really listen to your concerns, empathize with you, and then immediately offer a few suggestions for solutions that could be taken (or timelines for trying to find a solution). If team members feel like they’re really listened to, they’ll do whatever you need from them without any issue. You got their back, they got yours.
Listening can be a bit more complicated in business scenarios because not everywhere is an honest and safe space to talk about things at 100% truth values. What am I talking about? How about meetings you have with your team and the clients? Or when you’re on-site with vendors? In these situations, you might find really manipulative clients will try to bypass the project manager and talk directly with developers and more technical team members who might not be used to manipulative business talk and behaviour. They do this so that they can try to avoid a good PM blocking scope creep! They can get your developer to give them a bit of information, like a change isn’t really hard or that the developer could make it happen in a day, then the client will come back to the PM and say “well your developer says it’s easy, so why should I pay you more?” What does this actually mean for a PM? Well, you should always be listening to your team, but you should even more always be listening to what client’s are saying and who they’re talking to. You should also get used to how your team members communicate so you can notice their subtle cries for help when the client is drilling them for information. Sometimes the developer may not want to say no outright, and they’ll give you a subtle ask for help like “hmm let me think about that” which you should hear as “OH GOD PLEASE HELP ME!”.
Moral of the story:
- Listen to your developers and team members for real and empathize
- Listen to your clients and keep tabs on them
- Read between the lines and learn the more subtle communication of your team members so you can come to their rescue when they need saving
Being comfortable with tension
This one is easy to say but difficult to do. One of the problem is that we’ve moved towards work environments that are friendlier and friendlier, where criticism can be taken wrong more times than it might be taken well, and most people try to avoid creating conflicts. Whatever the reason, it means that business relationships can quickly become a 1-way street for clients who will just say whatever they want while PM’s just say yes so that they don’t create a conflict or an uncomfortable moment. I’m not saying you should go out there and be a professional contrarian. You still need to choose your battles wisely, but there’s nothing wrong with standing your ground, saying no, leaving dead air, or making a situation tense and uncomfortable if it’s for the good of you / your team.
This is especially useful when talking to clients about project costs. PM’s have a tendency to try to fill dead air and silences when talking about money because it might be uncomfortable to say a large amount, then have the client say nothing. When I’m talking to clients about costs I only have a few words that I say before telling them the cost: We’re some of the best developers around, our firm has worked with the biggest names, and we’ll deliver 100%. Then I just say the cost and nothing after. Sometimes it gets awkward as the client might be fumbling around or waiting for you to say something, but you just got to be comfortable with the awkward silence of that moment and stay calm in the tension. Otherwise you’ll lose control of the situation and be put on the back foot trying to give a million reasons to defend your pricing, which is never a winning battle.
PM’s are life savers. I’m not on the bandwagon of “cutting middle management.” I think that’d be a terrible idea because I’ve done a lot of good things in management positions and have had a lot of great PM’s bail me out of terrible situations. PM’s just need to get their soft-skills together. The things they might not tell you when you sign up for the job, but that will make you really shine in the role. To wrap up, the Cole’s notes of it all is to always be on the front line of defending against scope creep, step up your listening game, and learn to love some awkward silences!
Outputting content in TouchDesigner
Why is outputting content from TouchDesigner hard? TouchDesigner is an interesting...