I never had such an issue or was thinking about this topic during my PM career(Not because I was extremely respected by the developers. It was more like…I didn’t care.) But it seems to be an important question for a lot of Project managers. A good indicator of that is the interview question they keep asking you – “How can you get a team’s respect if you don’t have 10+ years of Haskell development experience???”. Looks like project managers really have some issues with respect…Sometimes I even think that developers treat project managers worse than QAs.. Oh my God, QAs!!! How that can be possible?
There is really some myth out there about Project manager’s work – that we are doing nothing and developer’s really don’t need us. People think that you became PM because you are not good in engineering, but you wanted to survive, so you became PM.
As a result, it seems that there no some initial level of respect. So PM need to earn it. I wanted to write some “rescue guide” for PM to get the team’s respect. It should help even in the worst cases, I guess.
Don’t be afraid, there are not so many great managers around. So your team has probably rather low expectations when you join it. So you can get many respect points rather quick.
Be a professional
Developers respect professionals. Even if they are not developers. But be sure developers understand what profession you are expert in and believe this profession exists 🙂
Prove that you are a good Project Manager. You are a good PM if there no issues coming to the team from your side. When everything goes smoothly, when you are able to remove roadblocks – people see that you are working. When you are using your voodoo Pm techniques, like storymapping and planning, and they are helping (at least, not making things worse) – developers understand, that you are working. When the value you are all creating is the goal for you, not the processes or rituals – developers will agree with you.
It is true no one of the developers would like to to the things you are doing – all these meetings with the clients, budgeting wars, hundreds of emails. They feel grateful to you to allow them to code all the day long. So don’t be a distraction to them and fix all the outside issues – and they will feel grateful even more. Show that you are not only “talking”.
Keep a pace of your industry and the technology it uses. Be active, be a thought-leader within your organization. Or even the industry.
If you are making a promise – be sure you can keep it. You can’t respected if you change things randomly once you have agreed to it. Be consistent. Of course, you can’t get rid of changes. But try keeping the direction you have chosen.
If you can’t keep a promise and pretend you “forgot” about it – minus 100 points to respect. Even if you try to avoid the responsibility and say that someone (client) made you do that.
Switch off your bullshit generator
As PM you know a log of IT buzz words and usually impress top managers with them during the meetings. Be careful. Developers are not stupid. You can’t impress them with pretending you have knowledge of the area you have read about on wikipedia. You are an expert in your own field – project management, they are experts in their field, just respect each other. Do not try to be the smartest one – that is very dangerous with developers, as everyone knows any developer is the smartest guy on Earth. At first you can think it is not ok, but for you, as PM that is a thing which makes everything easier – you can stop torture your brain and try being the smartest guy, who comes and saves us all. Just use your team brain power! They will love you even more!
Of course it seems like you can’t tell them all the truth. Because…What if they find out that we… Do black magic? I can’t guess the reason why we can’t be honest with the team. Process, changes – everything should be transparent.
If something goes wrong – you should always be the example for the team, take accountability for your part in issue and never place the blame on others.
Respected the work the team did
A manager who consistently makes the team rush to implement features and then cuts them for arbitrary reasons (poor scheduling etc…) will not get the respect of the team.
Remember, that you are the servant
Yes, leader. But the servant leader. Share your power, help them perform as highly as possible. Place yourself in a support role under them, not above them. Be part of the team, not someone watching them. Spent a lot of time with them, talk to them, face-to-face.
I am surprised when the new team treats me like a “boss”. As if I came here to manage them. The first thing I tell them is “I am here to help you!”. No, we are not going to be real friends, but why should be they afraid of me? I am even more surprised when I hear something like “Yes, that was stupid. But we did this way. Because he told us to do it and he is a manager. He can fire me if I don’t follow his words.”
Share your power
When you share your power you become even more powerful) In addition to having less actual work) In addition to having people more motivated and dedicated. In addition to getting more respect, as developers see you are not afraid to “loose” your power. That fear that can cost you up to 100 points.
Trust your team
By default – trust the team. You can entrust them later, when they prove they can’t be trusted. According to my observations the things are usually as they expect them to be – it you think person can’t be trusted and don’t trust him – he proves that soon. Do our opinion form the state of the system? I think, yes. Trust the teams and you’ll see they would adjust to your vision of the world even if they are previously spoiled by the other manager.
Leave some problem solving to the team members working on it: it’ human nature to want to solve problems. They would be happy.
Leave the space for the developers to play around, feel freedom and bring you beautiful, clean as the diamond ideas. Which they captive developers can’t produce.
And the last: Be rational
Be logical. Developers hate when people are not logical. Show logic or thoughtfulness when offering suggestions. They don’t expect that! Surprise them!