Why Distributed Teams are Less Effective (2010)

I disagree, and I've pitched companies to Suster and other VCs who've held this viewpoint. It's unfortunately very widely held by VCs, and in some cases is rather extreme, with certains VCs demanding you not only be non-distributed, but that you be non-distributed in specific places.

I become a believer in distributed teams from my experiences working on open source projects. In those cases, it's not possible to coalesce the team physically except on rare occasions. They seem to work just fine.

Anecdotally, the best teams I've ever worked on were distributed, and I will continue to start companies with distributed teams and work with companies as a distributed team member.

I will say that I think getting everyone together on a regular basis is good and useful. It makes the social dynamics much better if everyone can be reminded that their coworkers are actual people every 6-12 weeks.

Hiring for distributed teams is both easier and harder. On the one hand, you can choose anyone, anywhere, and many people in non-name brand locations are hugely excited by the idea of working on small teams on cool projects. The downside is that it takes more discipline to be effective on a distributed team, and you must have vastly superior communication skills than the norm. Lots of perfectly smart and capable people can't or don't enjoy working that way. You often don't know until a few weeks in.

I have no qualms with what Suster writes here. At the same time, I've encountered a number of very powerful counterexamples that gives me pause.

- 37signals: Renowned for its strong company culture, 37signals talks often about how having a distributed team is a competitive advantage because it allows them to hire the very best fit (excellence at work and culture fit) without regard to location.

- Singly: Up-and-coming post-Series A company. I've gotten to know them because they use my product iDoneThis (http://idonethis.com) to replace their daily standup. Neither their CTO nor their VP of Engineering works on site in SF and they are an API company! Yet they have an extremely strong engineering culture, and much of it revolves around a no nonsense approach to work and zero tolerance of meetings, and that's facilitated by being distributed.

- Ravelry: They've not only built a tight-knit team that's distributed, they've built a ravenous community and fan base with their product (2M+ users). They've said that because they're distributed, that makes them work extra hard on communication and making work fun.

> In a world where 90% of communications is non-verbal imagine what is lost on conference calls.

On the flipside, a significant percentage of people who work in the tech sector seem to be introverted, or sometimes even autistic (although it is hard to draw a clear distinction between the two). Many of them don't really "get" non-verbal communication anyway, even in a face-to-face setting. Even if they do, non-verbal communication tends to be much less efficient for these people. As a result, I doubt that relying exclusively on verbal communication results in such a large loss as the author describes.

> The culture is forged through office parties, poker, paintball or film nights. And slowly, over the years, those crazy stories about Danny passed out in the company bathroom after the Summer party get replaced by weddings, births and family picnics. We become more than dispassionate colleagues – we’ve been in the trenches together and survived.

And this is exactly the kind of office culture that introverted and/or autistic techies tend to hate, or even positively despise. Office parties? Boring. Danny's bathroom episode? Idle chitchat. Paintball? No, I'd rather go home early and play my favorite FPS game. And I thought I'd be able to avoid those stupid corporate events if I worked for a lean startup! No thanks.

In short, I think that the author is approaching the topic of distributed teams from a rather biased point of view, namely, the viewpoint of a corporate executive who is proud of his "social skillz" and expects everyone else to enjoy the pointless parties he throws.

This is from 2010. Let me offer one counterpoint to this, from my own experience:

Hiring is way easier when you allow your team to be distributed.

I need a developer -- I go on oDesk.com, and together with one of my developers who will be his future partner, we go through profiles and "hunt" for a good fit. Once you remove the geographic restriction, you will find SO much talent. And for the payroll and staffing issues we literally pay 10% to odesk. Compare that with how much staffing agencies would charge on top of the salary (I know, I've been placed many times as a consultant where the agency would take 50-90% on top of the hourly salary I wound up being paid).

Remote workers can work part time. They don't have to commute 2 hours a day. Remote workers are more OK with having odesk take screenshots of their desktop so I know they are working for the time I paid them. Remote workers often have lower cost of living and a startup can't really afford to pay local developers a competitive salary unless they are well funded.

I think Linux and other open source projects show just how effective distributed development can be. Github and other tools are being used by local teams, blurring the line between local and distributed. And also, I've found that the more asynchronous communication we have, the more disciplined we are. For example, if you have an issue, put it in the project tracker instead of talking about it.

Basically, I think that for something as virtual as software development, being distributed can be a real plus, and people can really be more free. This has also become the case with music production and voiceovers, as a friend of mine who owns a major sound studio recently told me.

I can think of examples where it works well to be distributed and ones where it doesn't.

PostgreSQL is a very distributed development group. There are small clusters of developers in many places throughout the world, but even then generally don't gather more than once per month. Sure, there are plenty of user groups and conferences, but it's not an every-week kind of thing.

And the postgres project really delivers. A strong release once per year with a variety of features; balanced between new innovations, performance, robustness, manageability, etc. It's hard to beat that.

I think the worst situation to be in is where you have very strong clusters and a few satellite developers or groups of developers. What happens is that the satellite developers are simply out of the loop, and don't even know what decisions are being made.

Either delegate components very clearly between remote groups, or go all distributed, or completely local.

It sounds to me like your experience in a remote team was sub-par, but that doesn't make remote teams bad... just that one.

Culture, chatter, gossip, staying up all night to get a release done... all of this can be done with remote teams if you have the right tools and you build it into your culture.

Of course there are pros and cons for remote teams, but my experience is that the pros far outweigh the cons.

I work in a team that has us spread across 4 countries (Australia, Poland, UK and Brazil) and very clashing time zones. It works amazingly well.

We have much more talented people working in our team than we could have gotten if we restricted our search to the local area only. I am positive having better staff far outweighs any cons of being remote.

My recommendation to anyone but my competitors would be to seriously consider a remote team.

Just like with anything else, the execution is what it all comes down to. Distributed teams are easy to mess up and hard to get right. If you're betting a sizeable chunk of money on some company and you are incapable of evaluating whether or not they have a distributed team that functions well then you should probably stay clear of it.

I've seen spectacular results and spectacular failures in distributed teams, it all depended on management, selection and processes in place to keep things moving. Mess up any of those and you won't be able to run a distributed team, but then again you probably won't be able to run a local one either.

When comparing two otherwise identical teams, the distributed one is probably the less effective. That's not the situation most companies are facing. A company looking to hire me that was competitive on most other fronts and stood out by letting me work remotely from Thailand would instantly jump to the top of my list. Many people for whom your company would not even be on the radar, let alone in the running, are suddenly realistic hires.

That article felt like him saying "I don't like it" 10 times

I've always believed that working remote is the future. The next step in the evolution of how we as humans do work. It's still early and the next decade will bring improved tools.

A lot of the foundation of Agile is improving communication. Communication works better face to face. Whether there are mitigating factors such as not being able to get really awesome people to participate is another question, but I've no doubt that my #1 problem with developers is how to facilitate their communication.

You can only get so many people to communicate well on a team anyway. 10 at most and you're into the Mythical Man Month. That being the case, you find the 10 best people who have good chemistry together, that's job #1. Job #2 is to colocate them if you can, but let's say it is a less significant digit than Job #1.

BTW, developers also need to be able to concentrate. That's another thing that fights with the communication imperative. I'm all in favor of at least 2 of the 5 week days being work at home days.

A big reason distributed teams fail is because companies don't understand how to properly organize and nurture them.

The right group of distributed teammates on the right product and project is fucking amazing. Its all about recruiting and constant communication with video. Seeings someone's face makes all the difference.

It's a shame that this article focussed on startups, because the problems outlined are endemic to any endeavour where a large amount of ideas and knowledge have to be exchanged between individuals with as little friction as is humanly possible.

In my own current case, that situation is a project moving from requirements capture to functional specification, where a huge amount of this sort of interchange has to happen, but is being prevented due to geographical separation of client business analysts and the technical design people. The remote collaboration tools have not been written that can even begin to substitute for a quick question over the cube wall, or an insight gained / misunderstanding overturned though a serendipitous ad-hoc conversation.

Sadly there is a pervasive management myth that office space to colocate teams is too expensive, and can be replaced by weekly meetings, email, communicator, exchanged documents and spreadsheets and the like. Wrong.

I've been working on distributed teams for over 2 years now. I very much prefer it and I find that personally I am more productive. I've also started a business with a parter who is remote. In 2 years we've only met twice. It helps that we are in the same timezone but any level of stagnation has not been a result of our location. When we eventually hire developers I would like to hire local so I can have in person social meetings with my team, but I would not want to have an office as I feel the trust and flexibility of working from your own environment can have a massive impact on a mature professionals creative output.

(lightly edited copy of my usual plea for evidence on this topic ;-)

Pretty much all the evidence (rather than anecdote) I can find shows that co-located teams in a single team room environment are the most productive - all other things being equal.

(And I'm saying this as somebody who spends a lot of their time working from home, and talking to other folk over Skype, etc. There are reasons for telecommuting - personal preference, getting access to people who cannot co-locate, etc. But for business productivity I'm not seeing much, if any, evidence).

Please not that I am not saying:

* That working alone in an office is bad / will cause projects to fail

* Telecommuting is bad (I do it - I like it)

* Telecommuting projects will fail (D'oh - of course not)

* You shouldn't telecommute (of course you should if you want to - but bear in mind that the business may have good reasons to disagree with that decision)

* That telecommuting makes you individually less productive (I'm personally unsure about this. I feel more productive when working by myself, but I know that personal perceptions of productivity can be false. Measuring personal vs team/company productivity becomes hard in anything less than the short term)

* That co-location is always the best solution (it isn't - other factors like team location and skills come into play)

What I am saying is that there is a lot of research showing that co-located teams in team-room like settings are much more productive. This runs counter to many developers preferences (mine too ;-) so it tends to get ignored.

So much more productive that solutions like 'Let's fly everybody to the same place and pay their room and board for a month' can be cost effective.

Here are some references to the research (If anybody has any research that contradicts this I'd love to hear about it. Especially if it talks about actual measured metrics of productivity - rather that self-reported 'I felt just as productive at home' ones.)

----

"It doesn't take much distance before a team feels the negative effects of distribution - the effectiveness of collaboration degrades rapidly with physical distance. People located closer in a building are more likely to collaborate (Kraut, Egido & Galegher 1990). Even at short distances, 3 feet vs. 20 feet, there is an effect (Sensenig & Reed 1972). A distance of 100 feet may be no better than several miles (Allen 1977). A field study of radically collocated software development teams,[...], showed significantly higher productivity and satisfaction than industry benchmarks and past projects within the firm (Teasley et al., 2002). Another field study compared interruptions in paired, radically-collocated and traditional, cube-dwelling software development teams, and found that in the former interruptions were greater in number but shorter in duration and more on-task (Chong and Siino 2006). Close proximity improves productivity in all cases." -- http://conway.isri.cmu.edu/~jdh/VRC-2008

"Based on the empirical evidence, we have constructed a model of how remote communication and knowledge management, cultural diversity and time differences negatively impact requirements gathering, negotiations and specifications. Findings reveal that aspects such as a lack of a common understanding of requirements, together with a reduced awareness of a working local context, a trust level and an ability to share work artefacts significantly challenge the effective collaboration of remote stakeholders in negotiating a set of requirements that satisfies geographically distributed customers" -- http://link.springer.com/article/10.1007%2Fs00766-003-0173-1

"Our results show that, compared to same-site work, cross-site work takes much longer and requires more people for work of equal size and complexity. We also report a strong relationship between delay in cross-site work and the degree to which remote colleagues are perceived to help out when workloads are heavy" -- http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?reload=true&#...

"Our findings reveal that: software developers have different types of coordination needs; coordination across sites is more challenging than within a site; team knowledge helps members coordinate, but more so when they are separated by geographic distance; and the effect of different types of team knowledge on coordination effectiveness differs between co-located and geographically dispersed collaborators." -- http://kraut.hciresearch.org/sites/kraut.hciresearch.org/fil...

"One key finding is that distributed work items appear to take about two and one-half times as long to complete as similar items where all the work is colocated" -- http://www.computer.org/portal/web/csdl/doi?doc=doi/10.1109/...

"Our study of six teams that experienced radical collocation showed that in this setting they produced remarkable productivity improvements. Although the teammates were not looking forward to working in close quarters, over time they realized the benefits of having people at hand, both for coordination, problem solving and learning.Teams in these warrooms showed a doubling of productivity" -- http://possibility.com/Misc/p339-teasley.pdf

"Despite the positive impact of emerging communication technologies on scientific research, our results provide striking evidence for the role of physical proximity as a predictor of the impact of collaborations." -- http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjourna...

"Groups with high common ground and loosely coupled work, with readiness both for collaboration and collaboration technology, have a chance at succeeding with remote work. Deviations from each of these create strain on the relationships among teammates and require changes in the work or processes of collaboration to succeed. Often they do not succeed because distance still matters" -- http://dl.acm.org/citation.cfm?id=1463019

One important property of face-to-face meetings compared to Skype chats that looks like nothing has mentioned before is the sense of responsibility.

It's far easier to turn off Skype for a day or two and give some crap excuses for whatever went wrong rather than look into persons eyes and talk about it.

Obviously it's not a perfect scenario and we expect those things not to happen but well, the world is not perfect and they do happen.

I've updated the title to indicate that it was written 3 years ago. How have things changed?

> magic

Sounds as rational as the ancient aliens guy.