I’ve worked as a project manager for about 8 years. While it involves a lot of politics, especially when the company or the customer you work for is a larger enterprise, a major part of a project’s success can be attributed to the project team. You definitely want the best team. And that does not necessarily mean the best individual players but people who can work together — comparisons with team sports usually hold. Strive for both: “A” players who perform well in teams.
However, it never stops there. Bad management can still mess things up and “A” players will leave first at the slightest hint of that happening. In a setting where the players have already been chosen (i.e. you are not the one who hires people), it is definitely up to the project manager to get the best out of his (or her) team.
The manager is expected to motivate his team. It says so in almost every job posting. It makes sense: The motivated team will go to great lengths to achieve success. The indifferent team’s output will be average at best. Most projects with demotivated team members fail (at least according to what I’ve seen). But nobody ever tells you how to motivate people. And only few people seem to know. Here is what I’ve learned:
Respect Your Team
It’s the number one motivator: respect. It works so well in IT because every programmer has seen so much contempt for their work (often even for their person) that respect will feel refreshing. Personally, I find that respect is a basic prerequisite of any professional. Unfortunately, disrespect is very widespread. No motivation without respect.
Get Their Input
Ask them about their opinion. Listen to them. And act upon their feedback if it is reasonable. If it is not reasonable, explain why. Decide on a case-by-case basis. Don’t just ask your best people, involve even the ones that don’t appear as important (they all are anyway). The quiet ones. The ones who haven’t made many major decisions on the job. They will have your back in times when you need it most.
Remove Distractions
Your main job is to create an environment for your team to be most effective. They need to be able to focus on their work. This means that you need to keep the surrounding the politics from them. You are the buffer between them and the customer or upper management. Fight upwards if you have to. Never pass blame down. Your project should be a safe place for your team members.
Enable Communication
Teams need to communicate. Make sure they can. Keep them in close proximity to each other. A daily standup meeting can do wonders. But absolutely keep it to 15mins, no more, no exceptions. (Push them to report faster if necessary. Discourage discussions, they can be held later.) Keep other, longer meetings to a bare minimum. I had a team meeting once a week max. Sometimes, they would only take 30 minutes or even less. If there’s nothing to discuss that applies to all attendees, cut it short and let people go back to work. Don’t make up insignificant topics.
Be Available
Never send people away when they ask for advice. But if you have to, e.g. when you’re on the phone, get back to them as soon as you can. “I’m busy” is not an excuse. Everybody is, all the time. If team members haven’t shown up in a while for a one-on-one talk, initiate it yourself. You should always know what your team is up to and what the general atmosphere is like. Make any conversation a personal one. Avoid phone calls. Definitely avoid email conversations. (Only use email to document what has already been discussed in person.)
Have Visions and Values
People are always motivated by a greater purpose. Show them the goal and how you plan to achieve it. Give them extra information. Show them the big picture. I usually pass on information I receive in manager circles, things typically not communicated to developers. It creates trust because I trust them by telling them. Also, be clear about your values. If there are behaviours you don’t want, then don’t accept them, from anybody. But let people know about them beforehand. It’s always best to have shared values so find out early on what those values are and communicate them clearly and often.
Be Humble
The word “manager” does not mean more or less than any other title. It’s just a different type of work. The best way to kill motivation is to display some kind of superiority towards the team. It may be cheesy but drawing the organizational chart upside down (with you below the team) is exactly what working in it should feel like: You as the manager support your team, you don’t command it.
A Word on Agile and SCRUM
Agile methods such as SCRUM are definitely recommended. They keep goals within visual range and provide a flexible enough framework to make changes happen. And projects change all the time because the world changes all the time. SCRUM should not be treated as a religion. Understand its intent and apply the methods which fits your team and project. Measure success and make changes if things don’t work well.
As a final note, I tend to think it’s much easier to follow these rules when you are a developer yourself. I’ve seen to many non-developers lead development teams in the wrong way, often not able to help them where necessary and often lacking respect. If you are a developer, however, you should know that managing a team is very different from hacking a machine. Solving team problems is not debugging. People won’t be programmed by you. You will need a certain amount of emotional intelligence to make things work. Once you’ve figured it out, though, it becomes an exhilarating task. When everybody is motivated, the sky’s the limit.