LTC#08 - Supporting a Low Performer
Hi, this newsletter is a weekly challenge for engineers thinking about management.
I’m Péter Szász, writing about my decades of engineering leadership experience on my blog, and training aspiring and first-time Engineering Managers on this path. See more about what I might offer you at leadtime.tech.
In this newsletter, I pose a weekly EM challenge and leave it as a puzzle for you to think about before the next issue, where I share my thoughts on it.
Last Week's Challenge
Last week, we looked at a struggling senior developer going through personal issues that start to impact his work performance. Read the details here if you missed it.
I'll frame my approach around these in three steps:
Goals: what I want to achieve in this situation;
Risks: what I want to avoid and should be mindful of;
56 Questions: what areas I want to discover to make the right decisions.
Goals
Execution: I need to stop the pattern of mistakes. Our team's work quality and delivery timelines are at risk. The recent production incident is a symptom of a deeper problem.
Personal: I want to support Ivan through his difficult time while maintaining appropriate performance standards. Understanding what support would actually help him is key.
Team: I need to protect the team from carrying an unfair burden, potential resentment, damaged external image, and above all, the risk of normalizing substandard work.
Risks
Execution: If I delay intervention, more mistakes will happen, negatively impacting the quality and performance of the products and services our team is responsible for. If I overreact, I might create a culture of fear, where people are reluctant to take risks, and mistakes are frowned upon. (See my thoughts on Celebrating Failure here.)
Personal: Ivan might perceive any intervention as a lack of empathy during his personal crisis, and pushing him too much might break him. On the other hand, ignoring performance problems could enable a downward spiral that becomes harder to address later. Any delay in actions sends two bad messages: that this performance is acceptable, and that I don’t care about him enough to recognise he’s suffering and offer my support. Altogether, the risk of losing a valuable developer is high if I don’t act promptly and with care.
Team: Ivan's struggles, especially after the incident, are clearly visible to the team. Not addressing it openly could suggest I have different standards for different team members, breaking trust and team cohesion.
6 Questions
(Yeah, I know this is usually 5, but I felt all of these are important to think about.)
How aware is Ivan of the impact of his actions? His reaction when turning off tests to meet deadlines - was it a conscious "I know this is wrong, but I'm desperate" decision, or does he genuinely not see the issue with his approach? In addressing performance problems, I always start with aligning on the problem itself with the impacted person. Do they see the problem? Do they agree that this is a problem? This alignment is a necessary prerequisite to move the discussion towards performance improvement. In this case, this can also make the difference between the need to support hard skills (testing philosophies) or soft skills (time management, focus, etc.) development.
Did I create a Culture of Safety? There are potential red flags in the story. If Ivan didn’t trust me before to share his struggles and ask for help, if he wanted to push through the pain and cut corners out of fear, without involving me, the person who he should trust most to give him the support he needs, then maybe I’m involuntarily sending signals that contradict safety and trust.
Do I truly believe Ivan can improve? It’s a tough question, but it addresses the key in supporting a low performer. Without this faith, it’s better for everyone to move things towards a clear closure, where Ivan moves to another role, team, or company. I saw a lot of people improve their performances from bad situations, but not one without the faith of their manager in their capabilities to succeed. On the other hand, many times I witnessed managers secretly losing faith in someone on their team, but delaying the inevitable unnecessarily long, therefore hurting the person, the team, and the organization.
What specific support would help Ivan right now? Often, people don't need a reduced workload but rather more structure, clearer priorities — or to the contrary: less structure and more flexibility in when, how, and where they work. Others might need temporary adjustments, perhaps more frequent pair coding or mentorship situations. Either way, we have to figure out together how the team and I can help him, and I should make him understand it’s OK to ask for help.
What’s the external impact exactly? The incident might be the top of the iceberg only. I need to check in with stakeholders, peers, and fellow teams to ensure there are no problems left undiscovered — and to enforce the message that we’re handling the issues.
How is the team experiencing this situation? Are they aware, frustrated, sympathetic, or taking on extra work to compensate (and hide the problems)? Is there someone else who needs my attention, but I can’t see them because I’m focusing on Ivan? Understanding the team dynamics helps me tune my approach and might lead me to discover other areas that need attention. Related, but Ivan might not be comfortable sharing all the details with the team. I should get clarity on that and respect his need for privacy.
I've faced variations of this situation multiple times, and there's no one-size-fits-all solution. The most effective performance improvement programs I've seen are based on empathy, combining clear expectations with genuine support, and a concrete plan with frequent check-ins that both the person and their manager feels can be achieved.
Use these pointers to plan your approach: Empathy, clarity, support; plan, check-ins, faith in success.
Did I miss any important aspects? What would you do in this situation? Let me know in the comments.
This Week's Challenge
You've been managing a small team for eight months when Jasmine, one of your most reliable engineers, comes to you with a surprising request. She wants to transition to a more infrastructure-focused role and has found an opening on another team within your company that interests her.
Your first reaction is dismay - you're already understaffed, your commitments are tight, and Jasmine is leading a critical project that's due in six weeks. Her leaving now would put your delivery timeline at serious risk. However, this is clearly an opportunity she's excited about that would give valuable experience to her career progression.
What do you do?
Think about what your goal would be and what risks you'd like to avoid in this situation. I'll share my thoughts next week. If you don't want to miss it, sign up here to receive those, and similar weekly brain-teasers in the future:
Until then, here's a small piece of inspiration to match last week's challenge, about an important aspect I left out to keep this article’s length at bay:
See you next week,
Péter