Empathy vs. Business Goals: My Story of Handling a Low Performer
My story handling a low performer and how I found balance between empathy and business goals; also, what I learned from it.
Handling low performers is not easy. No one wants to be a low performer voluntarily. There is always a story behind it.
In the competitive tech industry, most software engineers are proactive, professional, and ambitious. They want to create the best things possible.
Unfortunately, things happen. It could be a conflict, an accident, or changes in their personal life.
I have handled multiple cases of low performers, and this one is the most challenging. I'm sharing this story because I hope it can help more managers make better decisions. I hope it can spark more conversations on how to handle such situations better.
Meet Alex
Meet Alex (not his real name), a Software Engineer in my team that had been here for a few months. Alex is a nice person, and he handled tasks at his own pace.
One day, I started to notice that his development speed was slower than that of others.
During the update meetings, he always reported that he had been working on the same tasks. He would spend three days on tasks that typically took only two hours.
Initially, we thought that he was only taking his time getting used to his role. He was not in the company for that long, and it's common for new joiners to spend more time on development tasks.
However, the situation kept going for weeks. Other team members began to raise concerns, and even the team leader was confused.
I started to probe during our 1-on-1 meetings. And the truth started to emerge.
The Problems
After several probing conversations, I uncovered two major issues.
It turned out that Alex was working fewer hours than the company policy required. He had a personal family challenge that significantly affected his availability. It created a harsh working environment: constant disruptions and unpredictable schedules.
The second problem was that during Alex's interviews, the interviewers gave him a grade higher than his actual performance. This resulted in high expectations that he struggled to meet. I was also struggling with matching his achievements with the company's expectations. He was just not there yet.
To resolve these two problems, there has to be an adjustment. We can either:
Lower his grade to meet the expectations.
Adjust his responsibilities to match his availability.
However, either one would have a big impact on his salary and morale. His financial situation was not at the best during that time, so any further impact would add more burden to his shoulders.
As a person, I want the next actions to be in his best interest. But as a manager, I need to act in the company's best interest. On this issue, these two don't have any overlap.
If you are an Engineering Leader, what would you do if you were in this situation?
The Next Step
After evaluating the situation, I knew that an adjustment was inevitable. But the only thing I could do was to buy him more time.
I negotiated with the company to implement a performance improvement plan for Alex. It's a plan to find a way to match his performance with the expectations. It lasts several months. If it didn't work out, the company would take actions.
The major benefit of this plan was to buy more time for Alex.
If his personal situation improved, he would be able to dedicate more working hours.
He knew that an adjustment was coming, so he could prepare early.
This also allowed the company to collect sufficient data from the improvement plan before making a decision.
How It Ended
Unfortunately, I moved on from the company before seeing the outcome.
While I didn’t follow up afterward, I hope the plan gave him the support he needed to either meet expectations or transition to a role that better suits him.
What I Could Have Done Better
Looking back at this event, I still felt the tension and emotion when I talked to Alex. Even though I did everything as much as I could, there are a few points that I would have done differently if I were given a second chance.
1. Spotting the Issues Earlier
The issues were identified too late. If the issue was detected during the probation period, it’s easier for HR to make adjustments. It would have also minimized the impact to both parties.
Here’s what I would have done if I could do it again:
Collecting Feedback More Often from Stakeholders
I focused mostly on assigning tasks, but did not pay attention to stakeholder feedback. Most stakeholders already had questions about development durations during that period so it could be a great source to spot the symptoms.
Using Performance Metrics
I didn't use any performance metrics during that time. I only checked the overview of project progress and whether each person is occupied. Some metrics would be useful such as:
Number of tickets / story points finished in each period
Pull request cycle time
I had access to the data, but I didn’t use it effectively. I was 'being kind' and let signs slip by me. Using these techniques would help me spot issues earlier.
2. Revisiting the Hiring Process
One key issue was that the grade given to Alex was not accurate. It gave him enormous pressure when he started. I was also struggling with setting a reasonable goal for him.
It would have been great to revisit the hiring decision and understand how that decision was made. We would like to prevent that mistakes in the future.
Final Words
Handling low-performing engineers is rarely black and white. Every situation is unique, and there is no “right” decision for all situations.
If you’ve faced a similar challenge, I’d love to hear how you handled it. How do you approach low performance in your team?
Thanks for reading the post!
❤️ Click the like button if you like this article.
🔁 Share this post to help others find it.
Resources
Access structured 👣 learning paths if you’d like to move forward in your software engineer career more systematically.
Contact
You can find me on LinkedIn or Substack.
If you want more content like this, consider subscribing to my newsletter.
See you in the next post!
This article resonates deeply with my own experience as a manager. I once faced a similar dilemma with a low performer on my team. I prioritized the well-being of my team member and invested significant effort into rehabilitation. However, I've since realized that this approach, while well-intentioned, had unintended consequences.
It's easy to focus solely on the struggling individual and the company's bottom line, but we often overlook the broader impact. The team's morale can suffer, and as managers, we expend considerable energy that could be directed towards more impactful initiatives.
This experience taught me the importance of balancing empathy with pragmatism. While supporting team members is crucial, it's equally important to consider the overall team dynamics, productivity, and our own effectiveness as leaders.
The only situation I was involved in similar to this was from a more Junior engineer. He did excellent during the interview for a junior role and actually performed pretty good. After a while, he became a little stagnant in his performance. He was asking all the right questions during 1:1s. The problem was the lack of follow-up. His eagerness to grow never manifested in any concrete action, project, or generally any deliverable.
I knew something was up, almost like he was distracted. I had to put on my coaching hat and learned that his heart wasn't in it by asking why a lot of times and going deeper. Nothing was inherently wrong about the company or the team, he just felt like he jumped into a serious career path leaving too many personal questions unanswered. I gave him some time to think about it and he eventually decided to leave and pursue a spiritual journey. I think that was the best outcome for everyone and he even came back a year later, unfortunately we didn't have any open role at the time.
I learned right there to dig deeper right away if I sense something is out of place.