Remote Revolution

Paul Graham wrote an essay recently about immigration and the tech industry. Matt Mullenweg wrote a response mentioning distributed teams as a solution and there was a thread on Hacker News with additional discussion about colocated versus distributed teams. Steven Sinofsky wrote a response to all of those.

I am all for changing immigration laws. If someone wants to move to Silicon Valley from outside the country to work I think that is wonderful and they should be allowed to do that. I do not, however, believe that the future of the technology industry lies in colocated teams.

Exceptional programmers are difficult to find. If we take it that exceptional programmers are rare and necessary for success then it would seem incumbent on the companies who need these individuals to maintain work environments that remove barriers to working with them.

I have been working in the tech industry for twenty years modulo hiatuses for creative projects. I have spent roughly half of that time colocated and half of that time distributed. I do not have conclusive or broad data to support what I am about to write; even if data was available there well may not be enough of it yet.

Distributed teams are an innovation enabled by technology. Arguments of authority–Google is not distributed, Facebook is not distributed, ask startup founders why they do not use distributed teams–are ludicrous. Gather around let me tell you about a little thing called disruption.

I am reminded of the late 90s when people were debating the use of Linux and other open source projects in production. “All the successful companies use Sun! Talk to CEOs they will tell you they buy Sun because Sun is what you need to get the job done! You. just. cannot. be. enterprise. with. Linux. it. is. not. true.”

The last time I dealt with Sun (circa 2003) they wanted me to renew a $35,000/year maintenance contract on two servers. The one time I had used them it took five business days to get a failed RAID drive replaced. I said no thanks and invested the money into ten FreeBSD servers, keeping five as spares. Those spares wound up as a cluster enabling the organization to innovate in ways that would not have been possible had we wasted resources doing things the old way. Today that much money would pay for ten nice EC2 instances and related supporting AWS services without upfront costs, facilities, maintenance, etc.

The feedback loop seems clear: innovation reduces friction, reduces barriers, reduces cost thus fueling more innovation.

These are not the wild west days of outsourcing projects to hustlers cobbling together low quality teams. This is 2015; we have GitHub, Stack Overflow, job boards for distributed teams, massive numbers of contributors to open source projects. Today quality remote workers and companies can find and evaluate each other directly.

The way I see it this comes down to synchronous versus asynchronous communication. We started with synchronous communication. We built empires on synchronous communication, we developed techniques and processes and hardware architectures all around this idea of synchronous communication. But as time passed we realized what a drain of resources it is to always employ synchronous communication so we started looking at asynchronous communication. Oh no! What a disaster! We designed all the things for synchronous communication! As technologists how did we approach this problem? Did we dig our heels in and start screaming for more and more powerful hardware to keep the old ways afloat? Yup. How did that work out? It gave us a little breathing room but then we had to put on our big kid pants and acknowledge the reality that we could no longer continue to cram everything into one place and expect it to scale. We had to change processes and the way we approach problems. And what happened? We discovered better ways to do things. Not merely different ways or almost-as-good ways, but better ways.

Asynchronous communication is efficient because senders do not have to wait for a response. People choose text messages over phone calls for the same reason. In 2015 we choose abstractions, languages and frameworks–functional programming, actor systems, immutable data structures and so on–that support asynchronous communication. But eventually we get to a point, for example writing to a physical device, that requires synchronous communication. Similarly while distributed teams choose tools and processes that support asynchronous communication there are times when synchronous communication is necessary. The day-to-day implementation of this can vary by team–team video calls and 1-1 manager video calls and so on–but something I believe should not vary for long-running teams is getting together once or twice a year for a few days on the company’s time and dime to do something fun. Not a tech conference or an all-hands work meeting but something fun. It does not have to be a whitewater rafting excursion; getting together in a centrally-located city and visiting museums is great too. There is a level of intimacy that only comes from having had face-to-face interaction, but people do not have to work in an office together to make that happen.

When people are focused–in the zone–interruptions can be expensive. We respect this with surgeons because the consequences of interrupting a surgeon concentrating are obvious. We respect this in the library. We respect this on the golf course. We have recognized it as an issue with colocated teams for more than half a century–Herman Miller introduced what would become the cubicle in 1964 based on research into open office layouts that concluded open environments actually reduce communication between employees.

A few weeks back there was an article in The Economist about cubicles and how workers could break free of them.

“Workers, the Cornell study suggested, like closed offices best of all. But open-plan offices are preferred to cubicles.”

“For reasons of economy, if nothing else, a return to private offices seems unlikely. But mobile technology is making it possible to work anywhere. Could it also offer an escape from the cubicle farm?”

Curiously the article fails to mention remote work as a solution.

I believe a well-run distributed team has more transparent and less siloed communication that leads to better collaboration. This may be a tortured analogy but I think of it like Facebook versus Twitter–you may have more friend-to-friend bandwidth on Facebook but on Twitter everything is open and transparent which leads to insights outside of one’s circle of friends and to the natural formation of groups of collaborators. Before I really “got” Twitter I thought it sounded like a horrible idea–strangers following me and me following other people just sounded creepy and there cannot be any depth with this character limit and blah blah blah. It was not until I had to use it for work that I really got that it was not a pale substitute for Facebook but rather a genuine advancement in human consciousness and communication. This is also how I feel about distributed teams.

A well-run distributed team primarily communicates via group text chat like Slack. As much as possible all communication happens in various channels that form by team or project or whatever fits best. Communication happens asynchronously, transparently and is immutably logged. Conversations are not lost or forgotten; they are viewable and searchable. People can be included in conversations more easily because they can participate asynchronously. New group members can quickly be brought up to speed on a given topic or issue by referring them to relevant logs. Cross referencing code commits with tickets and publishing changes either directly to a group’s room or to a “newsfeed” room provides amazing documentation. If I want to know why something was done I can look at the commit, find the ticket and find all the relevant discussion about that, how the solution was worked out–it may have required something beyond just code such as infrastructure changes or contacting a service provider. Colocated teams can do this somewhat, but there will always be large gaps that require relying on people’s memories of events to resolve. Fitbit > trying to remember what happened. You may say the need for this does not come up often and you would be correct, but when it does come up it can save days or even weeks of time. It can be a lifesaver in time-sensitive situations like production outages. It can help prevent service regressions. As technologists we love data, we can learn from data, we can use data to improve our processes. Distributed teams produce more and richer data about themselves and the work they do than colocated teams.

An industry embracing Big Data should look for ways to apply those insights to itself.

Is the world ready for asynchronous work? It took Slack less than a year to reach a billion-dollar valuation. A list of companies that use distributed teams I started last month already has over a hundred listings. Remoteville is well on its way to being a major tech hub and we have not even begun to tap the possibilities. Given asynchronous work environments and the decoupled nature of functional programming it is not difficult to imagine trivially outsourcing coding tasks down to the granularity of a single function if we had the software tools to frictionlessly manage such a process.

Should everyone work on distributed teams? Of course not. There are many varieties of people with different working styles and interpersonal needs at different stages of life. By all means support workers who want to cluster together, whether that means maintaining official offices or paying for cowork space or whatever works. The idea is not to force distributed teams but to create and maintain a workplace that is asynchronous by default to maximize transparency and efficiency so all kinds of workers and teams can flourish.

As technologists we do not write blog posts imploring people to please go to gyms because that is the best way to work out; instead we innovate and build wearables that people can use to monitor and increase their activity and fitness levels wherever they are. That is who we are and what we do. We are the cheap plastic solution you should never bet against.

Postscript

In the course of writing this essay I realized asynchronous work is my mission and I do not want to just talk about it–I want to make it happen. I want to make using colocated teams by default as anachronistic as the horse and buggy. I want former homeless people living in renovated former office buildings because we no longer know what to do with all the extra space. I want cities planning to build smaller highways instead of maintaining mile-wide strips of asphalt that are empty except during rush hour.

Harvard recently completed a 75-year study on human (male) happiness. Their conclusion? It is all about love and warm relationships. By making work asynchronous we can get the same amount of work done while spending more time with people we love and cherish, living happier lives as a result.