Photo: candlescents/Creative Commons

Because of Marissa Mayer's recent change to Yahoo's remote working policy, three portfiolo companies sent us blog posts on the topic of working remotely. Check out Part One, and Part Three.

Previously posted on PixelMonkey

It has become increasingly common for technology companies to run as Fully Distributed teams. That is, teams that collaborate primarily over the web rather than using informal, face-to-face communication as the main means of collaborating.

This has only become viable recently due to a mix of factors, including:

• the rise of “cloud” collaboration services (aka “web 2.0″ software) as exemplified by Google Apps, Dropbox, and SalesForce
• the wide availability of high-speed broadband in homes that rivals office Internet connections (e.g. home cable and fiber)
• real-time text, audio and video communication platforms such as IRC, Google Talk, and Skype

Thanks to these factors, we can now run Fully Distributed teams without a loss in general productivity for many (though not all) roles.

In my mind, there are three models for scaling number of employees in a growing company in the wild today. These are:

1. Vertically Scaled: Fully co-located team in a single office. Need more people? Get a bigger office. Communication is face-to-face preferred, digital as necessary. I suspect Dropbox operates this way right now with its new and huge primary office in San Francisco. In Web 1.0, most companies were scaled this way out of necessity.
2. Horizontally Scaled: Several co-located teams in geographically separate offices. Communication is face-to-face preferred for employees in same office, digital preferred for employees in separate offices. I suspect Foursquare operates this way with offices in New York, San Francisco, and London.
3. Fully Distributed: There is no dedicated, co-located office. Digital communication is preferred for all communication. Github, Automattic, 37 Signals, and Basho operate this way today.

Choice 1 is the most “traditional” scaling approach. The theory behind this approach is that face-to-face communication is the most efficient collaboration method. Nice offices are the best way to build team camaraderie and attract the best talent. It can be tempting when growing to switch from a Vertically Scaled team to a Horizontally Scaled one, by simply adding a second office location.

Choice 2 is typically how small, colocated teams end up becoming “semi distributed” teams via multiple offices connected via web-based collaboration tools. In other words, some companies that are going through growing pains under a Vertical model may switch to Horizontal as a coping mechanism. If there is a talent shortage in a Vertical team’s original headquarters location, or if enough office space cannot be procured to sustain employee growth, Choice 2 may be seen as the only option on the table.

Choice 3 is probably the rarest among growing technology companies today, but is, as I mentioned, increasingly common. In Fully Distributed teams, there is no real “headquarters” or “central office”. All communication is digital-preferred, which means employees can work from anywhere and not be fearful about out-of-band communication. Typically, employees will set up home offices or work out of coworking spaces in their home area. Occasionally, the team will still have a “headquarters” office, though this office will often be reserved for things like management, sales, marketing, business development, or other operational roles that do not need to be scaled as heavily.

Choice 3 tends to work extremely well for technology-heavy teams due to a few factors:

• Tools for doing distributed collaboration on software projects are very mature thanks to the open source community, which has been doing this at scale for years. To give just a few examples: source code control is web-based, hosted, and distributed (e.g. Github); all good project management or bug tracking tools are web-based; production systems can be effectively managed using SSH; team knowledge bases can be built effectively using wiki technology/conventions perfected by projects like Wikipedia; many web-based tools are available for all other forms of typical “office” collaboration such as document editing, file sharing, and instant messaging.
• Software engineering requires long periods of uninterrupted focus, aka Flow. Working in an office environment tends to involve lots of interruptions and meetings; working from home, by contrast, (assuming a separate home office) guarantees a high comfort level and long periods of concentrated work in private.
• Great software engineers have eccentric work habits and quirky computer setups. Many software engineers report getting their best work done between 10pm and 2am or between 7am and 9am. Many intensely dislike commutes and rigid work schedules. Most have heavily customized their personal development workstation to be greased for productivity. Many report getting some of their best ideas in the shower or after a nap. Working from home in a Fully Distributed model offers more opportunities to leverage their established (and optimized) work style which would be socially unpalatable in an office environment.
• The best software teams are merit-based. That is to say, success on a great software team is measured by working software, not by the number of hours the engineer has planted his or her butt in an office chair. Success is definitely not measured by the number of meetings you have held or the quantity of your communication. Fully Distributed technology teams make working software the only reasonable deliverable a team member can provide. Thus, these teams naturally self-organize around its most productive members and shine a spotlight on poor performers.

Related Reading

Github’s fully distributed team is described well in this GigaOM piece, Tales from the Trenches: GitHub. Zach Holman’s presentation, How Github Works, also provides an insider’s take. Github is interesting because though there are 77 employees and the team operates in “fully distributed” mode, there are a significant number of engineers at the company’s headquarters in San Francisco (perhaps as many as 30 by some reports).

The CEO of Automattic, the company behind WordPress.com, describes 5 reasons why your team should be (fully) distributed. They also discussed their distributed culture and collaboration environment on their team blog. This AllThingsD article points out that the company grew to over 100 employees and over $45 million/year in revenue with no central office.

Basho, the creators of the distributed database Riak, are a fully distributed team of nearly 75 employees, millions per year in revenue. An excellent blog post on Basho’s blog dated last year describes their distributed culture. The person who wrote that post also provided a breakdown of headcount by job function: Engineering/Support: ~20, Executive: ~6, Sales/Marketing: ~7, Admin: 1.

37 Signals founder DHH wrote about the technology “talent shortage” to “Stop whining and start hiring remote workers”. In it, he indicated that 37 Signals distributed team includes employees from: Fenwick (Canada), Phoenix (Arizona), Caldwell (Idaho), Romiley (UK), Jefferson Hills (Pensylvania), Ann Arbor (Michigan), Boulder (Colorado), and Tampa (Florida). Another great post from their blog talks about Equality and Remote Teams — noting a negative behavior that happens in Semi Distributed teams where remote workers are seen as “second-class” team members to those in the “primary” office, and what they did to eliminate this behavior.

Fully Distributed: is it fully viable?

I have heard many VCs and business school academics describe distributed teams as a big mistake. To me, this makes perfect sense. VCs and academics are themselves only in the early stages of seeing their own business models disrupted by distributed financing and distributed education. So long as there is still a strong premium placed on face-to-face interaction in their own fields, they will assume it holds true for other fields, as well.

Vertical/Horizontal Scaling are “proven” Web 1.0 techniques for growing companies (think of Google or Amazon), while Fully Distributed is as of yet unproven. VCs in particular like to remove whatever risk factors they can from deals — the Fully Distributed model seems like a risk with no corresponding upside, especially if capital is cheap and talent is widely available.

But perhaps the biggest reason for distrust of Fully Distributed teams is simply past (and out-dated) experience. VCs and business school academics are typically older. They have lived through an age where corporate America became obsessed with Information Technology and its hyped ability to virtualize and distribute all communications, even when Internet connections were slow/unreliable and collaboration software was beta-stage, at best. Thus, they associate digital collaboration tools with the slow/frustrating kludges of yesteryear. They have also not yet fully internalized the various ways in which Internet distributed models have beaten centralized/co-located models in advanced collaboration — some big examples here include Wikipedia and the Linux kernel.

Fully Distributed’s viability is a recent development — I suspect we only reached the threshold about 3 or 4 years ago. But believe me: we have reached it. It is now a fully viable model alongside the other two more traditional organization scaling models. And it will become increasingly common in the next few years as the tools get better and the option becomes accepted by the wider ecosystem.

Other fully distributed teams discovered since publication: MadMimi (25 employees, all work-from-home); Canonical (multi-timezone distributed team; run like large open source project); Mozilla (they call themselves “remoties”); StackOverflow (16 full-time remote, 18 in-person office, but fully distributed “DNA”)

Discuss on Hacker News

Contributed by Andrew Montalenti, CTO at Parse.ly