How do you deal with under performers?

Take examples from life sciences. Look at things like a trained botanist looks at things in a forest. With that perspective, a forest transforms from an idyllic little haven to a savage battlefield. Trees would fight their enemies with ruthless efficiency for every square inch of precious access to the sun. Bushes would be relegated to the leftovers, and moss and grass on the forest floor are forced to subsist on even less sunlight than that. Young, light-green plants would tirelessly invade the territory of their older, dark-green rivals, never ceasing the effort to starve them of energy. Seeds and spores would invent ingenious mechanisms to cover a wider and wider area than their opponents.

It is your job to point out underperformers in the team to management. If you do not do that, the overall performance of the team will come to question. At some point or the other, it will impact your career in bad ways. Get rid of underperformers, and fill the team with efficient people. Pruning is important. Both for plants and in teams. For plants, unless you cut down the dried up branches, new growth will not happen as quicly as it can. The same principle applies for teams as well.

When one of your teammates is doing an inferior job, and if that is going to reflect on your performance, it is your duty to let people know what is going on. Trying to protect the person doing the inferior job is going to harm you in drastic ways.

This is a delicate question. As a Senior Software Engineer, you’re not typically the direct manager responsible for formal performance reviews or disciplinary actions. However, you are a leader and mentor on the team, and your actions can significantly influence team performance and morale.

Here’s how to answer, emphasizing your role as a supportive peer and technical leader:

“That’s an important aspect of team dynamics. As a Senior Software Engineer, my approach to dealing with someone who appears to be underperforming focuses on understanding, support, and then, if necessary, appropriately raising concerns.”

  1. Seek to Understand (Privately and Empathetically):

    • “First, I try to understand the situation without jumping to conclusions. Is there a specific technical area they’re struggling with? Are the expectations unclear? Are they facing personal challenges (though I wouldn’t pry)? Is there a mismatch between their skills and the tasks assigned?”
    • “I might observe their work, look at their contributions in code reviews, or notice if they seem stuck or disengaged.”

  2. Offer Support and Mentorship (Your Primary Role):

    • “My initial approach would be to offer support directly and privately. I might say something like, ‘Hey, I noticed you’re working on X, is there anything I can help with or clarify?’ or ‘How are you finding task Y? Let me know if you want to bounce some ideas around.’”
    • “I’d offer to pair program on a challenging task, help them debug, or explain a complex part of the system. Sometimes, a bit of targeted guidance or knowledge sharing is all that’s needed.”
    • “In code reviews, I ensure my feedback is constructive, specific, and kind, aiming to help them learn and improve.”
    • See Provide and Seek Technical Mentorship and Guidance

  3. Provide Clear, Constructive Feedback (If Appropriate in Your Role):

    • “If I see a consistent pattern, I might offer specific, constructive feedback privately, focusing on the work rather than the person. For example, ‘I’ve noticed in a few recent PRs that [specific technical issue] has come up. Here’s a resource/approach that might help improve that.’”

  4. Check for External Blockers:

    • “I’d also consider if there are external blockers or team process issues contributing to the underperformance that I could help address, perhaps by clarifying requirements or improving documentation.”

  5. Escalate to Management (If Necessary and After Your Efforts):

    • “If, after offering support and guidance, the underperformance persists and starts to significantly impact project timelines, team morale, or deliverables, then I would feel it’s necessary to discuss my observations with our tech lead or manager.”
    • “When I do this, I would focus on presenting objective facts and specific examples – ‘I’ve observed X, I’ve tried to help by doing Y, but Z is still the outcome, and it’s impacting the team in [specific way].’ I would share the steps I’ve taken to try and help.”
    • “It’s then the manager’s responsibility to take formal steps, as they have the tools and authority for performance management, like setting up a performance improvement plan or providing additional resources.”

  6. Maintain Professionalism:

    • “Throughout this process, I’d maintain professionalism and avoid gossip or complaining to other team members. My goal is to support the individual’s improvement and the team’s success.”

Key Takeaways for Your Answer:

  1. Empathy and Support First: Show that you’re not quick to judge.
  2. Action-Oriented (within your role): Describe what you can and would do (mentorship, pairing, constructive feedback).
  3. Boundary Awareness: Clearly indicate when you’d involve management, acknowledging their role.
  4. Focus on Facts and Impact: When escalating, you’d provide objective information.
  5. Team-Oriented: Frame your concern in terms of team success and project goals.

Avoid:

  1. Suggesting you’d take disciplinary action yourself.
  2. Sounding like you’d ignore the problem.
  3. Complaining or being overly critical.
  4. Jumping straight to “telling the manager” without trying to help first.

This approach shows you’re a responsible, supportive, and proactive team member who understands their role within the team structure.

Links to this note