How to Motivate a Team
I was following a thread on a LinkedIn group recently about how to motivate a team, and I felt compelled to join the group and reply. Not surprisingly, I had a few things to say.
The difference between a great team experience and a mediocre or horrible one has everything to do with the team dynamics and relationships – trust, shared goals, open communications, support, mutual respect, helping one another. It has nothing to do with the ‘hard skills’ of project management – having a particular tool, or using EVM, or even following a particular agile approach.
This opinion comes from my experience, and from explicitly asking thousands of project participants over the years, including rooms full of professional PM’s.
If the team has that better experience, the project results improve as well. We can proactively build that experience, but there are two barriers: understanding what to do, and thinking that all those things to do are a luxurious cost that the project can’t afford.
Let’s start with that cost issue. If we were to do a reasonable cost accounting on our project and sum up the costs of team dysfunction when it flares up on a project – from the hard costs of delays, rework, cost overruns, to the softer costs (though still quantifiable at least by proxy) of turnover or resentment or other forms of ‘less than 100% committed participation’, then these costs far outweigh any investment required to build an effective team. The savings comes in the reduction of these dysfunctional interactions. If we truly understand the costs of our project, that argument goes away.
Now for the ‘what to do’.
Even if we understand the basic ideas behind the Tuckman model for team maturity, and/or the Situational Leadership model for leadership based on the needs of the team, most PMs today don’t appreciate that we can consciously, proactively, build a team to a higher state of maturity so that it functions as the team and the leadership desires. Team building isn’t an afternoon of paintball, it has loftier yet still achievable goals.
While most people have lived a great team experience at some point, there remains little appreciation for the possibility of effective team building practices. The PMBoK merely mentions that the concepts exist, and Agilists primarily developed their approaches while working in a highly mature team environment without consciously recognizing the impact of that maturity on their success, so it doesn’t get codified into their approach.
We should be consciously invest in bringing the team together at the beginning of the project.
Sure, the team needs to understand the virtues and benefits of the project, but these are merely extrinsic values. I’m at the point in my career where if I can’t find intrinsic value in participating in the project (and money is not nearly the biggest driver), I’ll step aside and let others do the job, as a job is all it will be.
Every participant needs to have some intrinsic motivation in order to be able to contribute 100% to the project. This includes being valued not only for the skills they bring to bear on the project, but for everything else that they are. I find that the prominent doctrines of PM today tend to significantly downplay the human element involved in projects, and that is why projects get done (too few of them), but not nearly as efficiently, effectively, or pleasantly as they can be.
The PM should not be seen as the boss, and any hierarchy needs to be removed from the team. The PM brings an appreciation for the value of taking the time to motivate and grow the team. The team has conversations so the team agrees on the virtues and goals of the project, the PM doesn’t merely tell them these things. The team has conversations so everyone’s strengths are on the table (beyond their vocational strengths), and everyone expresses what they personally want out of the project. The team ensures that any diversity: gender, cultural, religious, motivational values, etc. – are understood and appreciated as strengths so the team has a wider range of perspectives to draw on to solve challenges, rather than allowing this diversity to tear us apart. The team discusses how to relate to one another to build and maintain trust – not to merely build a team agreement document that gets cast aside, but to nip potential conflicts in the bud.
All these conversations take time, but are definitely not wasted work. They build a team that can be relied on to do what is needed, and support one another through the challenges they will face. Over time they build trust, respect, and appreciation for one another, and an environment where fun can emerge. The project becomes more than merely a job, people have an intrinsic investment in the project and their teammates.
All this tends to make the team run more smoothly, identifies issues earlier so the team can collaborate to deal with them when there are more options to choose from, and leverages all the strengths the team can bring to bear together on the problem. It tends to bring the overall effort down rather than up, and improves the product quality in the process. There is far less talk about non-performers or overbearing bosses, less turnover, and silos are removed. This not merely theory, this is done in enlightened project teams worldwide.
All the ‘hard skills’ espoused by the reigning PM doctrines are still important, but I see their contribution in a different way.
Without an appreciation of a motivated, high performing team, a schedule can still be built, EVM can still be used and risks can still be analyzed. The project will still at some point be done – often later or more expensive or with poorer quality or with high turnover or all of the above. Sometimes ‘done’ simply means cancelled. The perception will often be that this PM stuff is hard, and often the PM is the hero that dragged everyone through the mud to completion. There is adrenaline on these projects, but that’s not the flavour of thrill I seek.
With a high performing team, these same ‘hard skills’ are tools to guide conversations in the right direction, the team collaboratively agrees on how they will complete the project, understands what might get in the way, knows where they are compared against their intent. Done this way, the PM doesn’t need to know all the answers. The team has more expertise and experience to bear on the problem, and a deeper sense of ownership with their participation. People gain an appreciation for the complexity of the other parts of the project, so silos disappear. Documents are the outcome of collaborative conversations, rather than unread, weakly filled-in templates.
Too often when a project is challenged, we doubt the team, think it may be the wrong team, even let people go when we haven’t taken the steps to help them become the a team we all desire. I have not seen any downsides to a comprehensive approach to motivating a team, and I have been on projects driven by both of these philosophies.
Team building is a conscious, deliberate process, that few leverage. I see it as the most important leadership contribution to the team.
This approach is the lubrication that makes projects run more smoothly. It isn’t ‘at odds’ with dominant PM thinking, but rather ‘supplemental to’.
I didn’t need awareness of any of this to get my PMP designation, by the way.
I don’t think the PMBoK should expand to codify these ideas, that’s already done elsewhere. Instead, I think we need to study multiple disciplines to completely understand how to proactively manage the complexity of team dynamics. – JB