Ask HN: How do you handle underperforming remotes at your company? When a remote employee appears to be slacking off regularly, what is the right course of action to handle this situation? |
Ask HN: How do you handle underperforming remotes at your company? When a remote employee appears to be slacking off regularly, what is the right course of action to handle this situation? |
If slack off means he’s not showing up at team meetings, constantly missing deadlines, low quality of work, etc.. just give feedback on a case-by-case basis, ask how he would make it better next time.
If he fails to improve and the examples pile up, time to make hard decisions. I have to say, in my experience as a direct supervisor, only 1 out of like 4 people fail to improve, if you are willing to invest your time and effort.
I have the impression that people get in some kind of comfort zone when underperforming that's psychologically hard for them to improve until they move to another team/company.
So, you should catch these issues as soon as possible to let people know that this is not tolerated, in some way, this helps because people can take you more seriously.
When you can measure and compare productivity and “slacking off” objectively and fairly, for everyone, let us know. Until then read Ed Zitron and stop worrying about how other people work.
In a motivated and well performing team, everyone has a pretty good gut feeling on who's slacking off and pretending to work.
Unless ... the whole team is full of slackers who want to collectively engage in theatrics and perpetuate that there's no such thing as objective performance metrics in order to not be exposed as slackers.
Collect weekly bite-sized updates to know how your team is doing.
First: Talk to them about it. This is the hardest part. The aim of this conversation is to let them know you’ve noticed a change in performance and you want to know what you can do to help. It’s an open conversation but there are two possible outcomes.
1. They’re bored of their work. This is more common than you think. Give them a big problem. Maybe a bug no one can figure out. Maybe move them to a different project for a while. Check in with them every day/2 days. They don’t have to solve/finish it instantly but they do have to demonstrate engagement.
2. They’re burnt out. This is coming for all of us one day so be kind. The solution to burnout is give them micro tasks. If there are no micro tasks take an existing task and break it down into micro tasks. Something that would take you an hour to do. You want to get them into the habit of moving tickets across the board again. There’s no time pressure here but you do want to start tracking their productivity.
If you suspect they are slacking off/have problems at home/have a full time second job solution 2 also applies.
Think of this period as like hiring an intern/junior developer. Your job is to support them & build them up. If they were once productive you’re trying to get that guy back. This takes time and don’t rush it.
Keep a close eye on their velocity. Expect them to be slowly building up. If you use ticket points track their points.
If after the first 2 weeks you get the feeling they are not engaging now is the time to notify your manager/ HR (depending on your country firing someone may be a long process)
The aim is to get them back to being productive again. Whatever caused this issue. don’t expect to get them back for 2-3 months. This is okay remember how much it costs in time and money to get in a replacement.
What we want to see over that time is a gradual improvement in velocity. Slowly start giving larger tasks. Check in with them at standup every day and have a half hour call with them once/twice a week.
Over these 2/3 months if you see no improvement bring in HR and initiate a formal PIP or whatever process you have for firing someone. If they’re taking the piss they’ve been found out. If they’re burnt out and are not engaging with this process maybe their time as a software developer has come to an end. At the very least their time at your company has.
Every single person is different. One person I took though the process fully embraced it and has since been promoted. Turns out he just needed more responsibility.
This is only hard if you do it after talking with everyone else.
Clearly from OPs complaints it's clear that people are checking in on the work, which is missing, that's why he opened this topic.
> everyone has a pretty good gut feeling on who's slacking off and pretending to work
I remember one such case where I had a gut feeling, but I didn't undertake any action. Writing to a manager felt like snitching, and I could have been completely wrong (maybe they had valid reasons, unknown to me, to have low productivity), which would cause me embarrassment. I think it often takes a team consensus, sort of validation with somebody else. But such sensitive topics are often communicated subtly, indirectly, with body language or voice intonation. But I won't be writing my colleague on Slack if they share my suspicion...
So they have a senior dev look at the requirements of the task to check maybe the estimations was wrong or the way it was formulated was bad, and also have a look at what that developer in questioned has checked into Git and start asking questions on why the slow process.
You can bullshit the non technical people, but you can't really bullshit your peers/seniors for too long before they realize your underperforming, when they start looking into your work.
I've had people try the env issue thing. I asked them to never try longer than 15 minutes to solve an env issue by themselves. Post on the public dev channel for help or ask me privately if they don't feel comfortable with it (it happens, that's OK). A lot of people just aren't good at troubleshooting env issues and I happen to be good at it even if I have never had that issue and I keep an eye on others posting and often can find a solution for people quickly. It's amazing how many people can't read error output, especially stack traces, and figure out which is the relevant message to search by.
Broken CI same thing really. And it's easy to compare if it's just them or everyone's builds are broken.
Complexity I offer help. Pairing for as long as needed. I've had a few guys where it became clear here that they really just weren't good. There are many signs here that you can collect and document. I've also done Re-implementations from scratch (not looking at their code) in some instances, proving their "hidden complexity" that took a week to not solve took me literally an hour to code down.
As the manager/lead I have an obligation to figure out if someone is just having temporary trouble or if they're simply a slacker by nature or just not good at their job. If that is the case it is my duty to get them out. They can slack off somewhere else and drag other people down, not me and my team.
Both for the company (I couldn't really care less in most cases, since the company doesn't care about us either) and for the rest of the team (I could never stand managers that let obviously bad/slacking people continue working alongside the rest of us that do their job properly and the slackers still get the same raises and potentially even negotiated a better salary, as they're probably good talkers, but bad walkers). I care for actual walk. I do not care for cheap talk but it's the most common.
Keeping your blocking issues silent for days is what the problem is, not that you habe issues.