4 ms·

How specifically would I know that? Last time I gave somebody the benefit of the doubt I ended up doing their work myself over Christmas. I'm interested to know

by Joeboy 3y ago

How specifically would I know that? Last time I gave somebody the benefit of the doubt I ended up doing their work myself over Christmas. I'm interested to know what I should've done to avoid that.

hosteur 3y ago
Well, impossible to say without context. But maybe it is more interesting what you should do afterwards. What did you do afterward?
- Joeboy 3y ago
  The project came to an end (hence me having to wrap up their work), so I didn't do much. I'm on a new project now, but I have the same question. If someone keeps insisting their work is coming along great and they'll be checking it in real soon, how do I know if it's true?
  - potatolicious 3y ago
    Ask for proof. Some employees are lower-performing and some need more structure. "Can you push your work-in-progress branch so I can take a look?" If they are consistently under-performing you need to structure them. Split larger tasks into smaller sub-tasks that are more tractable over shorter time periods. If a large task is expected to take 3 weeks, split it into chunks of 1-2 days. That way if a code review isn't sent out you get a quick signal that progress isn't being made. Remember that as the manager you have authority. They may chafe at being asked to do intermediate checkins and splitting the work into smaller quanta - that's fine, they can grouse about it with their friends, but they still have to do it. If they are underperforming even within this structure, have them keep a work log - which is basically a 1:1 asynchronous standup with just you and them. Read this work log daily and, in combination with smaller quanta of work, it should be fairly obvious progress isn't made. At all points don't hide the ball from them that they are underperforming. Tell them that they are underperforming but give them the resources necessary to improve. Solicit their ideas on how to improve and consider implementing them. Some employees can be structured to improve this ways. Others cannot - you work with HR on that latter group. But again: as the manager you do not need to see butts-in-seats to gauge productivity. More importantly, it is on you to set a benchmark for productivity and communicate to your team your expectation that everyone hits it, and alert them in your (frequent!) 1:1s when they are falling short.
  - lolinder 3y ago
    > their work is coming along great and they'll be checking it in real soon This is the process problem in my mind. Why are they working on something that goes weeks without checking in code? They should have smaller actionable chunks that can be checked in at least once a week. More importantly, take that same employee and put them in an office and do you really think things are going to be different? Alt tab is a thing, looking busy is a thing, and if you're entirely relying on their word that things are going well then you're going to get yourself in trouble regardless of whether you're in an office or remote.
    - Joeboy 3y ago
      > Why are they working on something that goes weeks without checking in code? I think it was a couple of days' worth of work, which they told me was nearly finished for a couple of weeks. All I was saying was there was no way for me to know whether that was the true or not. Unless they pushed the code, which they were always supposedly on the cusp of doing. On the last day before the holidays I was very explicit that they needed to push their code by the end of the day, which they said they would but didn't. Perhaps I need to be more assertive about it, or insist they pushed it live while I watched or something. I do think I'd have found the situation easier if we had a face-to-face relationship, although that's not really what I was trying to argue.
DiggyJohnson 3y ago
I'm sorry about your Christmas, but that seems like a poor reason to never give the benefit of the doubt going forwards. Situations are situational.
- Joeboy 3y ago
  > Situations are situational Indeed. I suspect a lot of people here work in situations where there's slack in the system and nothing particularly bad happens if the work doesn't get done.
  - lolinder 3y ago
    Yeah, no. We have tight deadlines that we're expected to hit and clear milestones for reaching those deadlines. If we miss them hundreds of people throughout the organization will know and ask why, and multi-million dollar sales contracts go out the window.
    - Joeboy 3y ago
      Ok, but unlike the person I was replying to you seem to be arguing against giving people the benefit of the doubt.
      - lolinder 3y ago
        I'm arguing against shrugging and saying "it's because of remote work" when your project is falling apart. Give the benefit of the doubt when there is doubt, but once there's no doubt then build the structure you need to make progress. Remote != Completely unstructured
        Joeboy 3y ago
        > I'm arguing against shrugging and saying "it's because of remote work" Have I at any point said that?
        3y ago

by Joeboy 3y ago

How specifically would I know that? Last time I gave somebody the benefit of the doubt I ended up doing their work myself over Christmas. I'm interested to know what I should've done to avoid that.

hosteur 3y ago

Well, impossible to say without context. But maybe it is more interesting what you should do afterwards. What did you do afterward?

Joeboy 3y ago
The project came to an end (hence me having to wrap up their work), so I didn't do much. I'm on a new project now, but I have the same question. If someone keeps insisting their work is coming along great and they'll be checking it in real soon, how do I know if it's true?
- potatolicious 3y ago
  Ask for proof. Some employees are lower-performing and some need more structure. "Can you push your work-in-progress branch so I can take a look?" If they are consistently under-performing you need to structure them. Split larger tasks into smaller sub-tasks that are more tractable over shorter time periods. If a large task is expected to take 3 weeks, split it into chunks of 1-2 days. That way if a code review isn't sent out you get a quick signal that progress isn't being made. Remember that as the manager you have authority. They may chafe at being asked to do intermediate checkins and splitting the work into smaller quanta - that's fine, they can grouse about it with their friends, but they still have to do it. If they are underperforming even within this structure, have them keep a work log - which is basically a 1:1 asynchronous standup with just you and them. Read this work log daily and, in combination with smaller quanta of work, it should be fairly obvious progress isn't made. At all points don't hide the ball from them that they are underperforming. Tell them that they are underperforming but give them the resources necessary to improve. Solicit their ideas on how to improve and consider implementing them. Some employees can be structured to improve this ways. Others cannot - you work with HR on that latter group. But again: as the manager you do not need to see butts-in-seats to gauge productivity. More importantly, it is on you to set a benchmark for productivity and communicate to your team your expectation that everyone hits it, and alert them in your (frequent!) 1:1s when they are falling short.
- lolinder 3y ago
  > their work is coming along great and they'll be checking it in real soon This is the process problem in my mind. Why are they working on something that goes weeks without checking in code? They should have smaller actionable chunks that can be checked in at least once a week. More importantly, take that same employee and put them in an office and do you really think things are going to be different? Alt tab is a thing, looking busy is a thing, and if you're entirely relying on their word that things are going well then you're going to get yourself in trouble regardless of whether you're in an office or remote.
  - Joeboy 3y ago
    > Why are they working on something that goes weeks without checking in code? I think it was a couple of days' worth of work, which they told me was nearly finished for a couple of weeks. All I was saying was there was no way for me to know whether that was the true or not. Unless they pushed the code, which they were always supposedly on the cusp of doing. On the last day before the holidays I was very explicit that they needed to push their code by the end of the day, which they said they would but didn't. Perhaps I need to be more assertive about it, or insist they pushed it live while I watched or something. I do think I'd have found the situation easier if we had a face-to-face relationship, although that's not really what I was trying to argue.

DiggyJohnson 3y ago

I'm sorry about your Christmas, but that seems like a poor reason to never give the benefit of the doubt going forwards. Situations are situational.

Joeboy 3y ago
> Situations are situational Indeed. I suspect a lot of people here work in situations where there's slack in the system and nothing particularly bad happens if the work doesn't get done.
- lolinder 3y ago
  Yeah, no. We have tight deadlines that we're expected to hit and clear milestones for reaching those deadlines. If we miss them hundreds of people throughout the organization will know and ask why, and multi-million dollar sales contracts go out the window.
  - Joeboy 3y ago
    Ok, but unlike the person I was replying to you seem to be arguing against giving people the benefit of the doubt.
    - lolinder 3y ago
      I'm arguing against shrugging and saying "it's because of remote work" when your project is falling apart. Give the benefit of the doubt when there is doubt, but once there's no doubt then build the structure you need to make progress. Remote != Completely unstructured
      - Joeboy 3y ago
        > I'm arguing against shrugging and saying "it's because of remote work" Have I at any point said that?
        3y ago