Team Conflict

I wrote this guide ten years ago when I was supervising undergraduate programming projects at the University of Toronto. I hope it’s still useful.

Grades just came back for the second assignment. Your team got 51%, which is far lower than you’re used to. The sick feeling in the pit of your stomach has turned to anger: you did your part, and so did most of the rest of the team, but Marta didn’t turn in her stuff until the very last minute, which meant that no one else had time to spot the two big mistakes she’d made. As for Chul, well, he didn’t turn his stuff in at all—again. If something doesn’t change, this course is going to pull your GPA down so far that you might lose your scholarship.

Situations like this come up all the time in the real world, and in all parts of life. Broadly speaking, there are four ways you can deal with them:

  • Cross your fingers and hope that things will get better on their own, even though the last eight times you hoped they would, they didn’t.

  • Do extra to make up for others’ shortcomings. This sometimes seems to work in the short term, and saves you the mental anguish of confronting others, but the time for that “extra” has to come from somewhere; what usually ends up happening is that other courses, or your personal life, suffer.

  • Lose your temper and start shouting. Unfortunately, people often wind up displacing their anger into other parts of their life: I’ve seen developers yell at waitresses for bringing incorrect change when what they really needed to do was tell their boss, “No, I won’t work through another holiday weekend to make up for your decision to short-staff the project.”

  • Take constructive steps to fix the underlying problem.

Most of us find number four hard because we don’t like confrontation. If you manage confrontation properly, though, it is a lot less bruising, which means that you don’t have to be as afraid of initiating it. Also, if people believe that you will actually take steps when they bully, lie, procrastinate, or do a half-assed job, they will almost always pull up their socks.

Here are the steps you should take when you feel that a teammate isn’t pulling his or her weight:

Make sure you’re not guilty of the same sin.
You won’t get very far complaining about someone else interrupting in meetings if you do it just as frequently.
Check expectations.
Are you sure the offender knows what standards he is supposed to be meeting? This is where a team contract comes in useful.
Document the offense.
Write down what the offender has actually done, and why it’s not good enough. Doing this will help you clarify matters in your own mind. It’s also absolutely necessary if you have to escalate.
Check with other team members.
Are you alone in feeling that the offender is letting the team down? If so, that doesn’t necessarily mean you’re wrong, but it’ll be a lot easier to fix things if you have the support of the rest of the team. (Finding out who else on the team is unhappy can be the hardest part of the whole process, since you can’t even ask the question without letting on that you’re upset, and word will almost certainly get back to whoever you’re asking about, who might then turn around and accuse you of stirring up trouble. After a couple of unhappy experiences of this kind, I’ve learned that it’s best to raise the issue at a team meeting in front of everyone.)
Talk with the offender.
This should be a team effort: put it on the agenda at a team meeting, present your complaint, and make sure that the offender understands it. In most cases, this is enough: human beings are herd animals, and if someone realizes that they’re going to be called on their hitchhiking or bad manners, they will usually change their ways.
Escalate as soon as there’s a second offense.
Hitchhikers and others who really don’t have good intentions are counting on you giving them one “last chance” after another until the term is finished and they can go suck the life force out of their next victim. Don’t fall into this trap. If someone stole your laptop, you’d report it right away. If someone steals your time or your grades, you’re being pretty generous giving them even one chance to mend their ways.

In the context of a student project, “escalation” means “taking the issue to the instructor”. (If you’re reluctant to do this because you don’t want to be a snitch, go back and read what I just wrote about people stealing your laptop.) Of course, your instructor has probably had dozens of students complain to her over the years about partners and teammates not doing their share. (It isn’t uncommon to have both halves of a pair tell the instructor that they’re doing all the work. This is one of the reasons I insist that students use version control to manage their projects: it lets me check who’s actually written what.) In order to get her to take you seriously and help you fix your problem, you should send her an email, signed by the whole team (or as many as you can get on side) describing the problem and the steps you have already taken to resolve it. Make sure the offender gets a copy as well, and ask your instructor to arrange a meeting to resolve the issue.

This is where documentation (step three in the list above) is crucial. Hitchhikers are usually very good at appearing reasonable; they’re very likely to nod as you present your case, then say, “Well, yes, but…” and rhyme off a bunch of minor exceptions, or cases where others on the team have also fallen short of expectations. If you can’t back up your complaint, your instructor will likely be left with the impression that the whole team is dysfunctional, and nothing will improve.

One technique your instructor may ask you to use in a meeting of this kind is active listening. As soon as one person makes a point, the person on the opposite side of the issue explains it back to him, as in, “So what I think Igor is saying is…” This guarantees that the second person has actually paid attention to what the first person said. It can also defuse a lot of tension, since explaining your position back to you clearly forces the other person to see the world through your eyes, if only for a few moments.

What sort of people make teamwork hard?

Tolstoy wrote that all happy families resemble one another, but each unhappy family is unhappy in its own way. Similarly, all good team members share certain characteristics, but bad ones can be bad in many different ways. Here are a few:

Anna
knows more about every subject than everyone else on the team put together—at least, she thinks she does. No matter what you say, she’ll correct you; no matter what you know, she knows better. Annas are pretty easy to spot: if you keep track in team meetings of how often people interrupt one another, her score is usually higher than everyone else’s put together.
Bao
is a contrarian: no matter what anyone says, he’ll take the opposite side. This is healthy in small doses, but when Bao does it, there’s always another objection lurking behind the first half dozen.
Caitlin
has so little confidence in her own ability (despite her good grades) that she won’t make any decision, no matter how small, until she has checked with someone else. Everything has to be spelled out in detail for her so that there’s no possibility of her getting anything wrong.
Frank
believes that knowledge is power. He enjoys knowing things that other people don’t—or to be more accurate, he enjoys it when people know he knows things they don’t. Frank can actually make things work, but when asked how he did it, he’ll grin and say, “Oh, I’m sure you can figure it out.”
Hediyeh
is quiet. Very quiet. She never speaks up in meetings, even when she knows that what other people are saying is wrong. She might contribute to the mailing list, but she’s very sensitive to criticism, and will always back down rather than defending her point of view. Hediyeh isn’t a troublemaker, but rather a lost opportunity.
Kenny
is a hitchhiker. He has discovered that most people would rather shoulder some extra work than snitch, and he takes advantage of it at every turn. The frustrating thing is that he’s so damn plausible when someone finally does confront him. “There have been mistakes on all sides,” he says, or, “Well, I think you’re nit-picking.” The only way to deal with Kenny is to stand up to him: remember, if he’s not doing his share, he’s the bad guy, not you.
Melissa
would easily have made the varsity procrastination team if she’d bothered to show up to tryouts. She means well—she really does feel bad about letting people down—but somehow something always comes up, and her tasks are never finished until the last possible moment. Of course, that means that everyone who is depending on her can’t do their work until after the last possible moment…
Petra
has a favorite phrase: “why don’t we”. Why don’t we write a GUI to help people edit the program’s configuration files? Hey, why don’t we invent our own little language for designing GUIs? Her energy and enthusiasm are hard to argue with, but argue you must. Otherwise, for every step you move forward, the project’s goalposts will recede by two. This is called feature creep, and has ruined many projects that might otherwise have delivered something small, but useful.
Raj
is rude. “It’s just the way I talk,” he says, “If you can’t hack it, maybe you should find another team.” His favorite phrase is, “That’s stupid,” and he uses obscenity as casually as minor characters in Tarantino films. His only redeeming grace is that he can’t dissemble in front of the instructor as well as Kenny, so he’s easier to get rid of.
Sergei
is simply incompetent. He doesn’t understand the problem, he hasn’t bothered to master the tools and libraries he’s supposed to be using, the code he checks in doesn’t compile, and his thirty-second bug fixes introduce more problems than they solve. If he means well, try to re-partition the work so that he’ll do less damage. If he doesn’t, he should be treated like any other hitchhiker.

Irreconcilable Differences

Sometimes, it isn’t just one person on the team who’s a problem. Sometimes, the whole team is dysfunctional. In the mid-1990s, for example, I worked in a data visualization startup. Individually, we were all smart, decent people. Put us together, though, and somehow our personalities and IQs canceled out, leaving us all dumb and nasty.

Instructors can allow for this by announcing at the start of the course that teams will be dissolved and re-formed halfway through the project, unless every member on the team submits a separate signed request to stay together. There’s a bit of psychology here: if people are required to ask for their team to be dissolved, they will often think, “It’s more trouble than it’s worth, I’ll just put up with it.” If dissolution is the default, though, then students won’t be inhibited by any stigma attached to being the one who caused trouble.

Students also usually understand that dissolving their team and forming a new one takes time that could be invested in earning a higher grade. In practice, therefore, teams will almost always choose to stick together if they see that hitchhikers and rudies are actually being dealt with.

Updated: