Aside from various other issues on which people have remarked, one thing that hasn't been pointed out so far is the problem with college projects: they're too damn small.

For every project, there is a good range of team sizes, large enough for many hands make light work, but not large enough for too many cooks spoil the broth (where you start having to split it up so finely that coordination overhead swamps the actual project work - see Fred Brooks, The Mythical Man-Month, for a classic discussion of this).

I remember one college project I had, we were supposed to do it in teams of four. Problem was, like other college projects, it was comfortably sized for one person, a moderately tight squeeze for two; four people was an insane glut. Solution: the two best programmers in our team did the project, the other two paid for our beer for an evening.

Now you say "all of a sudden, foom!, my part of the project is done because one of the girls was bored on the weekend and had nothing better to do. (Huh? When does this ever happen?)"

Well the answer is, it doesn't happen often in real life, because it's a symptom of a project much too small for the team size, or equivalently a massive glut of manpower for the project size - in real life, you have a to-do list stretching to somewhere around the middle of the next century, that grows by two items for every one item you knock off, and a desperate shortage of skilled people to do the work.

So while teamwork is important in real life, and many issues thereof do arise, that particular problem is mostly endemic to college projects.

Yes, I've had this exact problem in school, and it took me about 12 years (3rd grade through middle year of law school) to figure out how I could cope with it.

One hack that's helped me work together with people who have, shall we say, varying levels of motivation, is to ask people, nonjudgmentally, about their motivation levels and then try to assign each person a quantity of work consistent with him/her getting that work done very well. When you start hearing phrases like "Really? That's all you want me to do? OK! [shrug]" then you know you've cut the portions small enough. With a little bit of friendly prompting, the small amount of work will probably get done reasonably well and reasonably fast -- you will spend less time/energy prodding than you would have needed to do that portion of the work yourself.

Of course, this strategy will leave you and any other highly motivated team-members with an "unfairly" large chunk of the remaining work, but, crucially, this will still be less work than you would have if you tried to go it alone, either before or after trying to assign lots of unwanted work to unmotivated teammembers and then having to (re)do it when it's not completed on time or not completed up to a reasonable standard.

First, something not-particularly-useful-now but hopefully comforting: group projects in school, even ones that mimic real world problems, very often are not comparable to Real World projects in the sense of group composition and motivation. In school, you just can't get away from the fact that your ultimate goal is a grade, which is intangible and at least partially arbitrary. Because of that fact, you will nearly always have less total group motivation and more total disagreement on how much work is required for an "acceptable result" on a project for school than you will once you are out of school. As you noted in your lifeguarding example, being paid for your work helps no small amount. I'd also rather think that the fact that someone's life rides on the group's performance (as it certainly will in situations you encounter in nursing) takes motivation to a whole new height.

I had your problem all through high school and most of my undergraduate education. I attribute its fading primarily to learning to trust my group members more, which was facilitated through

1) picking group members carefully when I got the chance, to maximize potential for # 2

2) realizing that in my field, chances were high that at least half of any group I was in would be in the same ballpark as I was where motivation was concerned.

Each time I had to work in a group, I made a conscious decision to trust my group members to do a decent job, which helped me remember not to let my control freak tendencies make me objectionable. Sometimes this involved noting members I didn't trust and resolving to watch for slack from their end, as well, but quietly.

I also became a good leader by creating and administrating a very diverse group of players in World of Warcraft for almost three years, but I really don't recommend that route unless you have either an absurd amount of free time or a very low regard for sleep.

I have had some good group experiences and some bad ones. The good experiences differ from the bad in two ways: group members know what they're doing, and care about doing it. The former relates to both general knowledge (as you put it, knowing the right way to do things) and specific knowledge of one's assignment, while the latter is basically motivation.

Of course, it's easy to reflect on my past experiences and see, in retrospect, what shaped my feelings about them. However, that's not quite at the point where it's useful for predicting when future experiences will be good ones. Working in a group, especially with people you don't know well, can lead to a lot of anxiety due to your uncertainty about the other people and how they will perform. Here's how I've resolved this problem: figure out when I can trust the other people to know what they're doing and care about doing it. If my priors for the group members indicate that I should trust them, I simply do, unless new events warrant a reevaluation of that trust. If they indicate that I shouldn't, I assume that I will have to do all the work myself, and get going based on that. These can be mixed and matched, if I have different priors for different people. Coming to a working conclusion about the other people and then acting on it eliminates much of the anxiety from uncertainty.

One example of a great group experience was this past summer, when I did research at Fermilab. Because of the prominence of the laboratory, my priors for trusting my group members' competence were high, and every day that trust was validated. Everyone had skilled backgrounds, knew the right ways to do things, and cared about the research.

In contrast, many such "group projects" in school were bad experiences. Year after year of these led me to develop the policy that if a person seemed unlikely to be invested and competent, I* would cut them out of the action or give them busywork whose importance was minimal (in those highly irritating cases where the teacher demanded that each person contribute or the grade would be lowered anyway). School group projects are generally important for the grade rather than their actual content, and therefore, I reasoned, getting the grade is also more important than achieving the "intended" semi-egalitarian group experience.

I suspect this is what led to the "new sort of problem" you described. It seems likely that when you missed the meeting and didn't actively respond to the email communication, alarm bells went off for one or more of the other people in the group, especially if they didn't know you well beforehand. I admit without embarrassment that I have done to other people the same thing that happened to you. Obviously you know you're competent and invested, but that doesn't mean others do. It's unfortunate that you lost a group learning experience. However, for a project in which the outcome (the actual result and/or the grade) is most important, best practices dictate not taking chances on other members whose competence and investment seem uncertain.

To sum up: decide when and who you can trust, and go from there. Realize that the outcome is what's important, and it's not your responsibility to coax and prod every group member into a state of motivation and competence if they're not already there; in the same way, it's not others' responsibility to do that for you.

*I recognize that you stated you're not skilled at leading groups. To modify this advice for you (and other such people), I suggest that, if you come to that sort of realization about the person in the group and you're not the appointed or apparent leader, bring it up to the person who is, in such a way that ey'll hopefully take care of the problem.

Edit: I should have refreshed the page before submitting, as I now realize I repeated much of what other people posted before I finished writing mine. Oh well.

I’m more invested in the outcome than the others (...) I skimmed the email and put it aside for later, since it seemed less than urgent to me.

Notice a contradiction?

To a reasonable first approximation teamwork consist of exchanging and fulfilling promises. (To a first approximation only; in particular, affect turns out to count for a lot, but more over the long run.)

See this article for an introduction to one framework for thinking about promises, inspired by the work of Fernando Flores and Terry "SHRDLU" Winograd, and by Searle's theory of speech acts.

The situation you describe can easily be analyzed in terms of failure to negotiate a reliable promise - consider the specific details "an exercise for the reader". The failure isn't necessarily on your part - but one major point of the article is that reliable promises are a shared responsibility.

I'll just start off by saying that the latter "problem" will never happen outside of college. People simply do not have the time, effort, or motivation to do other people's work when they have their own job they're supposed to be doing. As rwallace astutely pointed out, college projects are way too small. When you are working, you will find that you (and everyone else) will always have more work to do than time to do it, so you (and everyone else) will not do others's work.

Your problem with the first group seems to boil down to the problem that people have different motivations. The sad truth is that this is going to be true in every setting, throughout your whole life. People always have different expectations of what they need to put in, and what they want to get out of a project.. What you need to do is learn to acknowledge that fact, and work with it. There are several ways of doing this. One of the easiest, though perhaps least fair, is (as was already suggested) to assign the work based on how much each person is likely to do. The problem with this is twofold: how much motivation someone has is is fairly hard to judge accurately, and it can foster feelings of resentment in those who have to do most of the work towards those who are (relatively) coasting.

One thing I liked to do with groups in college, which admittedly is not for everyone, was to have periodic meetings. At the end of each meeting we would decide what we wanted done by the end of the next meeting. We would then partition the work that remained (not just that which we wanted done by the next meeting) among the group members. Everyone was encouraged to do as much of their assigned work as they had time to, but there was no penalty except the ire of the rest of the group if they didn't.

So far this sound like how almost everyone does projects, but here's the catch: we made a deal that no one could leave a meeting until the work that was expected to be done by the end of that meeting was done. If everyone did their assigned work, then meetings were short. If no one did it (as happened sometimes) meetings would go into the wee hours of the morning.

This system worked well for us for a few reasons.

1) Everyone got to do as much work (individually) as they wanted. 2) Everyone ended up doing a portion of the work. Those who had difficulty motivating themselves to work on their own got to do their work with others there to goad them into getting it done. 3) Since everyone ended up working together on large portions of the project, no one felt like anyone else was free-loading, as we all saw everyone else doing at least some work. 4) It was very easy to consult with other group members if there was a part you didn't understand, or had difficulty with. This also lent our documents some flow, as they ended up being done mostly in the same style. 5) Most importantly, the work always ended up getting done.

I'm not saying I've solved the problem, that this is the be-all end-all solution to how every group should work. The point of this post (if there is one) is to say that every group needs to acknowledge the fact that motivations differ among group members, and to find a system to deal with that. If my solution is the one you feel would work best for your team feel free to use it, but if not, get to work developing your own. If you and your team acknowledge and work around the problem, your teamwork will be much more harmonious, and will produce results of much higher quality.

I have quite a bit of experience racing sailboats, in roles including skipper, tactictian, and trimmer/regular crew. I have raced with novices and with experienced crew. The single best predictor I have found for success at teamwork is that everyone is interested in winning (in a way that typical students may not be interested in doing a good job on a school project, even one that closely resembles a real world project). If my crew want to win, they will follow my instructions, even if they are inexperienced they will accept my coaching (or better yet, my more experienced crew will coach them and take the cognitive load off of me) and still do a good job. Given that, the most likely obstacle is too many leaders though I have been in several races where we solved that by just letting one person be in charge for the race even though several of could have done that job.

I took an interesting computer science course in high school... Grade 11 was exactly what you would expect from a comp-sci course, and by the end of it all of us were fairly fluent in two languages, but the second year was quite different. In a group of about five students, we were given problems to solve (like how to delete a node from a binary tree and rebalance it), had to develop an algorithm, and then learn how to implement it in a language none of us had used before. Our teacher knew that we could all follow instructions and learn from him fairly well. But the hardest part of programming for real is that you are eventually going to be in a situation where you cannot finish a project on your own, and every single person is going to have to be committed enough to learn a language and get their code in on time or you will fail.

We were a fairly typical group of high school students, so you can probably guess how successful we were at first. I was the only one who cared about learning the material, and did not have much I could do to get the others to cooperate.(being two years younger never helps) Eventually, I just had to make it work by studying harder, and telling everyone in the group that if they did not finish their part a week in advance, they were on their own. The people who didn't work hard failed, and those of us who were left eventually got much better at coordinating and working together. I don't think teamwork ever gets easy, all you can really do is give people an incentive to work hard and take up the slack for anyone who doesn't.

I don't know where else you could take a course like mine, but it definitely helped :p

I have this problem, and I've gotten to a place that works for me. Most times, the project is small enough that one person can do much of it easily, in which case I say that I'll do it and then split the work with anybody who objects. Other times, I ask, "who wants to do part X?" and all the parts that nobody picks up I do. I make sure that nobody has more work than they want, and I check in regularly to make sure people are doing it. Tip for this: people are less likely to mind my checking on them if they can see that I've already done my part.

.

Post and comments seem useful for students and teachers, but I was hoping for hints or links for teams of motivated adults. The teams I've been on mostly produce scientific publications (original research or reviews). Some observations: 1) work doesn't need to be divided equally, so long as each team member makes an essential contribution, but major contributors need to get more credit; 2) "you do most of the work and we share credit" can work if the one doing most of the work is essentially an apprentice (e.g., a grad student or postdoc) -- it's understood what the roles were -- but maybe not for two people with similar status; 3) two (or maybe three) people can brainstorm effectively without needing much structure; 4) big teams are tricky; if one or two people do most of the work with small contributions from many others (each getting a little credit), that seems to work OK. But I would have no idea how to organize a project that took major effort from more than 3-4 people; 5) email works OK, especially with collabators many time zones away; I always wonder about shared-screen-plus-audio tools, though.

I may have missed it, but it didn't really seem like you explained why you had the problem-of-a-different-sort. Could you elaborate on this? You go into far more detail about the first type of problem, when you think your standards will be higher, when you care about the outcome more than the others, etc. (type #1).

But you kind of gloss over the second (type #2), simply admitting that it happened.

It might be helpful for you to reflect (or if you have, add it to an "Edit" section) on why when you were in a type #2 situation that sounds like pretty much what you dream about when in type #1 situations... you seem to have produced the tangible results of a type #1 team member.

I clarified results as tangible, as I am saying nothing of your internal state, what you would have said if you asked whether you thought the outcome was important, whether you cared, etc. What I'm saying is that the output you fear/loathe from others in type #1 situations (not much in the way of contributions, little interaction, procrastination) might not be discernible from your actual output when in your desired type #2 situation, at least to a removed observer.

Have you thought about why that is?

Some tips from my life:

Try and get everyone to have the same goal. This helps everything else, and gives a reason for the group to get together.

Try and find people's strengths and motivations. Some people will do more work in a certain area than they would in another. Some people will hate doing one part but love a different one. Playing to other people's strengths helps everyone do a better job, as well as making individuals feel more responsible.

Sometimes people just don't know how to start. If you give them tangible guidelines then it takes a lot of the cognitive load off of them. On the other hand, it eats more of your attention that might need to be spent elsewhere.

Hope that helps.