> To be Captain Obvious for a moment, it seems much easier for remote employees to hide a lack of productivity, especially in roles where productivity is hard t

> To be Captain Obvious for a moment, it seems much easier for remote employees to hide a lack of productivity, especially in roles where productivity is hard to quantify (like software development). If you can't trust your workers to get work done without surveilling them, you should fire them, and focus on hiring employees you feel capable of truly trusting, not lament your inability to surveil them. An under-discussed benefit I've found in years of remote work is that it tends to come with a much higher percentage of supervisors who are actually capable of trusting their employees to be professionals and get work done, rather than managers who pay lip-service to ideas of trust but then use butts-in-seats-I-can-see as a security blanket to assuage their fears that employees are somehow "getting one over" on them. I find the latter sort of manager infantilizing and insulting. I also can't really say that I find it difficult to judge the productivity of remote software developers, having been in position to evaluate it for remote reports over a number of years. It's actually, in my experience, more or less identical to judging the productivity of local developers? I don't really understand what work output you'd be not seeing from a remote developer that you would see from an in-person developer, that would impact your ability to assess their productivity? Are you just attempting to count butt-in-seat hours and call that productivity, or something? Do you not have rough estimates of how long work items should take? Estimates in software miss constantly, of course, because consistently and correctly evaluating the complexity of a task a priori is well-understood to be very hard, but when a task misses estimates due to unexpected complexity, the extra complexity of the task will generally be obvious in the code you see in the eventual PR. Is the end work you see in PRs from your remote team consistent in terms of size/complexity/quality with the time that daily standup updates indicated was devoted to it? If the former seems "consistently inconsistent" with the latter team-wide, have you looked at how your project management processes might be causing a loss of productivity that you're misinterpreting as being related to butts-not-being-located-in-the-magical-seats-you-can-see? If it's "consistently inconsistent" with only one or a small subset of your team, have you devoted time to jumping into regular pairing sessions with those team members, to evaluate whether it's a skill-gap situation, or them perhaps struggling with a lack of detail (or too much detail) in the tasks they've been assigned, or if it's truly just a lack of effort situation (in which case, again, fire them, don't imagine that somehow a magical seat-in-your-sight will fix their fundamental lack of professionalism. Open offices are not even remotely immune to the presence of freeloader developers). Even apart from evaluating the effort, quality, and complexity of output you're seeing in PRs, or tickets they're writing, or solutions to problems they're proposing, in my experience daily standup updates are pretty qualitatively different between people who are doing the work versus people who aren't and are just spinning bullshit, and that's no less true on a remote standup than an in-person one. It also becomes instantaneously obvious the second you say "hey lets jump on a hangout after standup and you can walk me through the problems you've run into and we can brainstorm some work arounds".