CXO

How to destroy a project team in four easy steps

This will be a short blog entry this week. My wife just gave birth to our first daughter and I'm not thinking too much about project management or work. Really, I'm not thinking about anything other than sitting around looking at the marvel my wife has brought into the world and wondering how on earth I'm going to live up to her love.

That said, though, a friend of mine called me yesterday to talk about team building. He's having trouble keeping his team's morale up during a troubled time at his workplace. After spending a few minutes on the phone with him, it seems his executives have fallen into the most obvious of traps. They deliberately tear down the project teams, rather than building them up. It's an easy thing to get into, especially in an dictatorial environment where the managers get to redefine success at any given moment.

Step One – Stand on Top of the Team

The first, and most damaging, thing the executives demanded was to be part of every email conversation and meeting. This constant oppressive feeling of being watched, knowing you could be countermanded on even the smallest detail of your job, leads to a kind of paralysis which destroys initiative and a team.

Over the years, I've learned this kind of behavior stems from two basic situations. The first is a fear of losing control. The manager or executive simply cannot allow others to make decisions because he fears the consequences of those actions. The second, and more insidious, is a corporate culture in which even senior technical team members cannot make basic decisions because the executives feel a need to “validate” their paychecks.

If we were our executives' shrinks or their professional couches we could deal with this. As project managers, we just have to grin and bear it. Practically we can also try to manage this tendency by gathering all of the questions from the day before, presenting them to the executive in question, and trying to guide the executive's response. Sometimes it works, sometimes it doesn't. Sometimes the executive's fear runs too deal for simple measures.

Step Two – Distrust the Team Members

Sometimes an executive or a manager decides he is the only one who can possibly know what to do or what is going on. Anyone who disagrees with their understanding of the situation is automatically wrong, even if the other person's statement corresponds to reality. This immediately leads the executive to distrust everyone on the team regardless of what words come out of the team members mouth.

Valuing statement over reality seems to stem from the same “validation” instinct as the first step, where the manager has to make all the decisions to psychologically validate his paycheck. They may also be bored. After all, many managers in technology come up though the ranks and they still have that need to solve problems.

Coping with a manager engaged in this behavior takes a second fiddle to coping with the damage his behavior does to the team. I deal with it by listening to my team members and trying to keep them focused on the things they can control. Most people have to leave the environment in six to twelve months or completely burn out.

Step Three – Value Statement Over Reality

In many bad environments executives and managers come to value their statements of what is over the reality of the project team delivering value. They would rather be proved right, time and time again, than worry about the eventual cost. Doing it right in these environments takes a backseat to doing it at all, and damn whatever consequence come later. This kind of thing tends to show up in the most “results oriented” dictatorial environments. People try to prove their worth by doing the impossible over and over again. What they get are hacks, bits and pieces of functional systems throw up to create a facade of function. Behind the scenes the technical crew scrambles to keep everything functioning while the inevitable crashes take out key systems at predictable intervals.

Dealing with this problem requires a project manager to take a two-pronged approach. First we have to make sure we find out exactly what the executive's stated and come up with a way to provide a facade of that functionality. Then we have to plan to backfill the real functionality and manageability, probably as part of another project.

Step Four – Never Hold People Accountable

Oddly enough, the same folks who require the team to “keep them in the loop” with every email, distrust their own people, and value their word over the reality of what can be accomplished also have trouble holding others accountable for real failures. By accountable I don't mean yelling and screaming, but rather holding up the individuals actions to careful scrutiny after a serious problem occurs so that everyone can learn to avoid such mistakes in the future.

This failure to communicate about failure allows project teams to, in essence, waste their time because no one will tell them when they have failed. Worse, people quickly realize that a failure to act will lead to no worse consequences than a failure in action. In other words, it doesn't cost them personally any more to sit on their hands than it does to fail by acting. In fact, given the three other steps to disaster listed above, it costs them considerably less in terms of time and pain.

There isn't really anything we can do about this as project managers. Our ability to hold people accountable for project goals rest entirely on the culture of accountability our executives and managers create. Even highly skilled professionals sink to a level of mediocrity when no one will either recognize their achievements or help them overcome their failures.

Editor's Picks

Free Newsletters, In your Inbox