Is assessing performance important? We usually have performance reviews tied up with end of year bonuses and promotions. I tend to focus more on performance towards continuous improvement. If we have a template of what we should accomplish and how to add value and we can see if we’re on track we can adjust and improve.
What’s the source of bad performance?
We may associate bad performance with low productivity, or not doing the things right, or completely misbehaving. We point the finger to bad employees and expect them to make corrections. But I believe that there’s much more to it. The leadership should be responsible to address the root causes for bad performance. And this means assessing the responsibility of bad performance. And this may not be fully on the employee’s shoulders.
We should focus on how we can overcome hard times together.
Reason 1: Lack of skills
We may not have the required skills to perform our tasks. This can happen because of several reasons. For example we may start a different position and need to deal with unknown technologies or processes. We may be lagging behind because we haven’t had the time to do proper training.
Sometimes we don’t have the resources to provide training and will hope that people will just catch the train running. If that’s the case we should provide a safety net. But we need to be concious on that and try to provide a proper onboarding material that allows for quicker ramp-up.
But it’s an investment that will hurt short-time productivity. It’s both the responsibility of the employee and of the company/management to overcome this issue.
Reason 2: Lack of motivation
We may have high-performers that are not delivering as expected, simply because they’re not motivated. This may be because they’re not liking their current tasks or because they have no sense of purpose. Or even because they’re not connecting with their team.
We need to detect the situation and act on it. Indeed sometimes we have to perform dull tasks, and that’s part of the job. But we need to be aware that without good challenges and a healthy team, it will be harder to take the most out of some people.
We need to inspire and motivate. And this may be very hard. But it’s important to understand if this is the problem. Because this may result in high-performers leaving.
In this situations I believe the main responsibility is on the company/leadership. We need to have a inspiring vision and goals that challenge us.
Reason 3: Misfit
We may have someone that simply isn’t a fit. And this should be completely the responsibility of the company/leadership because we failed on the recruiting phase. It could be because the person is at a lower level (and even at a much higher level). It could be because we have different beliefs and values and have a culture mismatch. It could be some adaptation issue.
We need to figure out how to integrate them or how to help them on finding a new job. And we need to review our recruitment process on how to improve our match making.
Reason 4: Bad processes
Long build times, lots of meetings, etc. This will usually impact everyone but may be more troublesome for people that have more issues organising themselves. We may have people that use the wait times to advance on other tasks. But that multitasking may not be easy and may be harder to do.
We can also have people that are more optimised to do some parts of the processes. We should understand these strengths and weaknesses and try to take the most out of everyone.
Reason 5: Personal issues
Sickness, a small child, problems at home, etc. From time to time we all have our personal issues that impact our work’s productivity. In a healthy environment the team should have each other’s backs and help.
We need to help our teammates overcoming these hard times.
Reason 6: Bad teamwork
This may be very specific to some teams and cultures. We may have people that are very skilled and productive by themselves but don’t contribute to the team’s output (see team speed versus developer speed). We may also have people that are toxic and that lower the team’s output.
While these people may be great for short time bursts of productivity, they have a severe impact on long term productivity and may cause other people to leave.
How can we measure performance?
There are a lot of causes for bad performance. But how do we know that we’re at the face of bad performance? It would be great to have some engineering KPIs that would just communicate that. But it’s very hard to map the influence of people on the overall productivity.
I believe that the best way is to properly communicate expectations. We all have some idea of what good performance looks like in our head. We may have someone that is a template and we measure all other people against that one person. It’s important to understand what we really value and try to communicate that clearly. And this may be hard.
- We want good estimates and deliveries on time
- We want good quality deliverables with few bugs
- Be a good teammate
- We expect that some side tasks are also done and that they won’t impact the main deliverables
We could try to quantify some of these things. But that’s a slippery path. We may have someone that only did one pull request with one line of code in one week, not attending anything else, and that added huge value.
The truth is that most measuring techniques we can use may not be useful at all. And we may rely on our six sense. But the problem is that sometimes we don’t have all the context, and may be unfair when evaluating.
A good approach may be to query the employees peers. Again we may have some lack of context, but we’ll have more information. Usually information that we totally missed because of some private interactions.
The team always knows who’s pushing further and who’s lagging behind. And if someone is producing a lot but having a bad impact on the team.
If the company/manager may be responsible for bad performance, we should also try to assess it and improve on it. Many times we focus on low performance of developers like this a problem that they have. And it may be. But we need to held the leadership accountable. It’s the manager’s job to grow and motivate the team. If that’s not happening we need to do something about it. Just like we need clear expectations for developers, we also need it for managers.
Having the team evaluating the manager can be a good source of improvement points.
Setting clear expectations
It’s great if we’re able to communicate our expectations to our teammates. I find this to be very hard. The best way I found of doing this is just putting out what’s on my mind and discuss it on 1on1s.
It’s important to have an agreement on this. It’s not that useful if I expect something from a developer but that’s not seen as important from the developer. So I try to be very blunt and direct and I ask if we have an agreement. This may led to a healthy discussion.
For example I’ve seen people working hard on less priority tasks that add value but are not their main thing to deliver. And the main thing gets delayed. They may believe that they’re adding a lot of value but the stakeholders may have a different idea. And this results in recognition issues.
It’s important to have a relationship of trust beforehand. From my experience people tend to accept improvement points in a more productive way when they know that the other person has their best interest in mind.
Having these conversations periodically is great because we can adjust the direction when needed. I usually focus 1on1s on this, but we can also consider team retrospectives for it.
The main point is that, if we do have an end of year review, there should be no surprises at that point.
What’s the end goal?
We need to always be iterating on improvement points. This is what makes us grow. We do need to be concious on the root problems and address them. We need to be direct and honest and communicate clearly what’s on our mind. This is why I try never to ask for feedback about myself. I always ask for improvement points. This always makes the other person switch how they communicate. They may feel more comfortable on giving harsh feedback and if don’t have any they may take the time to think about it.
Then we should work together, as a team, on overcoming issues. This should be a joint effort. I do believe that developers should be more proactive in their own evaluations. For example, imagine that a developer comes to the manager and says: “Hey, I want to have a 30% pay raise in X years. What’s required to achieve that?”
This could put the manager on a hard spot. Because it’s hard to actually quantity these things. We may have progression ladders that have time intervals. But asking beforehand and having a specific set of goals or achievements would be very efficient to make people grow.
So when I’m on the manager side I try to do the exercise of thinking to myself of what would be required for my mentee to accomplish so that a X% pay raise is possible. What do I need to be able to sell that upstream?
This forces me to try to quantify things. And it’s an ongoing challenge.
The title says “Performance appraisal methods” but I end up without such methods listed. The truth is that I never saw anything that worked really well. But have seen lots of ways that don’t work. My focus is always to grow people make them more productive and valuable. But I’m still learning this skill. :)
Author Pedro Pereira Santos
License CC BY-NC-ND 4.0