6 ms·

Ask HN: How do you handle underperforming remotes at your company?

24 points by log101 3y ago

When a remote employee appears to be slacking off regularly, what is the right course of action to handle this situation?

TooSmugToFail 3y ago
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.
- ssss11 3y ago
  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_Colonel 3y ago
  "objective performance criterias" in a development role is a joke.
  - starcraft2wol 3y ago
    They must work at Google
  - FirmwareBurner 3y ago
    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.
    - The_Colonel 3y ago
      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...
      - FirmwareBurner 3y ago
        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.
genjii931 3y ago
Same as any employee, of course.
gregjor 3y ago
The Ludovico’s Technique worked for us. 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.
- postalrat 3y ago
  If they were working I wouldn't be bothered.
carlosjobim 3y ago
Depends entirely if you're his colleague or boss. To get good answers you have to ask good questions.
- FirmwareBurner 3y ago
  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.
  - The_Colonel 3y ago
    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.
    - FirmwareBurner 3y ago
      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.
    - pawelduda 3y ago
      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
notyourav 3y ago
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.
- AlexITC 3y ago
  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.
  - toomuchtodo 3y ago
    Could also be burnout.
  - pawelduda 3y ago
    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.
GoToRO 3y ago
Just a reminder: a professional synchronized swimmer will look like is slacking off compared to somebody who doesn't know how to swim.
rShergold 3y ago
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.
- 6510 3y ago
  > First: Talk to them about it. This is the hardest part. This is only hard if you do it after talking with everyone else.
jlizzle30 3y ago
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.
deleted 3y ago
[deleted]

24 points by log101 3y ago

When a remote employee appears to be slacking off regularly, what is the right course of action to handle this situation?

TooSmugToFail 3y ago

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.

ssss11 3y ago
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_Colonel 3y ago
"objective performance criterias" in a development role is a joke.
- starcraft2wol 3y ago
  They must work at Google
- FirmwareBurner 3y ago
  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.
  - The_Colonel 3y ago
    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...
    - FirmwareBurner 3y ago
      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.

genjii931 3y ago

Same as any employee, of course.

gregjor 3y ago

The Ludovico’s Technique worked for us. 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.

postalrat 3y ago
If they were working I wouldn't be bothered.

carlosjobim 3y ago

Depends entirely if you're his colleague or boss. To get good answers you have to ask good questions.

FirmwareBurner 3y ago
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.
- The_Colonel 3y ago
  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.
  - FirmwareBurner 3y ago
    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.
  - pawelduda 3y ago
    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

notyourav 3y ago

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.

AlexITC 3y ago
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.
- toomuchtodo 3y ago
  Could also be burnout.
- pawelduda 3y ago
  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.

GoToRO 3y ago

Just a reminder: a professional synchronized swimmer will look like is slacking off compared to somebody who doesn't know how to swim.

rShergold 3y ago

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.

6510 3y ago
> First: Talk to them about it. This is the hardest part. This is only hard if you do it after talking with everyone else.

jlizzle30 3y ago

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.

deleted 3y ago

[deleted]