Karl is the Head of web development at Agenic, a 60-people digital agency with 12 engineers. Karl has noticed that Mike, one of the backend engineers in his team, systematically produces way less code/functionality than his colleagues, with similar scope and quality.
Over the past six months, Karl has had a couple of informal discussions with Mike on the topic, but every time Mike had perfect excuses: too broad specifications, poorly scoped project or unforeseen technical complexity.
Lately, a manual analysis of a 4-week sprint has shown that Mike’s closest colleagues are 8x more productive on average. One key example is the day Mike worked on a project for 7 hours and wrote 10 lines of PHP, of which 8 were copied from a previous project.
Now that we’re approaching the end of the year, Karl is pressured by his CEO to terminate Mike’s contract.
What should Karl do?
When dealing with performance issues, the best moment to act was six months ago. The longer you let a performance situation slip, the harder it is to get the teammate back on track, especially if they’re unwilling to take responsibility, like Mike in this case.
When the first performance issue surfaced, Mike’s unwillingness to recognise his own shortcomings should have been the first alarm bell for Karl. There are indeed situations that are out of our control, exceptional situations. But product specifications that are “too broad” or a “badly scoped” project are not exceptional. Mike should have communicated his doubts and worked with the product owners to clarify all the unknowns.
It’s during the very first project Mike was running behind, that Karl should have clearly communicated his feedback and had conversations with Mike about how he can help him get back on track.
It’s brutally hard to tell people when they are screwing up. You don’t want to hurt anyone’s feelings; that’s because you’re not a sadist. You don’t want that person or the rest of the team to think you’re a jerk. Plus, you’ve been told since you learned to talk, “If you don’t have anything nice to say, don’t say anything at all.” Now all of a sudden it’s your job to say it.
Kim Malone Scott, Radical Candor
Let’s assume that Karl did give clear feedback to Mike and tried to help him the first time he had performance issues. Mike still ended up finishing his part of the project late, and now, he’s again having performance issues in the following sprint.
Karl should now be wondering if he was clear, articulate and analytical enough when he had his first discussion with Mike. According to Michael Lopp, an engineering leader at Apple and author of multiple books on engineering management, a manager should have “multiple face-to-face conversations over multiple months with the employee where [they] have clearly explained and agreed there is a gap in performance.”
If Mike is again having performance issues, it’s either because 1/ he did not accept his shortcomings (even if he said the contrary to Karl), 2/ he did not understand what he had to do to improve. The critical point here is to have the teammate agree. You cannot help people against their will, and one cannot improve if they don’t recognise their shortcomings. On the contrary, if you have the will, you can get the skill.
Karl should first try to get Mike on board, and the best way to do this is to make sure he has the data to back his feedback up: a lot of changes required in their early PRs, significant re-working, inability to estimate known features… Once Mike accepts the reality as it is, then he can start improving.
In case Mike did recognise his shortcomings but did not improve (point 2 above), then maybe the resources and support provided by Karl were not enough. If someone doesn’t know how to estimate reasonably or organise their work for efficacy, telling them to do so won’t change a thing. In this case, Karl should lay out a clear and concrete improvement plan, have weekly interactions with Mike on the topic and, perhaps, have Mike mentored by a more senior teammate.
Back to Karl’s actual situation, the one where he did not do everything stated above. Unfortunately, it might already be too late for Mike since many people in the organisation, including the CEO and Karl himself, believe he’s an underperformer. In a 1998 HBR article, researchers Jean-François Manzoni and Jean-Louis Barsoux found that once a specific vision of a teammate has settled in a manager’s mind, they will start being more controlling, ask for more meaningless tasks and lower their expectations.
When a manager falls into this set-up-to-fail syndrome, it becomes almost impossible for the teammate to reverse it since even good performance will be viewed through bias. Recognising this bias should be the manager’s first step, the same way recognising their own shortcomings should be the teammate’s first step.