Employee is a non-performer? It is your fault. Act on it
February 18, 2022
I want to start a new post topic. A part of future posts on this blog will be about management. Apart from data science, this is my day job and I feel like sharing my experience may help someone solve their problems.
Some time ago, I hired a software engineer. The interview went fine, but the timeframe was strict and I missed a few questions that I usually ask. We were under heavy pressure, since projects were understaffed and we desperately needed people to keep up with the task stream. The slog of exhaustion, the need for help and a lack of success in hiring for weeks have done their job. I hired someone impulsively.
That lead to a series of events that demonstrated a lack of skills we need on a project. “He will catch up”, we thought and invested some time in training. Then, he showed signs of poor time management. We worked on this problem on regular 1-1s. The number of problems snowballed. At the moment I realized how much time we spend fighting windmills 6 months has passed. The sunk cost fallacy has already rooted deeply in my mind. I should have detected this problem a lot earlier.
Everyone who has ever experienced a hiring mistake realizes that a rigorous interview process is not a 100% guarantee of success. Sometimes, even the most scrupulous process fails. Everything is simple when it works as expected. The hard question arises when the process fails. You hired a candidate. And you felt that something’s wrong. He performs not as well as you supposed. Some low-priority tasks on a project slack, schedules shift. You pump in more of your time to “kick-start things”. A weekly status report can become a daily technical session where the team leader helps this new hire to get through a complex part of his task. Weeks pass by, then months. People get tired. Tasks are not done and now the project enters the problem stage. You could decide to add more people to the team.
You need to learn to listen to that gut feeling that something is wrong.
The first thing to recognize is the early signs of the problem. Then, you need to collect data and analyze. Then, don’t forget act on it. It can be tempting to ignore the problem and give it more time, hoping it will resolve itself. And then it will be too late. Ignoring the source of the problem and trying to decorate the issue won’t help anyone.
Trusting your gut feeling makes you detect failures fast. Then, you need to think about how to get better. What could you do to sidestep the issue? Improve the interview process? Introduce project rotations in a more timely manner? Answers to those questions should help you to act. You will be in more trouble next time if wrong things aren’t improved. It’s likely that problems will show up you are already going on with the project. Having lots of tasks floating around, you can easily get stuck in decision paralysis. So, let’s draft an action plan for handling those situations to keep the solution plan as simple as possible:
-
Is this person working alone on the project in his/her field of expertise?
-
Can you afford to introduce someone with more seniority to the team and divide the work between them?
-
Can you move this person to another team, where he/her can contribute to smaller pieces of work?
-
Does the problem relate to his/her technical skills?
-
Does the problem lie in his/her soft skills?
This post might tempt you to act fast. Yet acting on such things with eagerness is often suboptimal. How much time is left to decide about letting people go? I would love to name a single number, like 2 months, but the truth is that it depends on the company’s culture, as well as hiring and onboarding processes. In some setups, waiting for two or three months won’t harm the business. For others, even one month of slack caused by a bad hire can cause a catastrophe. The better the culture, hiring, and onboarding, the longer you can wait without harming the project.
The choice of dismissing someone from a project, or even from a company, is a hard one. It’s complex both from a moral, project management and sometimes even business standpoints. Because of this, you need data. It will happily prove that you are wrong if that’s the case. If it’s not, then it will back you up in making a tough choice. And, it will help you to be reasonable and making sure that you are not acting on something that got out of thin air. Be realistic about your goals and work that needs to be done. But don’t forget to be human. Be kind, treat others well.
Having this settled, we need data. First things to look at are the project performance metrics. I will not go deep into this topic in this post and assume that you already have something to look over. Some examples of metrics that can keep you informed are lead time and estimation accuracy.
Next, you need to set a context-sensitive deadline. Write out related risks related to changing people on the project. Analyze. Decide how much time will be fine for that employee. This is an important moment, since we got our first number: decision deadline. When you got that, you can set up an improvement plan. Think on what points need to be worked on and communicate clearly. Do not forget to discuss the deadline and explain why you need it.
Another significant metric to keep in mind is the hiring cost. If you have this information available, then that’s great. If not, try to compute how much it costs your company to hire someone? Look for the hiring funnel stats somewhere in the company’s systems or reports. A quick back-of-the-envelope calculation will show how much effort and costs each successful hire brings. The larger this number is, the lower your risk appetite. Ineffective hiring processes lead to tight filters and overly complex interviews, since you have less room for an error. This can be a great metric to track and optimize over.
We have gone through a process of handling poor hiring decisions. It’s even more important to think about detecting those situations early and preventing them. The best scenario to have is when you don’t have such problems in the first place. You need to make sure that everyone is informed on what is expected from their level. And you need to know how things go for each team member. Do they enjoy their work? What issues do they face? Is there any feedback for them? Do they have feedback for you? Do they have all necessary resources to work efficiently? The most useful tool for this is regular 1-1s. Although these meetings deserve a separate post, I’d like to mention how you can make the team productive again with 1-1s. Each employee should have someone to talk to weekly in a semi-structured format. An important part of those meetings is providing and collecting regular two-way feedback. You may find out that your teammate struggles with tasks that are too complex for him. Or that someone is unhappy because of the problems she can’t solve alone. A regular schedule allows you to detect problems before it is too late. And regular feedback could save you from setting a stressful improvement plan with a fixed deadline in the future. Sounds much more comfortable, right?
In particular, always keep in mind competence when discussing issues related to performance. Sometimes, over/underestimation of a skill level hides under what looks like a hiring mistake. It is useful to keep this simple matrix in mind to decide if someone needs more of your help daily or even a shift in responsibilities:
Competence Level | How detailed should a task definition be? | Mentorship strategy |
---|---|---|
Low. Still learning | Step-by-step or detailed descriptions of simple tasks | Instructions, pair programming |
Medium. Competent. | Clearly defined task definition. Implementation details can be left out | Mentorship. Advice on how to proceed and get better, based on previous experience and feedback. Share your (mentor’s) knowledge |
High. Expert | High-level goals that allow freedom in implementation | Coaching. Support, provide guidance, ask questions. “A coach has some great questions for your answers; a mentor has some great answers to your questions” |
Also, it is worth noting that all task definitions should be SMART: Specific, Measurable, Achievable, Relevant, and Time-constrained. I find SMART to be as good as any other acronym from the software world, such as DRY or SOLID. And I don’t mean that in a bad way. When used right and in adequate moderation, they are helpful.
That said, we conclude this practical advice on how to handle hiring errors and how to make less of them. Concepts and ideas are not just theoretical. I faced same problems and looked for tools to avoid them. A hiring mistake can hit you hard. If you ever feel responsible for that, try to recall: the best way out is to get better, learn and avoid this situation next time. Management advice often sounds bland and obvious. But sometimes, only the experience of making those so-simple-on-paper mistakes is what makes you internalize plain truths.