How to manage a team member who doesn’t like the project

When you lead or manage a team, you need to create close connections with the people who are part of that team. This means building trusting relationships for both working and real life moments. When you have good, trust based relationships with your team it’s easier to fulfil your own role as a PM. That role includes noticing when one of the team members has conflicted feelings about the project, which can affect their work.
I’ve had cases where a team member’s personal dislike for a project manifested itself in very unusual ways! That’s why I’d stress that if you notice something strange in your team, it’s worth tackling it as soon as possible.

Danger signs that a team member doesn’t like the project

Each individual responds to their feelings in a way unique to them, but there are some common patterns which it’s worth keeping an eye out for. Here are a few signs I’ve noticed which might indicate that someone’s not happy with the work they’ve been assigned to:

  • They seem visibly upset and sullen for a long time (i.e. it’s not just a passing bad mood, it’s ongoing over days or weeks)
  • They get cranky, or respond in an aggressive or disproportionate way when approached with questions about the project
  • They’re constantly tired, sleepy or irritated
  • They try to delay deadlines by complaining that the tasks they’ve been given are unclear
  • They’re constantly late and take a lot of long tea breaks
  • An especially bad sign is when someone says something bad about a client and spreads a culture of disrespect
  • The programmer is experienced and responsible but for some reason they seem to make significant mistakes in one particular project
  • They’re inattentive to detail and rush through tasks without fulfilling them properly
  • At team meetings they draw back, display open boredom or even sleep!
  • They make inappropriate jokes about the project
  • They use test content which makes a joke of the project, demonstrating their disrespectful attitude towards the project as a whole
  • They close in on themselves and become less communicative
  • They seek out opportunities to help other programmers with their tasks too often, so as to spend less time engaging with their own project

As you can see there are many different indicators that can show someone’s unhappy. Perhaps you’ve spotted some more in your own workplace that I’ve not listed here. The most important thing is to notice when someone’s behavior changes dramatically and you feel a tension when communicating with them.

What can be done?

Once you’ve noticed the problem, it’s time to do something about it. The first step has to be a conversation with the team member in question. This isn’t necessarily a dressing down or a telling off (though it might be). You want to be honest and frank about the problem in such a way that they open up and talk “heart to heart” about how they’re feeling about the project. There’s no room here to be offended or for your own ego or emotions to take over, you’re simply trying to understand the problem fully so that a solution can be found. Usually when given an opportunity to open up about what’s bothering them it doesn’t take long for the real problem to come to the surface.

A wide range of problems

I’ve encountered some very varied reasons why people might withdraw from a project, here are a few that have come up:

  • The person hadn’t had a vacation for a long time and was approaching burnout. They needed to take some time out as soon as possible
  • The PM had inadvertently hurt the person by saying something careless during a team meeting. Having it happen in front of the rest of the team had especially turned them off of the project
  • The nature or content of a project made them uncomfortable. E.g. a male programmer had issues working on a site for selling and promoting beauty products
  • There was a conflict with another member of the team and this was concealed
  • The programmer had to work with someone else’s code. This is not uncommon and shouldn’t be a problem, but out of perfectionism, some coders really want to write everything from scratch, even though there’s no time or money available for this work
  • Sometimes a person just feels under appreciated. They need to be praised for the work they do, perhaps openly, when other team members are also present.

Finding solutions

With some of these problems, there’s an obvious solution which when implemented means that everything can go back to normal. In other cases, assuming that the employee’s problem is genuine and that they’re otherwise a valuable part of your company, it may be necessary to look for an opportunity to move them to a different project. Ultimately, frank conversation and faith in your employees ability to recognise the ways they produce their own best work are your best tools for managing this situation. Crucially, you should never just turn a blind eye to matters like this; your team are all in the same boat, you either sink together in the case of a project fail or succeed together with a successfully completed project.