I’ve been interviewing a lot of developers lately at my day job as the CTO of a tech consultancy, and I’ve noticed an interesting trend. Many of them seek us out because they want to work remotely. That’s not new. What’s new is that an increasing number of them are already working remotely … pathologically.
“We’re remote-friendly,” companies claim, but often that means some of the team is remote, while half or more are on-site together — a configuration that can easily become the worst of both worlds. The remote developer(s) feel like black sheep, odd ones out, perpetually missing out on context and in-jokes and osmotically shared knowledge, always having to run just to catch up.
Meanwhile, the on-site team members have to halt or table spontaneous jazz sessions in order to wait for “the remotes” to join them, at the previously agreed-on times, in order to come to decisions. In situations like this, even when everyone gets their work done, at best the setup is a constant annoyance … and at worst everyone’s morale and motivation is constantly being sapped.
Companies try to address this with things like daily stand-ups. Or, as I like to call it, “cargo-cult agile.” Agile development is very remote-friendly. Cargo-cult agile is not. It confuses a daily stand-up with inclusion and a common mode of communication. Believe it or not, agile development is not about stand-ups, sprints, tickets and spikes. It is about, to quote the original Agile Manifesto, valuing:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Let me just repeat that first one again. “Value individuals and interactions over processes and tools.” Individuals and interactions over processes and tools. Individuals and interactions over processes and tools. INDIVIDUALS AND INTERACTIONS OVER PROCESSES AND TOOLS.
So what do companies do? They define a set of “agile” processes and tools, and equate agile development with following those processes and using tools. It is to weep. But if you want to include remote individuals so that both you and they get all the benefits of remote work, without them feeling like neglected second-class citizens, interactions are the key.
Let’s talk about synchronicity. Fully local teams tend to exist in a cloud of synchronous communication. Small talk when you come in. A quick question when you walk past their desk. Impromptu sit-downs. Someone else overhearing your question, and joining in to riff on it. What’s more, you can easily check to see whether someone looks busy, or lost in code, before coming to bother them, which means you’re more likely to do so. There’s no shortage of emails and Slack calls and scheduled meetings, of course, but they exist above a substrate of casual (and sometimes not-so-casual) chatter.
That substrate does not exist for remote workers. Communications with them are, inevitably, more refined, less casual. There’s no “how was your weekend” when in the elevator together; at best you might ask it as a quick prelude to the thing you really want to talk about. So remote workers miss out on both the feeling of in-person belonging and community, which they can tell exists among the local workers, and the little work-related mini-discussions and mini-decisions that grow out of that chatter. No wonder they so often feel a little like exiles.
As a result, when you’re remote, scheduled synchronous communications like stand-ups, or other video calls, are no substitute for the absence of unscheduled asynchronous ones. Inclusion doesn’t require fancy tools. Email, Google Docs and a single Slack channel will do — if people actually use them. But that Slack channel has to be the primary water cooler in order for your remote workers to feel like first-class citizens. This obviously comes easily for primarily remote or remote-only teams. It’s a whole lot harder for those with one or two faraway people.
Other things help too. Meeting people face-to-face, if only once. (Although there are people I have worked with closely for almost a decade whom I’ve never met; I have hacker friends who go further and speak dismissively of “meatspace” as a whole.) Sheer personality matters, too: some people are extroverts who need people around, which isn’t optimal for remote work. But ultimately it’s about reshaping your interaction model to better include those individuals who are far away yet part of your team.
Lots of organizations talk about being remote-friendly, when what they actually mean is remote-permitted. Those are two very different things, and developers are justifiably increasingly skeptical of the latter. By far my most effective recruiting line when this subject comes up is: “I’m the CTO, and I’m fully remote myself.” Skin in the game, as Nassim Taleb would put it. But in truth, every company that currently employs disgruntled, unhappy, remote-grudgingly-allowed developers have skin the game already, too. They just don’t understand how it’s played … even, or especially, when their best people begin to leave.