0

My company has an agreement with a local University that every year we'll act as the customer to a team of students and get them to deliver a relatively small, simple software product to us. Our job is basically to tell them what we want, and help them out along the way by clarifying our requirements and answering other questions where appropriate. We set up the sprint schedule and hold meetings with them. We don't manage them as a team or develop alongside them (unless there's an emergency); the most development interaction we have is doing code reviews.

I've been involved for the past two years, and have taken on a more prominent customer role this year.

The issue is that there are some members who are clearly not pulling their weight and are slowing down development, while others are trying hard and are much more engaged. As above, it's not my job to actively manage them (in fact I got explicitly told not to do this); that's done by a student project manager, but soon I will have to give feedback to the team as a whole, which affects their grades. I'm finding it very difficult to give feedback to the team overall because of the aforementioned issue with individual team members. It seems unfair to give an 'average' score to the team when I feel that it doesn't accurately reflect the individuals' contributions; the ones who tried and were engaged will get less than they deserve, and the ones who didn't try will get a free pass.

In this situation, I feel like my hands are tied, and I'm not sure how to best proceed.

Improve this question
3
  • Presumably the real purpose of this arrangement is not to give you influence over individual grades, but so that you can cherry-pick the best performers for later recruitment?
    – Steve
    Jan 16, 2021 at 10:14
  • @Steve possible later recruitment is a factor, but we do also influence the team's grade. I'm not 100% sure but I think the grade is calculated using some combination of our feedback, peer-assessment within the team, and assessment from University lecturers. As such, we don't decide whether they pass or fail, but we do have a significant input (presumably 1/3).
    – Touchdown
    Jan 18, 2021 at 10:45
  • Yes I followed that you influence the team's grade. My point is that you are still expressing concern about differentiating between individuals. My suggestion would be to just rate the performance of the team as a whole - don't try and break it down into an average of individuals, instead ask, did the presence of the stronger performers compensate for the weaker? Was the product delivered on time and of good quality? You do not need to concern yourself with the individual contributions. Believe it or not, many real teams have a mix of both stars and mediocre members.
    – Steve
    Jan 18, 2021 at 18:29

2 Answers 2

Reset to default
6

Well, you said it yourself, it's not your job.

Do what is your job and give them feedback what went well and what did not. Do not put any blame, do not name any names. If you have tickets/issues/features that had lots of errors, or were late, name those. If other tickets/issues/features worked well, name those, too. You don't have to assign a blanket number, you can put different numbers on different parts of the project.

If they happen to internally connect the dots between persons and tickets/issues/features and what they do about it is their job. You were told not to do it and you don't have all the information to do it properly anyway. Your perspective might not be their perspective. Who knows, Alice, who always seemed so absent, may have done all of Bob's algorithm work, while Bob spent all the time talking about features. Maybe Bob who always talked a lot in the meetings and always checked in the great code, actually had Charlie over to go through that code with him step by step, because he'd never be able to do it alone. Point is, you don't know. So don't try. Especially not if you were specifically asked not to.

Anecdotal evidence, that nobody but the team can decide who is and isn't pulling their weight: There were two programmers on my last team. One was very diligent, did a great job, tested their product until it worked flawlessly and once released rarely had any problems with it at all. The other was sloppy, did not test their code sufficiently, did not take any advice and would deploy it despite known errors. The sloppy one would frequently be called up to fix production bugs in their product because their code would blow up multiple times a week. Guess what management saw? They saw one person who was never around to help when the situation was critical and they saw one person who was constantly doing overtime and weekend shifts, always hectic, always concerned about production bugs, always fixing bugs. Guess who they praised as being a good worker with a good work ethic? Certainly not the person whose software had 0 production bugs. No, to them, the person coming in on Sunday morning fixing a production bug was the hero. Because they did not know how that bug came to be in the first place. So... do not try to judge a team from the outside.

Improve this answer
0

Have a meeting with the project manager prior to giving your feedback.

There may already be peer assessment and other grading structures in place.

Improve this answer
1
  • We have to be careful doing this; I also got told off by the students' head of department when I got 'too involved' with the project manager. Basically we can say what we'd like, and we can try to influence their decisions, but we can't tell them exactly what to do or how to manage themselves. There may be a peer-assessment structure in place; I suppose that's some reassurance for me.
    – Touchdown
    Jan 15, 2021 at 10:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .