"Zoom orders workers back to the office" is funny, but there's nothing unique about Zoom doing it.

All these companies show that they don't understand how effective work is actually done, and how to organize around that. Instead, they're relying on the implicit benefits of the past where work _happened_ to be done in person (but they don't know how).

As I coach software teams (and do so remotely), it's pretty clear that the root problem is that folks never knew how to work together in the first place.

And I do mean "work together," not folks siloed in their little caves where you have no idea what they're up to.

Working together is a skill, it doesn't come for free. It can be learned. It can be taught.

An old coworker of mine replied, "Organic, spontaneous cross-organization collaboration is much harder to do when everyone is remote." Hmm. Let's dig into that a bit.
There are certainly benefits to being in person. But "collaboration is much harder to do when everyone is remote" isn't because people are remote. It's because people work in systems that are designed to inhibit real-time spontaneous collaboration. Examples include passing JIRA tickets around, Pull Requests, individual assignments, reviews based on individual performance, planning meetings, high Work In Progress instead of limiting WIP… The list goes on and on.
Unlocking Effective Collaboration: Beyond the Return-to-Office Mandate

Will return-to-office mandates improve productivity?

Industrial Logic - Modern Agile Consultancy

@qcoding I’ve been doing lots of user interviews and synthesis over the last few weeks.

It’s *much more difficult* remote. The tools aren’t there. Miro suuuuucks compared to a real whiteboard. Long Zoom meetings are much more fatiguing than in person.

We use Tuple for pairing. It’s the best option by a long way and it’s significantly worse than two people/monitors/keyboards/mice in-person. We don’t (can’t!) swap driver/navigator nearly as often.

@qcoding Bandwidth and latency *matter* and mostly can’t be improved (I’ll have the option of fibre in 2024… maybe? And I’ll still be 100ms away from my colleagues.)

Finally, don’t make the mistake of comparing a shitty car commute to a crappy office to biking to a nice office space with good equipment and great support staff. Your point about knowing how to collaborate is a good one, but technology and tools put an upper bound on what’s possible with remote.

@ratkins Thanks. You're may be the rare outlier who already had good practices, so for you it is a step down.

Have you tried using mob.sh instead of Tuple? "Driver drives their own machine" ensures zero latency. Handover is fast because mob.sh uses Git under the hood without you making commits, pushing, pulling.

@qcoding I’ll take a look at mob.sh, if it does what I think it does it’ll help. Latency for the navigator is the main issue though, it’s sometimes difficult to follow what the driver is doing across slow screen updates.

@ratkins @qcoding

Interesting. I always felt that Miro is way better than real whiteboards. Faster typing than writing, copy&paste of any kind of material, links, easy archiving and search if needed, no waste of paper, integrated tools like timers, voting make it easy and effortless and etc. just work…

Really, the physical whiteboard, I didn’t miss it from the first second on.

@ratkins @qcoding

Oh, did I mention: no boundaries (so we’ll not run out of space), easily changing everything afterwards, no unreadable handwriting, no crappy photos of whiteboards that need to be archived or rewritten on computer, easy copy&pasting of whole boards (e.g. for templates)…

@fxnn @qcoding Slow, every time I click something I accidentally move it, looking at an infinitely large whiteboard does me no good if I can’t see both my post-its and the frame I’m meant to be clustering them on at sufficient resolution (because I can only see a tiny window of the whole board at once), the affordances of a mouse just aren’t as good for moving notes around as the IRL version.

@ratkins @qcoding

Interesting, thanks for your thoughts! We see that it, as always, entirely depends on the audience :)

@fxnn Yeah. As @qcoding points out, I’ve had the incredible fortune to have worked in an environment which was specifically and thoughtfully crafted with the goal of supercharging developer productivity (Pivotal Labs.) Once you’ve seen what’s possible, management half-arsing it is intolerable.
@qcoding
Exactly — I've found out, however, that when I work in such a system, encouraging my fellow developer teammates to come to the office enables me to underpin the broken system. Instead of writing a Jira ticket, I just go to their computer and ask about a certain behavior to see if it's a bug. If it is, I ask them to bring up the code to tell me what it does, then I help them fix that bug, all without a PR, because I'm already here — it's easier to build trust and minimize fear in person.
@sewera Very true. Like you, I have worked to subvert broken systems from inside. You're taking advantage of the chief benefit of in-person work.
@qcoding Preach it! Give xi an English major who can write effective documentation over a CS major who can't explain their own code any day.
@jaycie One of the best devs I ever worked with used to be an English teacher. She would always ask the BEST questions.
@qcoding Exactly! Drama major xirselves (3D animation) but made a career out of self-taught programming skills.

@qcoding I saw collaboration increase when everyone went remote because the terrible office environment was actively impeding collaboration.

But then I've also seen the benefit of office spaces actually designed for collaboration.

@benjiweber Yes, the "open office" idea was co-opted from Extreme Programming where people could rearrange their space to gather the people they needed. You know, as opposed to lining everyone in rows where the real purpose was cost-cutting instead of supporting collaboration.