Student Team: How to deal with slackers

Question

I'm a software engineering student and as the course name suggest, we make software in class (duh! :D) We usually end up grouped into teams of 5 in building projects... But in the end, it's like I split myself doing 5 people's work instead.

Problem 1: Team mates don't know anything... at all

These guys don't listen in class, and by "skip counting" or "raffle" I end up with them. Some are willing to do the project, which I tend to concentrate in helping (because they show up in meetings). I try to explain in simple terms, with diagrams and all, but they still can't grasp the concept of the project.

Problem 2: Not meeting deadlines

True that we have our other deadlines, but deadlines should be deadlines. I usually hold my end of the bargain, but the others usually don't. They usually say "I can do that later. The project deadline is still 2 weeks away. Why rush?". This happens, and then everything piles up near the deadline.

Problem 3: Total dependence on me

So they don't know how to do it (but I do), they delay everything to the last minute (but I don't). When they realize that they can't do it, they turn to me because I know how to do it, and I have nothing to do since I'm done with my end.

Note that I have tried to explain to them what to do before starting off.

Problem 4: "Rockstars" and Hot-air balloons

Some of these slackers are, unfortunately, "rockstars" and show-offs which do code their way (think of globals and single-filed C code) and talk a lot but can't do a thing at all, respectively.

Problem 5 (I promise, this is the last): They are not afraid to fail

I may not be a dean's list candidate, but I am afraid of failing class. But my team mates? They accept failing. In fact, they fail at least 1 class a semester. A failed class would be like a walk in the park for them.

In the end, I usually end up doing everything and the one who has barely slept in days. We usually get rated as a group, and if they slack-off with their module, all my hard work goes to waste because of these slackers.

How do I manage this team, and straighten them up? Currently I am in at least 2 teams that happen to be like this (the others team-ups are still under observation).

Answer 1

Group projects in school always kind of annoyed me primarily because I was being graded on someone else's failure or success. This is often explained away as "simulating what it would be like to work in a team environment". They're not wrong. Once you enter the business sector, you will often be placed on a team, and you will run into these same problems. However, in getting my own degree I decided I wasn't going to fall victim to anyone else's nonsense.

Problem 1: Team mates don't know anything... at all
You will always have these individuals whom I refer to as "dead weight". They mean well, they try their best, but in the end they simply will never measure up fully. Whenever I was saddled with one of them, I tended to look at it in a business context. Most of the time they tend to be very hard working and dedicated individuals who will follow instructions beautifully. Use them as such. Give them guided work and explicit instructions. Take the leadership role they are not prepared for and get the most work out of them that progresses the team.

Problem 2: Not meeting deadlines
Another business topic for which there is no excuse. The difference here is that in school you're not being paid for it (grades maybe, but some people just don't care if they get a C). It's not as important to them as it is to you. You'll find this in business as well. This is more dead weight, and you need to be prepared for it. In business, often a team member will be "thrown under the bus" for not meeting objectives. In school this just doesn't fly. You need to identify these individuals and "count them out". Do their work for them, keep it behind the scenes, and when the individual doesn't come through you'll still be prepared for a good grade. It means more work for you, but you will almost never get a failing grade for completing the work. When I got my degree, I didn't have time to waste on people who were wasting it. I did every aspect of a project solo. When my teammates held up their end, I tossed my extra work aside. When they didn't, we still passed. The problem it's caused for me in business is that I tend to adopt the same attitude when I identify these individuals, and so I do more work than I should have to (and some of it gets thrown out).

Problem 3: Total dependence on me
Stop giving them answers. Teach them how to find or divine the answer for themselves. Ask them what they've done, where did it lead them, what does the research tell them. Lead them to the answer and after a couple of tries they'll start figuring things out on their own.

Problem 4: "Rockstars" and Hot-air balloons
You won't ever get past these individuals. It took me a year to crack one I met in the business world. In school you don't have a year. I treat these individuals as if they weren't doing their work at all most of the time. That way when their pieces fall short, I have a backup plan. In the business world, we do team level peer reviews designed to teach technique, refute assumption and change habits. "Rockstars" tend to become kittens once they realize their work must withstand scrutiny from a group rather than an individual.

Problem 5: They are not afraid to fail
Hard work and dedication to your goal is the only thing you can guarantee. If you can't get good team members on group projects, then you must assume the responsibility for yourself to complete your goal. In the business world, there is generally recourse through management when something like this occurs. In school there just isn't time. Be true and committed to your goal, and no one will stand in your way.

This is your chance to learn leadership and direction. You don't need to "manage" them, you need to lead them. You won't make friends of them, and frankly if your goal is a degree then there is no room for friends. Set goals and expectations and hold people to these goals. Make sure everyone knows about these expectations. When they aren't met, announce this to the team. Don't become angry about it, don't plot to get even or to shame anyone explicitly. Fill in the gaps yourself, and get the job done. Sure, someone else will earn a free grade off your labor, but should that really concern you? The group project is temporary, but your continued success will always be there. Their failures will begin to pile up on themselves eventually.

This may back-fire on you. I had people in school who would request to be teamed with me because they knew it was their chance to slack. What they weren't prepared for was my dedication to my goal and what it meant to let me down. I woke several people up after midnight a few times (banging on doors sometimes) demanding that work be complete. I made some people VERY miserable for not living up to my expectations. For those that did keep up and pulled their end, we became friends and tried to work together as often as possible.

The answer to your question ultimately becomes: Your level of commitment to your goal will determine your success. I achieved a 4 year degree in 2.5 years by taking a heavy course load and summer sessions. It all boils down to commitment.

Answer 2

I was in this situation when I was at college. Looking back now, with a good many years of development experience in various teams, there are some things that I wish I had done. The basic one is this:

I needed to be a leader.

Nobody else was going to do it, so I needed to take more charge and give the group direction. However, that doesn't mean that I had to do all of the organisational work- those people who don't know how to do anything with an IDE or text editor? One of them could do a whole bunch of contacting people and sorting out times to meet up, without having to know much about writing code. Delegation is a big part of practical leadership.

Also, making it absolutely clear who was responsible for what, helps everyone feel they have a role and helps to make it clear who deserves lower marks if the project works out that way.

Teammates who know nothing

May not make for great programmers, but they can still do a whole lot of work- you need documents, you need requirements gathered, you need testing, you may need custom icons for your application, you will want usability tests. In most software projects there are as many non-programming jobs as programming ones. Find ways to make the most of what they can do.

Not meeting deadlines

This happens- students are lazy. But one thing that might help would be to have a regular schedule of meetings where you have something like a Stand-Up, each person taking a turn to explain what they have done for the project since you last met, what they are going to do next and whether anything is blocking their progress. Ideally this would be daily but practically you may need to do it every couple of days. Keep a diary recording what everyone has said they would do and what they have done, so you can call people on it early if they are not taking part.

Dependence and Rockstars

Practically you are being a Rockstar in the real sense by writing most of the working code, but part of this task is to get people writing code together. You will benefit more if you can get some clearly defined interfaces and then get everyone who can usefully write code to write their own components in a black-box way, so you only have to interact with one another's code at those boundaries. If their code is horrible, it's not really your problem as long as it works. That way everyone has to be independent in their own way but they also have to be working with the team. You then need to get these integrated early ( half way through at the latest ) so that you can iron out problems and get things tested.

Useful ideas:

Divide And Conquer

A team project looks big and intimidating and it probably is - certainly at my university they worked us pretty hard for those grades. Split it up into the smallest chunks you can ( as a team ) and then divide those out and take regular and early rain checks on where everyone is at. A stitch in time saves nine in these situations.

Your team mates are brilliant

Remember that your team mates are all intelligent and able people. They might not be as good within your specialisation as you are, but with the right direction and encouragement they could do really well and you know what? They would be really pleased if they did. In my experience ( as a very lazy person ) most people don't enjoy being lazy or late or over deadlines. It's stressful and unpleasant and we would prefer not to do it. If you can help people to get things done so that the team stays ahead of deadlines and comes out looking good at the end of it, then you'll be very well prepared for a lot of things that life throws at you.

Your experience is common

Remember that your professors have probably taught these classes for years. They have seen these traits time and again in groups. Maybe you could talk to them about the challenges you face and ask if they have any tips. If you have people who just take no part in the project you could ask them about that too- they may be able to draw your specs in a little or suggest an alternative approach. After all, you are paying them to teach you, not to subject you to stress and sleep deprivation.

Answer 3

First thing you need is a little humility. I was the same way in college. It took some hard life lessons for me to learn and I suspect it will for you as well. But like those who wasted their breathe on me I will try and help you here.

The bottom line is you need a good finished product to turn in for your grade. Unless you are willing to accept the failure then you are going to need to put in more effort than you probably feel is your responsibility to get the job done. The good news is that in the process of getting the job done you will gain some valuable experience in working with a difficult team.

Problem 1, 2, 3 & 5:

This is probably the easiest for you to deal with. I would try and work with the person in question. Schedule time to work on the project and help them understand what they need to do. Many times the person you think doesn't know anything just does not know how to get started. Once you help them on the path they may surprise you. Otherwise they may have some other skill that will help you in the future. Hopefully working together to complete this assignment will help you find that.

In the worst case scenerio your assessment is correct and the person just doesnt care or is unwilling to put in any effort. Just do their work for you. Trust in Karma to claim its due later, and do not look back. Yes, they get a free grade off of your work but you get to move on with the skills that will serve you well in the future.

Problem 4: "Rockstars" and Hot-air balloons

This is your chance to learn a skill that will pay huge dividends for you in the future. How to succeed when you have to use sub par work effectively. It does not matter what field you go into, when you get to the real world you are going to be tasked to work with something that does not meet your standards. It is your job to succeed in spite of that. Take what they have and make it work. Yes it will be much harder to make it work than to just do it over yourself, but when you get to the real world that will not be an option far more often than you like. Learn to adapt and make it work now so that when you are faced with situations that actually matter you are able to handle it better in the future.

In the end, the best way to lead is by example. Put in the work that it takes to get the job done and do not let the project fail.

Answer 4

The unfortunate reality is that you will actually meet these situations in the real world. My memory of group projects in school (caveat: although I'm a software dev now, I have a degree in the humanities) more or less mirrors yours: most of the time, you got maybe one other person in the group who pulled their own weight and you basically had to resolve things between the two of you. That being said, here are the strategies that have worked for me in the past:

Assume you're going to do all the work

I realize that everybody's just learning the system, which in and of itself is going to ramp up the difficulty level right there, but chances are your professors aren't giving you something that's undoable. In fact. there's a solid chance that you just might be able to take on the whole thing yourself. So, delegate responsibility and all that but if guys aren't meeting deadlines, just fill in the work for them.

Don't think of this as doing someone else's work, think of this as taking advantage of the system. You want to be a great programmer? The difference between good programmers and bad ones is that good ones do a lot of it. Theory is nice and all, as is talking with other programmers, but at the end of the day the only way to really and truly learn about the process of programming is to just write a lot of code. On top of that, if you have a TA who will go in and critique the work beyond running a .exe to see if it works, that's, like, double the opportunity: if you write all the code, all the code review you get is stuff that applies to you.

Think in terms of Agile, or at least try to.

One of the tougher things about starting out is that you're only just aware of the concepts of coding (or maybe you're one of those guys who's been doing it since they were 5, who knows) is that you don't necessarily have experience with software development methods like Agile. You may want to look into how it's done (check out Scrum as well, which is kind of a submethod of Agile). Among other things, it tends to let you know early on who is going to help out and who is not.

A brief synopsis of some of the things that having an Agile-based mindset might lead you to do in a group like this:

• Conduct a "daily standup" between everyone where everyone talks about what they did in the last 24 hours and what they'll be doing in the next 24.
  • Get together to break down your project into smaller sub-projects and finally "stories" that each might take only a couple to few hours to finish which you can then dole out to everyone.
  • Go by a general philosophy that what you want to get off the ground first is something that meets the minimum requirements, and then, once you've fulfilled those, go back and add more features. Sometimes, yes, this does require you to go back and refactor some code you've already written, but a. this is what we do in the real world, and b. you'd be surprised at how often you don't have to do that.
  • Have periodic get-togethers where everyone can present their work to everyone else. Code review isn't necessary at this point, although if people are game to do that, sure. What you're really after at these points, though, is actual working stuff that everyone can look at to see if/how the different parts work.

Consider some sort of version control.

Even if this just means opening up a Github account, this is a really good idea. For one thing, as before it allows you to see really, really quickly who the slackers in your group are (additionally I know that there's a paradigm in college that says you can get away with doing everything at the last minute - that doesn't really fly with software development and this is a good point for folks to figure that out). On the flip side, if someone gets into a car accident you aren't left trying to explain that to the professor on the day the assignment's due if they've been checking their work in.

Also, and perhaps most importantly in your situation, version control actually gives you a bit of extra freedom to try new things that may or may not work out. Let's say you've put together that WinForms app or whatever that accomplishes the absolute minimum that the prof is expecting out of the assignment, but you get extra credit if you can write it in WPF. With good source control you can check out the UI, make all kinds of sweeping changes to it as you refactor it, and if you get boxed into a corner and it's Sunday night and the project's due Monday morning, you can always back out of your changes and go back to that version you know will at least get you a B.

That applies to all your colleagues as well. If you get a stable build and then someone breaks it, the worst case scenario is that you can always rewind to the last stable build. I think that has happened to all of us in the real world.

I understand that your colleagues don't know how to use source control. The good news is, it doesn't take that long to learn. The hour you spend helping them will pay you back in spades (if nothing else, you can use the check-in data as evidence that folks didn't actually do any work).

Keep a dialogue with your professor and/or TA.

I know, nobody likes to be a snitch, and if your dev program is extra small, it might suck to have to work with people in the future whom you've kind of sandbagged on this project. The way to avoid this is not to go by the maxim that "snitches get stiches", it's to constantly be in a dialog with your prof whether people are pulling their weight or not.

First up, if you're having issues with your part of the assignment, or if you have questions about the course material in general, by all means take advantage of your prof's or TA's office hours and hit them up for advice. It was my experience that teachers in college are overjoyed to have students engaged with the coursework. It's only natural, then, that the subject of your group dynamics may come up and you'll have the opportunity to talk about how only 2 people of your 5 person team are seeming to do any work. In fact, this may be an issue you can get advice on. Even if the advice is "yeah, we figured lots of groups would be like this, which is why we really only gave enough for 2 people to do if they're motivated", that is useful information.

You may not get any dispensation at the end of the project even if you've been complaining about this all along, but I will tell you this much: you are far, far more likely to get aid if the professor/TA is/are aware of these issues far in advance than if you drop this on their plate along with your assignment, or worse if you never tell them at all and they have to, say, assume that 5 people did the work over 3 weeks that one college kid could have done in one particularly harrowing weekend, and grade you accordingly.

How to profit from this experience.

Loyalty to your classmates may seem admirable in college but once you have a paying job that is the only difference between you paying your rent next month and going back to live with your parents, you will quickly find that your first loyalty has to be to yourself. You do nobody any favors to prop up a guy who is slacking or, what is worse in my mind (because the conversation is so much harder) a guy who tries but just can't cut it.

In fact, my experience, particularly with Scrum/Agile style smaller groups, is that very often you are constantly liasing with people who are not technically savvy, don't really understand what it is that you're doing for them, and just want results. Often these people are either signing your paycheck directly or else they report directly to the person who does. If you don't tell them that in your 5 person team (for instance), 3 people are goofing off or don't know what they're doing, they will assume that all 5 of you are slacking when you miss deadlines. Or, in the best case scenario, they'll be in no position whatsoever to recognize you for your 70 hour weeks making up for the work of the guys who aren't pulling their weight. Those people need to be cut so that management can hire (presumably) more competent people in their place or else, if things are too far along already, understand that they should expect a 2-person team level of results, not a 5-person team's.

It's not an easy position to be in, but software development isn't necessarily easy, and the need to be a bit on the ruthless side only increases as you get out of college.

And I know I said this before but it deserves re-mentioning: I know it sucks to feel that you have to shoulder the load here, but look at any situation where people are slacking as an opportunity rather than a bad thing. If you're in groups of 5, your prof has designed the assignment to provide you with a (relatively) small amount of work to do and a (relatively) small amount of feedback in return for your work. If you "have to" do 100% of a job you were only expected to do 20% of, you're getting 5 times as much of an opportunity to gain what athletes refer to as "muscle memory" - the innate knowledge of how to do what it is that you do that you really only get by doing it - not to mention 5 times as much face time with the prof and/or TA when the assignment is finished. You should pity these folks, not be angry at them.