Depending on who you ask, “remote” working is either gaining steam in the tech industry or still a coveted-but-rare perk for the lucky few. A pattern that seems to be emerging is this:

• Tech giants like Amazon and Google, wagering that their corporate brand and bidding power are strong enough to attract and retain local talent, are doubling down on co-located teams. Amazon’s choice of “conventional” sites in Northern Virginia and NYC for their much-hyped HQ2 presence, as well as Google’s announcement that it’s doubling its presence in NYC, seem to support this.
• Meanwhile, smaller tech companies are slowly (reluctantly?) coming to terms with “remote” working, as they are increasingly squeezed by talent availability and costs in giant tech metros like San Francisco and NYC. (For some reason, few people want to move there.)

There are the conventional objections to “remote” working: namely, VCs hate it, and simple path dependence leads many founders to not even consider it until a solid co-located team has been established. Adopting “remote” working is not simply a matter of hiring someone out in Sioux City – it involves a series of intentional organizational and cultural changes that lots of stressed leaders just don’t want to deal with. Moreover, all of us start with basic inherited ideas of old-fashioned “work culture” that don’t really translate into the knowledge economy of 2018. These are all real, but solvable, obstacles to overcome.

But one largely overlooked obstacle to the adoption of “remote” working is the popular conception of how it actually works, the root of which has to do with all the quotation marks you’ve seen here so far. The term “remote” work itself implies tasks being done at arm’s length, and at some critical remove between object and subject. I’m here, and “the work” is over there, in other words. Like anywhere, this framing is critical. And it’s also mostly wrong. Don’t adopt “remote” working. Adopt distributed work.

What “remote working” calls to mind is something like a solo contributor at home connecting to a workstation at a corporate headquarters to run large jobs on a server. In this case, the employee is truly “remote” in the sense that s/he is in one place, and the “work being done” is in another.

Yet in knowledge industry companies, that’s not the way things are. Rather, we work on shared digital artifacts, both individually and in teams. Whether you write code, text or build marketing collateral, “the product” lives online, where it is tracked, version controlled and saved for anyone’s review. If “the product” is this content, then “the work” is the generative process behind it, which again, is usually done in some combination of individual and team-based settings (eg. meetings). The individual component of that, in my own experience, is often the most valuable.

I’ve found that the number of meetings on your calendar is directly, inversely proportional to your productivity on any given day. That obviously isn’t to say that all meetings are bad or a waste of time, but most work cultures do tend to have a bias towards them that isn’t very conducive to peak team productivity. Teams hold more meetings when they don’t have enough important work to do otherwise.

Distributed working

In the modern knowledge industry workplace, the majority of collaboration is done digitally via email, instant messaging or chat, and sometimes voice or video calls. We have meetings as well, of course, but I’d be willing to wager quite a bit that compared with the volumes of other communication we receive (particularly email and chat), these are a minority of our interactions with colleagues. The great irony of our time is that hundreds of thousands of knowledge industry workers are forced to live near giant metropolitan areas at very high cost and with long commute times simply so that they can congregate at an office, don noise-canceling headphones, and then communicate with each other primarily through email and Slack.

“Remote working” doesn’t truly describe the alternative to this state of affairs. Instead, I think “distributed working” is a better way to grasp the way a company organizes itself to fully capture the value of these tools.

Distributed working – or “distributed teams” – refers to a system of organization in which the company exists mainly in its digital form. As a knowledge industry firm, its products are digital, live online and are accessible to anyone who needs them; its work is done both individually and collaboratively. When collaboration is called for, everyone reaches for the wide array of digital tools available: anything from simple chat or telephony all the way to conference calls, shared Trello boards, Google Docs/Sheets and the like. This can all be done pretty much regardless of geography, and actually looks a lot like what co-located teams do today anyway. The only difference is that in a distributed model, those teammates aren’t all sitting under a single roof.

In the same way that distributed computing systems offer the advantages of scalability, fault-tolerance and overall efficiency, distributed working promises the same:

• Scalability – any co-located company is limited to a labor market of some commutable distance surrounding its headquarters. Particularly for smaller companies competing with GAFAs for talent in a big metro, this can be a formidable challenge.
• Fault-tolerance – as a result of its much larger potential labor pool, a distributed company isn’t hamstrung when personnel with key skills leave the company. Backfilling critical skills is much easier when geography isn’t a limiting factor to sourcing talent.
• Overall efficiency – even with generous allowances for employees’ home workstations and semi-regular travel to meet in-person, distributed teams are usually much less expensive and more flexible when compared with the costs of centralized HQ office space – particularly in expensive metros.

But what about collaboration?

The most popular criticism of this style of working is that it supposedly doesn’t work for “deep” collaboration. Maybe it’s fine for coordinating tasks, critics say, but it can never replace grabbing a few of your colleagues for an in-person whiteboard brainstorming session. (Whenever I hear this criticism, my first sympathies are for the critic’s colleagues, who apparently live in constant fear of being “grabbed” and their work derailed by their coworker’s sudden need to brainstorm.)

As someone who’s done a fair amount of whiteboarding with colleagues too, I agree that in-person collaboration can be highly valuable. In fact, getting a whole distributed team together in-person once a quarter or half is a popular approach for companies that use this model, and of course smaller, ad-hoc meetings can be arranged as needed too. These are good opportunities for things like long-term planning, roadmap strategy, design ideation and so on.

That said, I just don’t encounter the need for deep strategy and vision-setting sessions with cross-functional teams of my colleagues on a frequent basis. As I’ve written about before, Product Management is mostly about consistent execution of plans, not painting high-level visions. The “vision stuff” is certainly important, but it’s just not what most of the job really is. Instead, most of the Product Management function is about keeping track of 5 or 10 (or 20, or…) different threads at the same time, making sure they are more or less aligned, and dipping into “light” collaboration with lots of different colleagues on a regular basis. Many or most other functional roles operate very similarly.

This, in fact, is perfect for a distributed working model. The great thing about digital interaction is that because it’s asynchronous, it not only allows for multiple simultaneous threads of requests/responses, but it also lets a person turn off those notifications and focus on one task when necessary. Victims of open office layouts everywhere weep at the thought.

Some personal experiences

I worked on distributed teams for almost four years, first on a product marketing team and then as a product manager. I worked with colleagues spread out across the U.S., and even in Europe and East and South Asia to boot. And you know what? It worked just fine.

The biggest key to making a distributed working model succeed is to program the organization’s “work culture” with a bias towards using those collaboration tools I mentioned. In our case, since there was effectively no real “headquarters,” of course every meeting had a WebEx and a conference line. We used other tools as necessary, but honestly found that plain old instant messaging, email and telephony fulfilled 95% of our needs. If we’d had Slack and Trello then, I imagine we could’ve done even more. But as it was, we ran a highly successful, multimillion-dollar run rate SaaS business more or less completely distributed. Anyone who says that distributed working “just doesn’t work” just… hasn’t really tried it.

I also had the experience of truly being a “remote” employee at a highly HQ-focused firm. That experience was more challenging. While I still managed to be pretty effective, I found that “face time” up at HQ was an unspoken but ultimately necessary part of the job, and it came at the cost of lots of time away from home. I didn’t like that.

Technological advancement is creating both new types of work that must be done, as well as new ways to do them. Yet most knowledge industry companies resist these advancements with the same reluctance and suspicion of a horse carriage maker towards a combustion engine. Between the increasingly unattractive economics of giant metropolitan living and the advancement of new collaboration tools, distributed working models are a fundamentally disruptive organizational technology for the way we work. A few smart companies are adopting them today and positioning themselves for long-term success. The others better hope that this internet thing is just a fad.

Edit, 11/19: This post went to #1 on Hacker News today. I guess it touched a nerve! This made it my new most-viewed post ever. Good work, everyone.