Literature Review: Distributed Teams

Introduction

Con­text: Oliver Habryka com­mis­sioned me to study and sum­ma­rize the liter­a­ture on dis­tributed teams, with the goal of im­prov­ing al­tru­is­tic or­ga­ni­za­tions. We wanted this to be rigor­ous as pos­si­ble; un­for­tu­nately the rigor ceiling was low, for rea­sons dis­cussed be­low. To fill in the gaps and es­pe­cially to cre­ate a unified model in­stead of a se­ries of iso­lated facts, I re­lied heav­ily on my own ex­pe­rience on a va­ri­ety of team types (the fa­vorite of which was an en­tirely re­mote com­pany). This doc­u­ment con­sists of five parts:

  • Summary

  • A se­ries of spe­cific ques­tions Oliver asked, with sup­port­ing points and cita­tions. My full, di­s­or­ga­nized notes will be pub­lished as a com­ment.

My over­all model of worker pro­duc­tivity is as fol­lows:

High­lights and em­bel­lish­ments:

  • Distri­bu­tion de­creases band­width and trust (al­though you can make up for a sur­pris­ing amount of this with well timed vis­its).

  • Semi-dis­tributed teams are worse than fully re­mote or fully co-lo­cated teams on ba­si­cally ev­ery met­ric. The poli­tics are worse be­cause ge­og­ra­phy be­comes a fault line for fac­tions, and in­for­ma­tion is lost be­cause peo­ple in­cor­rectly count on prox­im­ity to dis­tribute in­for­ma­tion.

  • You can get co-lo­ca­tion benefits for about as many peo­ple as you can fit in a hal­lway: af­ter that you’re pay­ing the costs of co-lo­ca­tion while benefits de­crease.

  • No pa­per even at­tempted to ex­am­ine the in­crease in worker qual­ity/​fit you can get from fully re­mote teams.

Sources of difficulty:

  • Busi­ness sci­ence re­search is gen­er­ally crap.

  • Much of the re­search was quite old, and I ex­pect tech­nol­ogy to im­prove re­sults from dis­tri­bu­tion ev­ery year.

  • Numer­i­cal rigor trades off against nu­ance. This was es­pe­cially detri­men­tal when it comes to form­ing a model of how co-lo­ca­tion af­fects poli­tics, where much that hap­pens is sub­tle and un­seen. The most largest stud­ies are gen­er­ally sur­vey data, which can only use crude cor­re­la­tions. The most in­ter­est­ing stud­ies in­volved re­searchers read­ing all of a team’s cor­re­spon­dence over months and con­duct­ing in-depth in­ter­views, which can only be done for a hand­ful of teams per pa­per.

How does dis­tri­bu­tion af­fect in­for­ma­tion flow?

“Co-lo­ca­tion” can mean two things: ac­tu­ally work­ing to­gether side by side on the same task, or work­ing in par­allel on differ­ent tasks near each other. The former has an in­for­ma­tion band­width that tech­nol­ogy can­not yet du­pli­cate. The lat­ter can lead to serendipi­tous in­for­ma­tion shar­ing, but also im­poses costs in the form of noise pol­lu­tion and si­phon­ing brain power for so­cial re­la­tions.

Distributed teams re­quire in­for­ma­tion shar­ing pro­cesses to re­place the serendipi­tous in­for­ma­tion shar­ing. Th­ese pro­cesses are less likely to be de­vel­oped in teams with mul­ti­ple lo­ca­tions (as op­posed to en­tirely re­mote). Worst of all is be­ing a lone re­mote worker on a co-lo­cated team; you will miss too much in­for­ma­tion and it’s fea­si­ble only oc­ca­sion­ally, de­spite the fact that mea­sured pro­duc­tivity tends to rise when peo­ple work from home.

I think rely­ing on co-lo­ca­tion over pro­cesses for in­for­ma­tion shar­ing is similar to rely­ing on hu­man mem­ory over writ­ing things down: much cheaper un­til it hits a sharp cliff. Em­piri­cally that cliff is about 30 me­ters, or one hal­lway. After that, pro­cess shines.

List of iso­lated facts, with at­tri­bu­tion:

  • “The mu­tual knowl­edge prob­lem” (Cram­ton 2015):

    • As­sump­tion knowl­edge is shared when it is not, in­clud­ing:

      • typ­i­cal mind­ing.

      • Not re­al­iz­ing how big a re­quest is (e.g. “why don’t you just walk down the hall to check?”, not re­al­iz­ing the lab with the data is 3 hours away. And the re­cip­i­ent of the re­quest not know­ing the asker does not know that, and so as­sumes the asker does not value their time).

    • Count­ing on in­for­mal in­for­ma­tion dis­tri­bu­tion mechanisms that don’t dis­tribute evenly

    • Silence can be mean many things and is of­ten mis­in­ter­preted. E.g. ac­quies­cence, de­liber­ate snub, mes­sage never re­ceived.

  • Lack of easy com­mon lan­guage can be an in­cred­ible stres­sor and ham­per in­for­ma­tion flow (Cram­ton 2015).

  • Peo­ple com­monly cite over­hear­ing hal­lway con­ver­sa­tion as a benefit of co-lo­ca­tion. My ex­pe­rience is that Slack is su­pe­rior for pro­duc­ing this be­cause it can be done asyn­chronously, but there’s rea­son to be­lieve I’m an out­lier.

  • Serendipi­tous dis­cov­ery and col­lab­o­ra­tion falls off by the time you reach 30 me­ters (chap­ter 5), or once you’re off the same hal­lway (chap­ter 6)

  • Be­ing near ex­ec­u­tives, pro­ject de­ci­sion mak­ers, sources of in­for­ma­tion (e.g. cus­tomers), or sim­ply more of your peers gets you more in­for­ma­tion (Hinds, Retelny, and Cram­ton 2015)

How does Distri­bu­tion In­ter­act with Con­flict?

Distri­bu­tion in­creases con­flict and re­duces trust in a va­ri­ety of ways.

  • Distri­bu­tion doesn’t lead to fac­tions in and of it­self, but can in the pres­ence of other fac­tors cor­re­lated with location

    • e.g. if the en­g­ineer­ing team is in SF and the fi­nance team in NY, that’s two cor­re­lated traits for fault lines to form around. Con­versely, hav­ing com­mon traits across lo­ca­tions (e.g. work role, be­ing par­ents of young chil­dren)] fights fac­tion­al­iza­tion (Cram­ton and Hinds 2005).

    • Lan­guage is an es­pe­cially likely fault line.

  • Levels of trust and pos­i­tive af­fect are gen­er­ally lower among dis­tributed teams (Morten­son and Neeley 2012) and even co-lo­cated peo­ple who work from home fre­quently enough (Ga­jen­dra and Har­ri­son 2007).

  • Con­flict is gen­er­ally higher in dis­tributed teams (O’Leary and Morten­son 2009, Mart­ins, Gil­son, and May­nard 2004)

  • It’s eas­ier for con­flict to re­sult in with­drawal among work­ers who aren’t co-lo­cated, am­plify­ing the costs and mak­ing prob­lem solv­ing harder.

  • Peo­ple are more likely to com­mit the fun­da­men­tal at­tri­bu­tion er­ror against re­mote team­mates (Wil­son et al 2008).

  • Differ­ent so­cial norms or lack of in­for­ma­tion about col­leagues lead to mis­in­ter­pre­ta­tion of be­hav­ior (Cram­ton 2016) e.g.,

    • you don’t re­al­ize your re­mote co-worker never smiles at any­one and so as­sume he hates you per­son­ally.

    • differ­ent ideas of the mean­ing of words like “yes” or “dead­line”.

  • From anal­ogy to biol­ogy I pre­dict con­flict is most likely to arise when two teams are rel­a­tively evenly matched in terms of power/​ re­sources and when spoils are win­ner take all.

  • Most site:site con­flict is ul­ti­mately driven by de­sire for ac­cess to growth op­por­tu­ni­ties (Hinds, Retelny, and Cram­ton 2015). It’s not clear to me this would go away if ev­ery­one is co-lo­cated- it’s eas­ier to view a dis­tant col­league as a threat than a close one, but if the num­ber of op­por­tu­ni­ties is the same, mov­ing peo­ple closer doesn’t make them not threats.

  • Note that con­flict is not always bad- it can mean peo­ple are hon­ing their ideas against oth­ers’. How­ever the liter­a­ture on vir­tual teams is im­plic­itly talk­ing about re­la­tion­ship con­flict, which tends to be a pure nega­tive.

When are re­mote teams prefer­able?

  • You need more peo­ple than can fit in a 30m ra­dius cir­cle (chap­ter 5), or a sin­gle hal­lway. (chap­ter 6).

  • Mul­ti­ple crit­i­cal peo­ple can’t be co-lo­cated, e.g.,

    • Wave’s com­pli­ance officer wouldn’t leave semi-ru­ral Penn­syl­va­nia, and there was no way to get a good team as­sem­bled there.

    • Lob­by­ing must be based in Wash­ing­ton, man­u­fac­tur­ing must be based some­where cheaper.

    • Cus­tomers are lo­cated in mul­ti­ple lo­ca­tions, such that you can co-lo­cate with your team mem­bers or cus­tomers, but not both.

  • If you must have some team mem­bers not co-lo­cated, bet­ter to be en­tirely re­mote than leave them iso­lated. If most of the team is co-lo­cated, they will not do the things nec­es­sary to keep re­mote in­di­vi­d­u­als in the loop.

  • There is a clear shared goal

  • The team will be work­ing to­gether for a long time and knows it (Alge, Wei­thoff, and Klein 2003)

  • Tasks are sep­a­rable and in­de­pen­dent.

  • You can filter for peo­ple who are good at re­mote work (in­de­pen­dent, good at learn­ing from writ­ten work).

  • The work is easy to eval­u­ate based on out­come or pro­duces highly visi­ble ar­ti­facts.

  • The work or worker benefits from be­ing done in­ter­mit­tently, or doesn’t lend it­self to 8-hours-and-done, e.g.,

    • Wave’s anti-fraud officer worked when the sus­pected fraud was hap­pen­ing.

    • Eng­ineer on call shifts.

  • You need to be pro­cess- or doc­u­men­ta­tion-heavy for other rea­sons, e.g. le­gal, or find it rel­a­tively cheap to be so (chap­ter 2).

  • You want to re­duce vari­a­tion in how much peo­ple con­tribute (=get shy peo­ple to talk more) (Mart­ins, Gil­son, and May­nard 2008).

  • Your work benefits from long OODA loops.

  • You an­ti­ci­pate low turnover (chap­ter 2).

How to Miti­gate the Costs of Distribution

  • Site vis­its and re­treats, es­pe­cially early in the pro­cess and at crit­i­cal de­ci­sion points. I don’t trust the pa­pers quan­ti­ta­tively, but some re­port site vis­its do­ing as good a job at trust- and rap­port-build­ing as co-lo­ca­tion, so it’s prob­a­bly at least that or­der of mag­ni­tude (see Hinds and Cram­ton 2014 for a long list of stud­ies show­ing good re­sults from site vis­its).

    • Site vis­its should in­clude so­cial ac­tivi­ties and meals, not just work. Hav­ing some­one visit and not in­te­grat­ing them so­cially is worse than no visit at all.

    • Site vis­its are more helpful than re­treats be­cause they give the vis­i­tor more con­text about their cowork­ers (chap­ter 2). This prob­a­bly ap­plies more strongly in in­dus­trial set­tings.

  • Use voice or video when need for band­width is higher (chap­ter 2).

    • Although high-band­width vir­tual com­mu­ni­ca­tion may make it eas­ier to lie or mis­lead than ei­ther in per­son or low-band­width vir­tual com­mu­ni­ca­tion (Håkon­s­son et al 2016).

  • Make peo­ple very ac­cessible, e.g.,

    • Wave asked that all em­ploy­ees leave skype on au­toan­swer while work­ing, to recre­ate walk­ing to some­one’s desk and tap­ping them on the shoulder.

    • Put con­tact in­for­ma­tion in an ac­cessible wiki or on Slack, in­stead of mak­ing peo­ple ask for it.

  • Lightweight chan­nels for build­ing rap­port, e.g., CEA’s com­pli­ments Slack chan­nel, Wave’s ku­dos sec­tion in weekly meet­ing min­utes (per­sonal ob­ser­va­tion).

  • Build over-com­mu­ni­ca­tion into the pro­cess.

    • In par­tic­u­lar, don’t let silence carry in­for­ma­tion. Silence can be in­ter­preted a mil­lion differ­ent ways (Cram­ton 2001).

  • Things that are good all the time but be­come more crit­i­cal on re­mote teams

  • Have a com­mon chat tool (e.g., Slack or Dis­cord) and give work­ers ac­cess to as many chan­nels as you can, to recre­ate hal­lway serendipity (per­sonal ob­ser­va­tion).

  • Hire peo­ple like me

    • long OODA loop

    • good at learn­ing from writ­ten information

    • Good at work­ing work­ing asynchronously

    • Don’t re­quire so­cial stim­u­la­tion from work

  • Be fully re­mote, as op­posed to just a few peo­ple work­ing re­motely or mul­ti­ple co-lo­ca­tion sites.

  • If you have mul­ti­ple sites, lump­ing to­gether similar peo­ple or func­tions will lead to more fac­tions (Cram­ton and Hinds 2005). But co-lo­cat­ing peo­ple who need to work to­gether takes ad­van­tage of the higher band­width co-lo­ca­tion pro­vides..

  • Train work­ers in ac­tive listen­ing (chap­ter 4) and con­flict re­s­olu­tion. Microsoft uses the Cru­cial Con­ver­sa­tions class, and I found the book of the same name in­cred­ibly helpful.

Cram­ton 2016 was an ex­cel­lent sum­mary pa­per I re­fer to a lot in this write up. It’s not eas­ily available on-line, but the au­thor was kind enough to share a PDF with me that I can pass on. My full notes will be pub­lished as a com­ment on this post.