I find myself on all sides of the remote engineering debate. I have managed large remote teams from China to Argentina. I have a handful of remote engineers today at Artsy in places like Boston, Salt Lake City, and Amsterdam. Some were hired remotely, others have moved from or are moving to New York. I have recently had a remote developer in London quit after having been refused an H1B twice because of quota. And I have moved to the U.S. on an H1B visa myself in 1999. Finally, I often collaborate on open-source projects, where I am remote and have never met and will likely never meet the other collaborators.
I don’t see remote engineering as a barrier. In this post I would like to offer a more pragmatic approach to embracing it, while still preferring face-to-face collaboration.
In his open letter Let the Other 95% of Great Programmers In Paul Graham writes:
We have the potential to ensure that the US remains a technology superpower just by letting in a few thousand great programmers a year.
As a non-American I don’t feel as patriotic. I eagerly advise European engineers not to get too hung up on moving the U.S. and to head to Berlin rather than New York or San Francisco in order to avoid the visa hassle. Berlin is a fantastic city, young and fun, cheap and thriving, dense with tech startups and very culturally diverse. I have spent many years in Europe during my college years and would have rather moved to Berlin than Seattle in 1999, had it had a technology center then. With companies that include such names as SoundCloud, it definitely is a technology center now.
As a followup to Graham’s post entitled How Paul Graham is Wrong Matt Mullenweg writes:
If 95% of great programmers aren’t in the US, … set up your company to take advantage of that fact as a strength, not a weakness.
Taking the opposite position in Why Remote Engineering is So Difficult, Steven Sinofsky lists the challenges of doing just that. He writes:
If I had to sum up all of these in one challenge, it is that however you find you can divide the work across geography at a point in time, it simply isn’t sustainable.
Let’s unwind this last one. In my personal experience working there, Microsoft’s remote teams were always treated as second category citizens and were never given a chance to succeed. During the first decade of the 21st century the company’s executives spent a tremendous amount of time and effort destroying organizations that were acquired world-wide. New York’s own Massive Inc. was a perfect example, wound down from a successful engineering culture into oblivion of the Seattle suburbs in just a few years. Amongst all the reasons Sinofsky listed in his post, he omitted the one I would write about the most - Microsoft’s senior management prefers to hold power close to Redmond, where individuals look more alike, and control structures already in place can be exercised quickly, swiftly and at scale.
Sinofsky’s dividing work is another construct that makes remote engineering almost impossible. It assumes that the organization must closely map to software - Sinofsky himself ran the very much top-down and undoubtedly successful Office team. However the results resemble the organization: a massive codebase that takes 5 years to ship, is slow to maneuver and requires huge investments to turn around.
Other successful models organize teams around the customers. A typical cross-functional team that focuses on a consumer could, for example, be shipping the website product and a mobile application and would be composed of designers, product specialists, marketers and developers. A such successful organization is flipped upside-down where managers aren’t distributing tasks and work at the service of the individual contributors. The latter can collaborate with both technology and face-to-face as they see fit, while experiencing much higher sense of ownership and feel empowered to act on their creative freedoms. Of course, that is much harder to accomplish than a military style command-and-control stack-ranked herd.
Matt Mullenweg’s suggests we use technology to solve the remote engineering problems:
Use WordPress and P2, use Slack, use G+ Hangouts, use Skype, use any of the amazing technology that allows us to collaborate as effectively online as previous generations of company did offline.
Agreed. Those are, indeed, difficulties that we can overcome by paying a few dollars a month for a service.
That said, I really feel that the real challenge is not a technical, but an organizational one. If a team solves real world problems, I would want it to resemble closer that real world they live in. A product with a global audience should be delivered by a global team with diverse skills and opinions and strong regional differences. And as technology leaders, we should seek to fill the gaps and to enlarge the spectrum of possibilities within each individual small group.
Personally, I hire T-shaped people with a very wide set of interests and narrow specialities. And I am lucky to be able to find a lot of those people in New York City, where every culture is represented and where the best people, including engineers, flock. And when I see someone exceptional that fits this profile and that doesn’t live here, I simply don’t make their location be the deciding factor in joining my team.
To summarize, I prefer working with people locally and value face-to-face collaboration, but I also think the other thousand qualities they bring to the engineering game are often more important, which makes their physical whereabouts a lot less relevant.