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?
37 comments
Depends on your role. Assuming you are their direct supervisor, simply give more tasks. Slacking off is usually due to not enough to do. Follow the tasks at a high level, make sure he knows he’s being tracked. This has even the effect of increasing motivation, as most people value attention.
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.
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.
My experience is the opposite, when people is unmotivated or not interested in the work, its unlikely for them to improve even if you give them enough chances.
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.
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.
Could also be burnout.
I think it could be just bad fit. Work looks good from outside but once someone is hired, they get disillusioned because it turns out they don't actually enjoy business domain or whatever else and find the job unfulfilling.
Assuming you have objective performance metrics, and consistent criteria, the appropriate course of action would be to warn them, re-evaluate after a trial period, and fire if nothing changes.
"objective performance criterias" in a development role is a joke.
Then how about subjective performance criteria?
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.
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.
My experience in remote teams was that people have smaller awareness of other team members. There's less communication, which means you have less direct one-to-one communication, but you also learn less information indirectly about others from such conversations.
> 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...
> 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...
Sure, but that's why you have scrum masters, product managers, product owners, etc. who routinely check up on progress, beyond the daily and push the buck down on items suffering delays. So at one point, the non technical people will ask the senior technical people "why wasn't task X been delivered, according to planning it should have been done by now".
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.
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.
They must work at Google
this is right. In fact it’s exactly the same for in office employees, it’s just that old style management can no longer judge people by when they walk in and out of the office.
The best signal to gauge Eng performance is their impact against business objectives. Money saved, UX improved, costs reduced, modules deleted, etc.
Collect weekly bite-sized updates to know how your team is doing.
Collect weekly bite-sized updates to know how your team is doing.
I’ve had to deal with this a few times now. After asking around the greybeards I really respect this is my current run book.
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.
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.
> First: Talk to them about it. This is the hardest part.
This is only hard if you do it after talking with everyone else.
This is only hard if you do it after talking with everyone else.
Just a reminder: a professional synchronized swimmer will look like is slacking off compared to somebody who doesn't know how to swim.
Same as any employee, of course.
Depends entirely if you're his colleague or boss. To get good answers you have to ask good questions.
Or check Jira and Git, it's not rocket science. If the person has a task assigned that would take a junior max 3 days of chill work to knock out but it's been 7 days and still no results and the person hasn't reported any blockers on the dailys, it's pretty obvious there's a performance issue.
I usually check Git, see nothing committed, then ask them privately "how are things going with your project? Do you need any assistance?" Another couple days goes by, some garbage that doesn't run is committed to git... I ask again. The cycle repeats. I'm just the tech lead on the project, I have no real authority, so if the situation doesn't improve I do mention it to the actual manager. They usually then do nothing.
Damn I'd like to work at your company to coast for a bit to relax. Where I'm at right now you'd be fired on the spot after a couple of weeks like that if your manager hears you're doing nothing.
We had someone who got fired for performance issues. It took a good 6 months.
It's quite easy to hide (provide plausible deniability for) low productivity if the person is smart about it. Complain about environment issues, broken CI builds, unexpected complexity etc., there was one meeting too, then put in the minimum amount of progress.
For many of these there are fixes.
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.
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.
For sure, if you like to be a detective and expose the slacker, it is possible to do it. But more often I see people rather giving the benefit of the doubt.
As a peer that's totally OK.
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.
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.
Of course it's easy to fake issues to justify lack of productivity for months when you're remote, but then you should be sharing your issues at the daily meetings so people can help you fix them to get on with work. That's what the dailys are for.
Keeping your blocking issues silent for days is what the problem is, not that you habe issues.
Keeping your blocking issues silent for days is what the problem is, not that you habe issues.
Complaining about all these is legit, I'd rather do it and get fired for "underperforming" than push through this shit and burn out. These sound like excuses but could be real issues that should be investigated because maybe it's rotten infrastructure that nobody cared about because it's "unproductive". Other devs can be affected too, apart from the person raising it because they lowered their expectations over time and can handle the suffering for the time being, while waiting second hour for CI to pass
All of these are legit, and that's why they're great excuses. CI works most of the time, but sometimes has hiccups for whatever reason. Everybody gets hit by such issues from time to time, this particular dev is just reeeally unlucky and happens to catch those every other day. But nobody keeps the stats. People might get a hunch something is wrong, but what can you do with that?
Offer help with troubleshooting, hop on a call (maybe pair programming), ask what have they tried to solve the problem, etc, etc... If you assume someone is slacking because of common roadblocks, you're setting yourself up for trust issues. If you see they are indeed underperforming, you can take regular steps from there. If they straight up lie it'll be obvious at some point. No need to start with stance of distrust IMO
Or perhaps: the task is really not that important and nobody cares. If it should take “3 days of chill work” and nobody complains on day 5, well, perhaps it’s better to not solve the task at all.
Found the Googler.
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.
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.
Aaa... the mythical junior.
What's mythical about that?
Every manager I know will threaten to hire that junior. The problem is that he/she doesn't exist.
[deleted]