3 ms·

I mean, a lot of people don't "work" in the office either. You're either using some sort of concrete metrics to try and measure productivity or you're not. "Bob

I mean, a lot of people don't "work" in the office either. You're either using some sort of concrete metrics to try and measure productivity or you're not. "Bob shows up to work every day" doesn't actually tell you much about whether Bob does anything useful while he's there. I don't think figuring out who is productive and who is not is substantially different for an in-office job vs remote job. One might even argue (I'm not sure I would, but it seems plausible at least) that it is harder to measure in office. You might be tempted to rely on things like "butt in seat time" (whether they are doing productive work or just browsing reddit) or who tells funny jokes at happy hour.

The_Colonel 3y ago
It's still much easier to gauge work in person. Like if a person complains about a difficult problem 5 times in a row in daily, it makes a big difference if I glance over and see them in the IDE/terminal/stackoverflow, discussing with colleagues, drawing on the whiteboard, cursing or even sitting in the chair, apparently in deep thought. In remote, all you see is their online status (maybe).
- thinkharderdev 3y ago
  But you don't just have their online status. You can still talk to people even if you're not in the same room. You can ask them questions about what they've tried and see if they're making any substantive progress from day to day. When they say the problem is difficult in the daily you can ask followup questions to see if they've really thought about the problem hard. If on day 4 all they can say is "it's difficult" then they are clearly not working very hard on trying to solve the problem. Once they finally do finish you can ask details about why it was so hard and judge for yourself whether it was genuinely a tricky problem or they were just slacking off. These are all things you should do as the team lead or manager whether you are in person or remote.
  - The_Colonel 3y ago
    Well, basically you then need to chase them as a dev manager. And not just one person, but most of the team, because you can't really get the information passively. I bet the devs love that. In practice this doesn't really happen and the dev manager is quite blind to what's happening. And it's not just the dev manager, but generally all team members get this information passively when co-located. It's much easier to read the room when people are in the same place, and you see how they interact. When remote, devs often have no idea about other devs, unless they again chase the information (which usually doesn't happen).
    - thinkharderdev 3y ago
      > Well, basically you then need to chase them as a dev manager What you are describing, following them around to observe what they are doing, sounds a lot more like "chasing them" than asking a couple of follow-up questions in the standup.

The_Colonel 3y ago

It's still much easier to gauge work in person. Like if a person complains about a difficult problem 5 times in a row in daily, it makes a big difference if I glance over and see them in the IDE/terminal/stackoverflow, discussing with colleagues, drawing on the whiteboard, cursing or even sitting in the chair, apparently in deep thought. In remote, all you see is their online status (maybe).

thinkharderdev 3y ago
But you don't just have their online status. You can still talk to people even if you're not in the same room. You can ask them questions about what they've tried and see if they're making any substantive progress from day to day. When they say the problem is difficult in the daily you can ask followup questions to see if they've really thought about the problem hard. If on day 4 all they can say is "it's difficult" then they are clearly not working very hard on trying to solve the problem. Once they finally do finish you can ask details about why it was so hard and judge for yourself whether it was genuinely a tricky problem or they were just slacking off. These are all things you should do as the team lead or manager whether you are in person or remote.
- The_Colonel 3y ago
  Well, basically you then need to chase them as a dev manager. And not just one person, but most of the team, because you can't really get the information passively. I bet the devs love that. In practice this doesn't really happen and the dev manager is quite blind to what's happening. And it's not just the dev manager, but generally all team members get this information passively when co-located. It's much easier to read the room when people are in the same place, and you see how they interact. When remote, devs often have no idea about other devs, unless they again chase the information (which usually doesn't happen).
  - thinkharderdev 3y ago
    > Well, basically you then need to chase them as a dev manager What you are describing, following them around to observe what they are doing, sounds a lot more like "chasing them" than asking a couple of follow-up questions in the standup.