Stuck at dysfunction junction

Posted by on Feb 18, 2015 in Computerworld Columns | 0 comments

Sooner or later, every IT manager finds himself at the head of a dysfunctional team. People don’t talk to one another, and sometimes they hide information. They can’t make decisions. They can’t stick with decisions that have already been made. Work gets duplicated or doesn’t get done at all.

It can make you feel powerless. You are under pressure to deliver, but you can’t do it when the team you’re completely dependent on can’t seem to work together.

I usually see IT managers tackle the problem of a dysfunctional team in one of three ways, all misguided:

  • We’ve got a bad apple on the team. And we need to fire him. In this case, one person becomes the scapegoat for the entire group. Unsurprisingly, things don’t get better after the execution. Time for Plan B.
  • We need a new process. This one tends to run into trouble because it’s difficult to respond properly to an unarticulated problem. No matter how clearly you spell out and assign tasks, the new process probably won’t work much better than the old one because you don’t have a real grasp of what it is that needs fixing.
  • We need to reorganize. Again, you don’t identify the real problem, and instead you try to separate the people who are most antagonistic toward each other. What you usually get are the same problems, moved from one place to another.

In every case, the solution doesn’t work because you have failed to understand where the problems are coming from.

As frustrating as a dysfunctional team is, don’t let it cloud your judgment. Remember that most people in IT really want to do a good job. You can generally assume that all of them sincerely believe that they are behaving in ways that the organization rewards. For example, team members who don’t respond to emails may believe that doing so would be a distraction — that completing their tasks is more important to you than communication.

Try to think of assumptions your team members might have that lead them to behave the way they do. Then ask yourself two really hard questions:

  • How does my behavior contribute to or perpetuate these assumptions?
  • How does my inaction contribute to or perpetuate these assumptions?

It doesn’t matter if you have told them that their assumptions are wrong. Actions truly do speak louder than words. People learn much more about what the organization values by what you do or don’t do than by what you say. If you tell everyone that you want them to share their best ideas, but then publicly belittle people who offer bad ones, they learn that it’s not safe to speak up, and no one offers ideas ever again.

Once you have a good idea about what underlies your team’s behavior, you can begin behaving in ways that change their assumptions and encourage them to learn about what the organization really values. At that point, you might even pursue reorganizations, removals or new processes. The difference is that, as responses to a problem that you have identified, they’ll be means to a well-understood end, rather than just confusing experimentation.


 Copyright 2015 by Computerworld Inc., One Speen Street, Framingham, MA, 01701.  Reprinted by permission of Computerworld.  All Rights Reserved.

For more information about how you can leverage geeks to get the technology you want, contact or call 310-694-0450.

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.