I wrote an earlier post on Fast Fights about the great d.school teaching team that I was part of last term. I have been getting some questions about team effectiveness since then, and when we did our "postmortem" for the class, one of the students asked for more systematic frameworks to help them with group dynamics and effectiveness issues. There are no magic answers to the problem of team effectiveness. The problem of how to avoid dysfunctional team dynamics runs rampant and, even though thousands of studies have been published on groups and teams, it remains mysterious and unsolved problem. One of the best books on the subject is Leading Teams, by Harvard's J.Richard Hackman, who has been studying group effectiveness for at least 35 years. But Richard would be the first to say that there are no magic answers to this problem, most teams are pretty dysfunctional, and the "magic" that happens in great teams is a rare surprise that can be impossible to replicate the next time (I hope to be part of another team as great as that d.school team soon, but I am also a realist..).
I have found, however, that groups can be more effective -- and more fun -- if they take time at the outset to consider their design and operating principles, take time to deal with "group dynamics" problems when they arise, and do "postmortems" to analyze what went right and wrong when a team disbands, so the organization can do a better job of with teams in the future and so that people on the team can be more effective team members in the next group.
A few years back, I wrote a list of diagnostic questions to help structure these discussions. I reproduce it below as some teams and team members may find it helpful. This list isn't exhaustive and I suspect that there better ones out there. But it may be a useful starting point for some teams.
Questions to Think About When Designing
or Repairing a Team
1. What do you
consider a success at the end? For the team? For specific individuals? For the larger organization
2. Diagnostic
questions to ask yourself (and discuss openly with your team IF there is sufficient
psychological safety and trust):
The conversation
game. How talks the most? How talks the
least? How interrupts the most? Who gets interrupted the most? Are these
patterns destructive or constructive?
The power game.
Who is the most influential in the group, who is the least influential? Do people get their way just because they are
pushy or because they know better?
Do people in the
group act like friends, enemies, or solo operators-- or some blend of the three? Do people get “points” for helping
others and asking for help? Do you just
watch people struggle and complain behind their backs? Or do you just do your
own parts and paste them together somehow at the end (Note it depends on the
level of interdependence required for the task – some tasks require a lot of
interaction, others can be divided-up pretty easily).
Talk versus
action. Do you hold people accountable
for doing what they say? Or do you encourage and reward smart talk alone?
Performance norms.
Do you ask people to make specific commitments? What do you do when someone
drops the ball? Forgive and forget?
Forgive and remember? Talk about it? Simmer?
Conflict. Do you
know how to fight? Do you fight over ideas or personality issues? Do you know when to stop fighting?
“Full speed ahead”
problems. Are you charging ahead, with
your project idea or with your division of labor, or do you stop regularly and
ask if it is working?
Other norms. Are you unwittingly encouraging each other to be procrastinate, to snivel, to fight about silly things, to arrive late, to be mean to each other? Think about what you are allowing and encouraging in the group – is it getting in the way?
3. Types of Members. Some questions about different kinds of “personalities” in the group, inspired by “Feuds in student groups: Coping with whiners, martyrs, saboteurs, bullies, and deadwood,” an article that David Jalajas and I wrote years ago.
Martyrs: What should you do if one of your group
members insists on doing everything, and constantly complaining about how
little others are doing?
Saboteurs: What can you do when a group member undoes or
changes others’ work without permission and in a way that conflicts with prior
agreements about how it should be done?
Bullies. What do
you do when a group member is so bossy and pushy that they constantly insist
that others do it their way?
Deadwood: What do you do with “deadwood,” people who
don’t pull their weight?
Note: Effective teams spend most of their time talking about the content of the work and the logistics of getting it done. Talking about the above question at the outset or when the team hits a rough spot makes a lot of sense. These questions are also useful for doing “post-mortems” when project is over and the team is disbanding, so the people and organization can be more effective in the next project.
BUT beware that too much attention to these questions can be just as dangerous as none at all. Some of the worst teams I have
been on have spent so much time talking about these and other “process” issues so much that they
fail miserably: The task doesn’t get done at all or is done badly. Ironically, because too
much time is spent on interpersonal and personal issues, the dynamics problems that
the team is trying to resolve get worse because –and a lot of research backs
this up – task failure is a powerful causes of dysfunctional conflict,
nasty episodes of “blamestorming,” and personal dissatisfaction. So although I believe strongly in thinking
about and raising group dynamics issues, especially at the beginning and when a
team is broken, too much of this good thing can be very bad.
There are some things you can do to prevent disaster. If you have a really, really important project ahead, and the team members don’t know each other, they should spend some time together without doing any important work. When NASA launched the Apollo program in the 60’s, projects spent the first months just getting to know each other without doing any important work. It’s much harder to criticise a friend than a stranger. Also, the way incentive programs are modelled often conflicts with the philosophy behind how modern project work should be done. Incentive programs encourages hero behaviour in groups, while standards such as ISO 9001 and CMM don’t allow hero cultures in organizations.
Posted by: Jan Barkhed | December 19, 2006 at 12:13 AM
Bob, thanks for sharing the tips. Very useful indeed.
I've only just found your blog. I'm sure I'll enjoy 'catching up'
Steve
Posted by: Steve Pashley | December 18, 2006 at 09:12 AM