And that's not even opening the can of worms regarding remote productivity. 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). Sure, people like Nilay Patel (who was mentioned in the story) work from home with great success because it allows them to control their environment. But people like Nilay Patel are extremely unique in their motivation, commitment, and aptitude. Companies should be extremely cautious to extrapolate success stories like his onto their own resources.
We moved to open workspaces because of success stories and consultant pitches and hip office trends despite its obvious flaws. The move to everyone being remote has the ingredients of a fad, too.
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".
There are some scenarios (domain knowledge, budget constraints, lack of office space, etc.) that justify people working remotely, so don't take my original comment as a statement that remote teams never work. Clearly they have, and clearly they do. But even if you're just some sort of management Jedi that I'm not, I think there are inherent flaws in remote teams that aren't solved by just having the right people.
If you're a non-software developer managing software developers, that's (in my experience) a profound organizational issue that simply does not work in any situation, open office or remote. If you lack the skills to actually evaluate the work output by your reports, then you're left with piss-poor proxies that are more noise than signal and frequently have no correlation to what productivity actually looks like in the field.
Evaluating ability, progress, and effort can be done as more of a human problem than a technical one. Heck, current or former developers are more prone to overconfidence in their assessments, especially when they're not personally neck-deep in the exact area.
A good people manager can smell a slacker based on a wealth of signals from 1-1 meetings and the overall flow of work. But the strongest signals come from what the manager picks up from your coworkers, who are almost certainly going to be more qualified to evaluate your progress than the manager could be.
People can still slack off and put up a bullshit screen that'll fool their coworkers for a while, because they're not watching for it. That's not their job anyway, that's the manager's job, and they don't need to be able to hand-code an encrypted distributed hashtable to smell a rat.
That said, it depends on who you have. Some developers need oversight from a knowledgeable manager, especially when remote. Some don't. The purpose of management extends well beyond evaluation, which is more of a cure that you'll need inversely proportionately to how well you do prevention (team dynamics etc.)
Laughable; phones have worked for decades. Your brain and mouth and ears don’t stop working, do they? Furthermore you are greatly overestimating the proportion of high intensity local collaboration to grunt work. The vast majority of tech jobs could be remote overnight and nothing would even slow down. These jobs are not hard or collaboration intense regardless how cool your employer makes you feel about coming into the office. It’s just hard work like any job, and in person collaboration is a miniscule part of that. In reality people like their offices and that’s 100% fine, just don’t ask me to move to your city so you can feel more comfortable asking me how something is going or what I think about x idea.
I think acceessibility is a broader issue with remote work—remote desktops don’t play well for the blind.