Lack of Production From Team Members

Started by
6 comments, last by Gian-Reto 9 years, 5 months ago

Ok, I am going to try to explain a situation I am in right now, and attempt to get some advice on how to handle it. This will be a pretty long post though...

About a month ago in my Software Development course we were given a big group project. After talking to the person playing as the "customer" (basically just describing the system he wanted and we had to figure out what he wants, requirements, and all that) to figure out what to do we went around and talked to everyone in the class to figure out our team. I took this seriously and didn't just pick random people and chose people that had different expertise but complemented each other (i.e: front end, UI, and back end stuff). We had our team and everything seemed great after talking and telling each other what we were good at.

We got together again not to long afterwards to discuss the technology we would use. After discussing it, and figuring out what the back end programmers wanted to use, I saw I was the only one who did not actually know it (ugh...PHP...I still hate it) nor really never really wanted to learn it. No problem, I didn't want to be the weak link in the team, so that weekend I spend the entire weekend, along with my other school work, using it and knowing how to use it so I felt comfortable with it. Couple days after that we got together again and the back end people started to layout what we wanted to do first. I was anxious to get started so I actually went ahead and said I would get some base code started up and get to work on the initial system. Needless to say here we are about a month later and I am still the only back end programmer to have done any work. It's been me working my butt off with the other team members working on the front end to work on connecting everything. That's been going great and we have great communication with each other. Nothing to complain about there. Though we still meet every couple days (mostly all of us) to talk about where we are at. Well the other back end programmers show up sometimes and sometimes they do not. When they show up they act like they are ready to get going but they haven't done anything yet. So me and the lead front end person were talking the other day about it. We went ahead and gave them some tasks for them to complete and they agreed and seemed excited to get going. We meet today and we find out they have nothing done, then left the meeting early.

So here I am now the lead programmer using technology I do not like nor wanted to use (but to be a team player I didn't complain and studied my butt off to not be the weak link). I'm actually fine with that. Though we also have documentation we have to complete and turn in on certain dates. The lead front end guy and I got together and worked on some of that then told the rest of the team we needed it to complete. Now we are getting complaints from the two members, who haven't done a single thing on the project, that we asked them to complete the documentation. The lead front end guy and I have pretty much just stood up and said we are not going to do anymore documentation as their is just absolutely no way we can manage all the code and write all the documentation with zero help from the two people doing nothing.

We've tried bringing it up with them and they "apologize" and say they are going to get started now and seem anxious. Nothing still. I, and the lead front end guy, have no idea what to do now. We are stuck waiting on them trying to finish their tasks we assigned to them, that they still haven't started, that I am pretty much about ready to just say "I'll just all the back end code, y'all just make the documentation look good!"

Anyone have any suggestions on what to do here? Because right now when we do the peer review of each member on what the contributed to the project we flat out can't give them anything, except for the little they have done with the documentation.

Advertisement

I do not intent to offend , so read with care wink.png


So here I am now the lead programmer using technology I do not like nor wanted to use

You are the lead coder, but not a leader. tongue.png

Often motivated, skilled people tend to fall into the 'I'm the only one who is skilled enough to safe our butt right now' trap. This is, they have a very high expectation for delivered quality, which most other team members are not able to provide. This leads often to the sitution, where these skilled people do all the challenging stuff themself and leave the rest of the (boring) stuff to the rest of the team, which is "lacking" the skill to master the challenges.

This has a very high potential of destroying the team motivation !

If you want to motivate your team, you need to learn to hold back, to delegate challenges to other member, to accept, that others need to learn by failure, to support them, that a good team performes much better than a single, skilled individual. This way you might build a good team ambient,in which, over time, others will accept your expertise and will willingly change challenging tasks for more boring stuff.

Ask your professor if you're allowed to fire people/hire new people. If so, fire them, or give them a deadline for finishing their work (early, with enough time for you to do it all if they don't) or else be removed from the team and receive no credit.

They're not self motivated, and it sounds like they're not doing anything very useful, and instead just hurting morale.

You may also be able to find replacements from another team that isn't doing well, but don't bank on that. As the leader, you chose bad people (a bit of bad luck there): you may have to suck it up and finish the documentation yourself.

A grade is equivalent to payment, if they can't bear this tedium, they won't get far in the professional world.

The original post was too long and I have to head off to university now. You have students who aren't doing their work, you say... quelle surprise! Your team does not have a leader or project manager (aka producer), or if it does, it doesn't have one who's doing his/her job. Somebody needs to step up and bring order to the chaos. Sure, talk to the professor. But also talk to the entire team. The members need to be reminded that their grades depend on it. Remind them that having a project is good for the portfolio. Point out that after graduation, the dependable people are the ones who'll be recommended by teammates for jobs.

Gotta go. Sorry for the brevity.

-- Tom Sloper -- sloperama.com

I question why you come to "us" for advice. Believe it or not, this is likely to happen in the industry as well, and it's a Producer's job to handle this. If your team had a leader, it would be better. Whether you're up to the task or not is relevant, but it is also a good moment to learn about what it takes to "make stuff happen".

You could put all of the best coders in the world together and get nothing done, if they don't have a clear direction, and clear understanding of what is acceptable or not.

Back during my studies, I've had to deliver programs I had done alone because team-mates were slackers. I never complained because I told them about their inexcusable attitude, and, upon delivery, let the teachers know about it. On a few occasions, I've had special treatment because I delivered 75% of a functional software despite being the single acting team member in a team of 3 (where I would've been expected to deliver 33% of the functionality).

It sucks, but that's life, not everyone is born with a professional mindset. Some people approach "work" with the "40h/week" mindset, and others approach work with a mindset that involves "Am I proud of what I've done today?". This simulation is a perfect time for you to understand the difference between having the right skills and the having the right attitude. When often hire junior programmers over senior ones just because they have more passion for their work. Nearly everyone can get better at coding, but very few can actually change their pre-disposition to work.

Being a CS student myself this has happened plenty of times to me.
- Let them know that they have responsibilities to the group, and they have to do their part. Mention it once, maybe twice, and leave it at that.
- Let your professor know that they didn't do their part (keep minutes for meetings and/or a log of what everyone worked on)
- Do not fall behind. There is a set deadline for when your project needs to be finished. If they're not working everyone else has to pick up the slack so your group doesn't fall behind.
Sorry to hear about the unproductive team members, I feel for ya

You are the lead coder, but not a leader... Often motivated, skilled people tend to fall into the 'I'm the only one who is skilled enough to safe our butt right now'...
This has a very high potential of destroying the team motivation!...If you want to motivate your team, you need to learn to hold back, to delegate challenges to other member, to accept, that others need to learn by failure, to support them, that a good team performes much better than a single, skilled individual.

QFE, don't discount this advice. In younger days I have been the perpetrator and the victim of this working style, and neither time was I very satisfied with the result. You cannot expect morale to remain high for the whole team when a minority of the team took ownership of the project early on. It is not their fault as much as it is not yours and as much your fault as it is theirs -- but nevertheless, there is now a situation where only you and the front-end person (people?) are invested in the project, and there seems to be no challenges left in the project for these others to find value in. They're probably thinking "At this point, I can coast through with a C by only doing enough to not get kicked out, or I can work my butt off doing the boring remnants and maybe get a B." I suspect you would not be motivated by that either.

Your problem is not productivity, its morale. Attacking it as a productivity issue will not solve the problem. Being older and wiser now, I would approach my past situations like this -- set aside any feeling of superiority or indignation, acknowledge that there is a morale issue stemming from a lack of ownership by all team members, cede some of your remaining *interesting* feature work to them or find new features for them to own, split documentation and other "boring / busywork" tasks across the team.

Remember that in this setting there is no hope of promotion, which is usually what enables people to endure more menial tasks in their professional career -- here, to keep the team happy and productive, members have to share in both the interesting and menial work.

throw table_exception("(? ???)? ? ???");

What others already mentioned, plus my own expierience:

Most students are lazy slackers. Sad truth, comes from my own expierience. I also wasn't always as productive in my CS studies as I should have been, altough I never slacked off during team work. That, to my eyes, is just mean to the people that actually do care about the project and the grades.

But different people have different ways to look at the same things, and what Ashaman73 said in the first post is a good example. It could be that these people could tell you something YOU did wrong.

No, scratch that, you should ALWAYS at first try to find out what you did wrong. Be upfront with the guys, ask them why they have not delivered yet and what you can do to help them. There is a chance that these guys were either offended by your attitude (not very preofessional, but this is university after all, so don't expect it), or they have other problems they were not upfront about (maybe they have work in the evening just to afford their studies, who knows?).

Maybe, as Ashaman73 wrote, you yourself were acting as Lead Programmer, but instead of leading the team you were doing everything yourself....

On the other hand, chances are these lazy slackers are just trying to get through an assignment the easy way, leeching work from other people. Make SURE you have given them all the second chances they deserve, you talked to them as honest as you can be, and really analyzed what you could do better yourself.

If nothing of this helps, shoot them down. If they cannot deliver without good explanation, they probably never will. They are a burden to the team, and to be honest, you should not let them profit from achievments that are not theirs.

But always try to learn yourself from things like that. There always two sides involved, and not matter how lazy slackers they are, you most probably could have done something better.

And that thing might just be to pick your team members more carefully, or spot the slackers earlier and follow up on their non-delivery in a more timely manner (asking for problems or reasons for not delivering earlier, reminding them about their tasks sooner, or firing them from the team before its almost too late).

As a last note:

The insistance on having their way with the backend language should have alarmed you.

I know there are some people that insist "I am a Java Expert!" or "I am a Database Specialist", and if you even ask them to do what is basically in the job description like to commit their Database code to Subversion or writing the needed Unix shell code to wrap their Java code, they insist that this is not their Job. Now, these guys are ****s, but given that they have enough expierience, and the boss has a high regard of their expertise, you will have to put up with them. Hell, they might even be such geniouses in their area of expertise as they claim (though that does not mean they should be ****s to all the people around them).

Now, we are talking about CS students that are pretty much at the start of their career, before you could even talk of them as "specialists"... if there is one thing you should get in University (apart from the skill to learn new things in a timely manner), its being exposed to as many languages, paradigms and needed "fringe skills" as possible. University is not the place to specialize, you do that later on the job, or when doing your PhD or whatever.

As such, if a student complains about a new language (like you did about PHP, obviously without evn trying it), its all fine and dandy. We all had that (learning C++ in university was PAIN. This was down to the stupid way our professour taught it, but still... one of the only languages I was NOT looking forward to learning... fast forward some years and I am actually enjoying using it :)). We all have it still from time to time, even as professionals.

Now, there is a big difference between saying "Ugh, PHP... well, if it has to be that" or saying "It has to be PHP, because...." (followed by either "... I am already proficient in it", "... else I will not participate", or any other bollocks). The second one shows clearly that the person is not only not willing to learn something new, he is insisting on it with a high degree of probability because he is too lazy to learn something new. If he is too leazy to learn, he is most probably also too lazy to deliver something in an assignment.

This topic is closed to new replies.

Advertisement