Have you ever had to provide negative feedback to a struggling team member? It can be a really uncomfortable situation, especially if you don’t know how to approach it.

But as anyone managing even the most outstanding and high-performing technology team knows: Bringing together more than one person lends itself to occasional disruptions. And some of these disruptions can derail the project as team members get embroiled in disagreements and other issues. The result can be a failure to meet expectations—a disaster for everyone involved. As a team leader, you have to be ready to give the right kind of feedback when a team member needs it.

To help you out, here are three real-world scenarios that I’ve experienced and some of the key talking points that helped the situation (and the project) move along.

Scenario #1: The rogue report

The problem: Susan was an excellent HR systems analyst. She knew the HR system backward and forward and was an asset to the team. John was a software developer responsible for implementing system configuration changes. Susan was the configuration lead and John was assigned to support her. Despite multiple attempts from Susan, John had no interest in taking direction from a woman but would take direction from a man. When Susan would assign him a task, he’d ignore her request or speak to the men about the assignment instead. On one occasion, he bluntly told her he didn’t have to listen to her because she was a woman. It might sound like a dated scenario but these situations do still exist. (This also overlaps with scenarios a team member, for whatever reason, refuses to take direction from a manager.)

Diagnosis: Team member doesn’t understand the project roles and responsibilities and doesn’t respect the female leadership role or the manager.

Action plan:

1. Meet with each team member individually and listen to each person’s concern.
2. Meet with both jointly and raise the teamwork issue
3. Clarify roles and responsibilities
4. If needed, remind the reluctant team member that taking direction is part of their job responsibility.

What happened next: After a lot of back-pedaling and insisting that Susan didn’t understand him, John agreed to the role and started to perform better. He may not have liked the situation but once he understood his job was at risk, he quickly complied.

Scenario #2: The coder who can’t deliver

The problem: Ravi was a new hire to the project team. His resume cited a long list of successful software engineering projects and passed the technical interview while highlighting his coding experience with relevant examples. Two weeks into his assignment, Ravi continued to reference programming books where he was a self-proclaimed expert. He often stayed late and needed to meet with other developers for help. His coding assignments took longer to complete and the code quality was poor. Even the basic “Hello World” complexity-level assignments took a week to complete when it took others a few hours.

Diagnosis: Ravi bamboozled his way through the interview and really wasn’t as proficient as he claimed.

Action plan:

1. Gather the facts—coding assignment complexity, typical development estimate and code quality issues.
2. Meet with the team member and express your concerns.
3. Listen for feedback.
4. Determine if the resource’s skill level meets the needs of the project.
5. Provide additional training or replace the resource.
6. Review the technical interview process to ensure the issue doesn’t occur again (e.g., include an exercise or coding test).

What happened next?

After meeting with Ravi, he confirmed he wasn’t as proficient as he represented himself in the interview. His past experiences were gained while working with a stronger developer. He expressed his commitment to do “whatever it takes” to get the job done. Given the project timeline, it was clear the project needed a more proficient resource. Ravi was released from the project in pursuit of another opportunity where he could be successful. The project team absorbed his work and rewrote the code he was assigned.

Scenario #3: Meet Mr. Alt-Tab

The problem: Steve was a proficient developer. He was knowledgeable in systems development and understood the technology that the team was implementing. At the beginning of the project, he completed his coding assignments ahead of schedule and indicated he could take on more work. Halfway through the project, his performance slowed down dramatically and every time the project manager walked up to his desk, you’d see the screen flicker as he pressed the Alt-Tab key (which switches between top-level windows without using the mouse). CNN Sports scores and fantasy football websites quickly switched to the Eclipse integrated development tool that the project team was using to develop the product.

Diagnosis: Team member had potential but an Alt-Tab problem (AKA a focus or discipline problem.

Action plan:

1. Gather the facts and examples including code assignment productivity, team feedback, and Alt-Tab behavior.
2. Meet with the team member and express your concern.
3. Listen to the feedback.
4. Explain that you understand the reality of checking personal email and browsing non-work activities but the focus still needs to be on work.
5. Clearly set the expectation when checking personal email, sports scores, personal calls, etc. should be handed (i.e., lunch) and when team members should be focused on work.

What happened next:

Steve fessed up and provided some useful information. He admitted to slacking because the assignments were no longer challenging. He knew he was using the Internet more than he should be given the team’s development schedule. He committed to doing better and asked for additional assignments that would challenge him during the project. Steve was given another task that engaged him more, and his performance improved.

Do you have a similar story?

If I had more space, I’d regale you with the tale of the software developer who insisted on drawing data models on bar napkins over beers and coding in a dark room during the day. However, I think these examples provide enough fodder for discussion in the blog comments below.

Do any of these poor team member performance stories sound familiar? Do you have a similar story? Share your situation and action plan in Comments.

Your team can move mountains when they collaborate elegantly, intelligently and effectively. LiquidPlanner is a collaborative project management software that gives everyone on the team autonomy over their own tasks and insight into the big picture.