Fully Distributed Teams: are they viable?

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

29 Responses to “Fully Distributed Teams: are they viable?”

  1. Louis Chatriot Says:

    This really resonates with me: we hesitated a long time before deciding to work as a fully distributed team (well “fully” may be a big word as we are currently 3), but I really don’t regret it, compared to synchronous workspaces where I was disturbed very often.

    In case it interests you, we wrote a book about this experience and the tools we chose, which you can find here: http://leanpub.com/startupflow

    Louis

  2. Jonathan lambert Says:

    Did it for five years with a large team while building multiple companies. We got an office after the engineering team asked for it. And only then. Works great as a hub and spoke but there is an unfair advantage to being office crew sometimes.

    Doesn’t work for everyone, and I don’t think it works in all circumstances. But it will work and scale with exceptional team members.

  3. Saverio Says:

    Fully distributed teams are not always working (therefore, can be “distrusted”) because it just doesn’t work for some people.

    For example, a few friends of mine actually like working in an office.
    Another friend of mine told me he’s setup a fully distributed environment at some point, and it was three times as slow as it was in their previous centralized setup.

  4. Jake Says:

    we are almost totally distributed but we have a shared room full of racked machines for testing, development, etc.

    having a distributed team is great and allows us to cherry pick our development team based on the best people instead of the best people in a given geographic area. only caveat is that people in a given timezone/region should always have at least one other person with whom they share a work schedule. our australian dev doesn’t have much company when he’s hacking.

  5. Chris Jones Says:

    Choice 3 is how Canonical made Ubuntu. I’ve worked there for 6 years and love it. I want all my future work to be choice 3 :)

  6. ubersoldat Says:

    I’ve been working in a Horizontally Scaled company for the past three years and I like the idea of having, at least, the IT teams separate from the business, specially for development teams.
    On the other hand, when scaling either horizontally or distributed , as a developer, you’ll need support. Not on the coding side, but on how the business is run, in architecture, in what makes money and if the business is very complex, I don’t see a fully distributable approach working.
    Another thing which makes a distributed approach difficult to implement is the stress or extra work load on managers to keep thing “in sight”. Many managers like to see their workers on their chair and “manage” on-site.

  7. Richard Brewster Says:

    I recently saw a presentation of a business being run by choice #3. Not software development, but an information processing business. There were a half dozen workers in four cities. Everyone worked from a home office. Dropbox was used for file sharing. Communications was mostly by email, as I recall. The business process was a queuing system, with each worker having an input and output queue. Status was easily tracked by monitoring the queues.

    A question was asked, How do you track worker’s time? Answer: We don’t need to. Worker pay is tied to expected throughput. The business is so small, everyone knows everyone else. If you are not paying people by the hour, you need some sort of work delivery tracking system. A ‘results-oriented’ work environment.

    Programmers in such an environment would need their work tracked by meaningful value delivery metrics. I think that would be an improvement over pay by the hour. But it would have to be a fair and accurate measurement. I’m not sure how it would be done. It’s not always easy to isolate individual contributions to a team project. Project milestones might be used as a collective measure of value delivery.

  8. pixelmonkey Says:

    Great comments here and on Hacker News. I’ll respond to just one of them that stuck out for me:

    “Another thing which makes a distributed approach difficult to implement is the stress or extra work load on managers to keep thing “in sight”. Many managers like to see their workers on their chair and “manage” on-site.”

    Fire those managers. If yours is a creative organization of any kind, those managers are worse than useless — they are actually harmful, and will have a net negative impact on your team and its overall productivity.

  9. Gabor Torok Says:

    Hi,

    Couple of things:
    - Full distribution works only for those who can organize their time. They’re definitely not juniors, they probably don’t have their family at home (to distract their concentration), etc.
    - Since this working method is so young, we can’t know the impact of distant teammates to our “business social life” (as opposed to “private social life”). I know it by experience that it boosts efficiency a lot to meet distant coworkers every now and then and work together at the same location for a while.

    Other than that, full distribution is really here and it’s a viable working method indeed.

  10. Paweł Wrzeszcz Says:

    Hi,

    Great read. I recently presented similar ideas that came from my own experience – “Visibility Shift in Distributed Teams” http://prezi.com/lrosc_z0pzy0/visibility-shift-in-distributed-teams/

    I believe that working in a distributed environment is like using Scrum – it does not solve your problems, but makes them more visible.

  11. Benjamin Wesson Says:

    One of the dangers of horizontally scaled teams (i.e., option 2) is that the members fall into “us-and-them” thinking as the team becomes distributed over time. This is particularly an issue for teams that have grown through acquisition rather than organically. Co-located team members at the company’s headquarters over emphasize face-to-face communication and don’t put sufficient effort into digital communication with their distributed peers. This leaves everyone outside of headquarters “out of band”.

    Teams that are fully distributed (i.e., option 3) don’t have this problem (at least not the same extent) because there is no headquarters. However, care must be exercised to ensure that workers in any one office or region don’t fall into this trap as each sites scale vertically (i.e., option 1).

  12. pixelmonkey Says:

    @Benjamin Wesson, great comment. I agree 100%.

    The purpose of my blog post was to identify and describe the three models I am seeing in the wild.

    I know that horizontally scaled teams have some serious communication issues, typically, for the reasons you outline. Personally, I only consider vertical and fully distributed to be viable scaling models; any attempt to go from vertical -> horizontal should probably be a shift from vertical -> fully distributed, instead.

  13. ff Venture Capital - The Difficulties of a Distributed Team Says:

    [...] May, Parse.ly’s co-founder and CTO, Andrew Montalenti, wrote a blog post titled “Fully Distributed Teams: Are They Viable?” Montalenti grouped team distributions into three categories: 1) Vertically Scaled: the [...]

  14. Working remotely — pros, cons and choices | freePress Says:

    [...] another thoughtful essay with lots of links to sources, take a look at this post from Andrew Monelanti, co-founder and CTO of Parse.ly.) Share it!Like this:LikeBe the first to [...]

  15. Calling all remoties Says:

    [...] http://blogs.hbr.org/cs/2012/08/are_you_taking_your_people_for.html http://zachholman.com/posts/how-github-works/ http://www.pixelmonkey.org/2012/05/14/distributed-teams [...]

  16. Why I Decided to Spend More Time Working from Home Says:

    [...] on having a distributed team. In fact our CTO, Andrew, wrote an excellent piece on whether fully distributed teams are viable. Two-thirds of our team is distributed across the US, Canada and Europe. However, we also have a [...]

  17. Why I Decided to Spend More Time Working From Home | Tips for the Unready Says:

    [...] pride ourselves on having a distributed team. (Our CTO Andrew wrote an excellent piece on whether fully distributed teams are viable.) Two-thirds of our team is distributed across the U.S., Canada, and Europe. However, we [...]

  18. Working from home and distributed teams... - GQAdonis Says:

    [...] read this post this morning about the viability of maintaining fully distributed development teams written by [...]

  19. Why I Decided To Spend More Time Working From Home | Lifehacker Australia Says:

    [...] pride ourselves on having a distributed team. (Our CTO Andrew wrote an excellent piece on whether fully distributed teams are viable.) Two-thirds of our team is distributed across the US, Canada and Europe. However, we [...]

  20. Why I Decided to Spend More Time Working From Home » Breaking News | Latest News Headlines | Top Stories Says:

    [...] pride ourselves on having a distributed team. (Our CTO Andrew wrote an excellent piece on whether fully distributed teams are viable.) Two-thirds of our team is distributed across the U.S., Canada, and Europe. However, we [...]

  21. Scott Berkun Says:

    Good post and comments.

    An interesting angle on the question is how viable it is for companies to shift between different models.

    Some of the best examples, Automattic and Github, started fully distributed, and it makes sense that as they’ve done so well they’ve grown with those models. But I know of few established companies that have tried to make the switch.

    Many large companies like Cisco, IBM, Accenture, etc. all a lot of remote work but on a daily basis – where people work from home a day or two a week. The gap in the outline you have is there’s no easy place to categorize these companies, even though they probably represent the largest numbers of remote workers in the world.

  22. Devdas Bhagat Says:

    IBM and Cisco and the ilk are fully distributed. Being in a different physical location or a different timezone is about the same in terms of communication overhead.

    The switch needed for the companies to flip is between synchronous and asynchronous modes of communication. Once you start communicating in a form suitable for asynchronous communication, distribution becomes a lot easier. You want something with extremely high SNR, rather than high bandwidth. Hence text over voice/video. Then you sync up every few months to bring up areas of focus (kernel development conferences, for example).

    This is the same technical insight as RPC vs message passing over sockets. For the tech types, CORBA vs Erlang.

  23. pixelmonkey Says:

    @Scott Yes, I’ve pondered this, as well.

    I actually used to work at Morgan Stanley, which was navigating a pretty dramatic shift from horizontally scaled to fully distributed (at least, for certain IT teams, including mine at the time).

    We had team members in New York, Montreal, and India. The New York – Montreal team was the bulk of the engineering staff, but there were serious issues with out-of-band communication, both within the Montreal office and within the New York office. Even I was guilty of this, not knowing much about the dynamics of distributed teams at the time. Of course, with the India team, there were serious problems with navigating the timezone delta. In my current startup, I try to solve both problems by forcing 100% of the team onto web-preferred communication, by centering the team roughly around EST time (with “core hours” of 10am-3pm ET), by enabling full transparency, and by having regular team retreats.

    It was actually at Morgan Stanley that I learned the importance of asynchronous communication. We had an always-on chat room with good etiquette re: backlogged messages and status messages. We also had a strong culture of technical discussions via e-mail and using code prototypes. So I’ve definitely seen large companies dabble with moderate success. Just like anything else at BigCo’s, though, it takes a lot more to drive organizational change than it does at nimble companies that were only recently founded.

    Re: “work-from-home flexible arrangements”, I really see that as something else altogether. Few vertically-scaled or horizontally-scaled offices are willing to adopt the “distributed team culture” merely to enable people to occasionally take a work-from-home day. This is perhaps a good thing — doing so would probably alienate a portion of the workforce who sees no need for work-from-home flexibility at all (or views it as nothing more than an occasional “perk”, another side of the “flexible hours” coin).

    I think it’s instructive to view “face-to-face preferred w/ flexible work-from-home arrangements” and “digital preferred w/ no requirement for office presence” as fundamentally different cultures.

    @Devdas, I think the analogy to kernel development conferences is a great point.

  24. Lesuko Says:

    We are a startup with a fully distributed team- no head office. We are struggling with communication and software tools for scrum, kanban, scrumban- trying to figure out what works best for software development.

    Does anyone have any recommendations- real time updates is key as our calls are on skype/ghangout.

    Thanks!

  25. Lesuko Says:

    I’m curious to learn what software tools people are using to manage their distributed teams. We haven’t found a good solution for real time development management- scrum/kanban/scrumban.

    Any recommendations or experiences you can share- what works, what didn’t work?

    Thanks!

  26. » Groovy, the Python of Java Says:

    […] Also, do you want to use the "Python of Python" in your everyday work? (That is: Python.) Well, Parse.ly is hiring a Senior Software Engineer, ideally in Eastern or Central Time Zone. This is a remote position for our fully distributed team. […]

  27. » Build a web app fast: Python, HTML & JavaScript resources Says:

    […] Do you want to do modern Python web development on a daily basis, working on some of the most interesting problems at the intersection of large-scale data analysis and information visualization? Check out Parse.ly — we’re hiring! Engineers work ideally in Eastern or Central Time Zone, as this is a remote position for our fully distributed team. […]

  28. Giving Thanks for Parse.ly Team Retreats by Parse.ly Says:

    […] usually distributed Parse.ly team most recently converged offsite to Charleston, South Carolina. These retreats allow us to re-align […]

  29. » Joel Spolsky’s business operating system Says:

    […] new hires. And though he only came around recently on the importance and power of remote work, the fully distributed team we built here uses the same principles, the same “operating system”, that he […]

Leave a Reply