This is a very tricky topic. And you can beat the statement from the first sentence of post’s title easily by bringing up the well-renown examples of successful remote teams that have managed to create something really memorable (like GitHub, StackExchange, Mozilla or Basho - you know, the Riak guys) and … you will be absolutely right, but … you won’t know how much effort / determination / skill it requires until you try it on your own.
Why did these teams succeed and other do struggle then? What was the distinguisher?
Here’re my thoughts:
- The vision, the target, the goal - all shared
Words are just words - they do vanish when not written down. And even if they are written down, there’s always some kind of margin for interpretation - you can’t be 100% precise. And you can’t write down everything anyway.
To share the vision, you have to share it constantly: exchange opinions, brainstorm altogether, sometimes spend 1 or more hours at the whiteboard, etc. Or PoC a bit while pair-programming. The less continuous is vision-sharing, the more twisted the outcome will get. Unless people are really, *really* compatible (“are on the same wavelength”) - and this is VERY hard to achieve in corporate conditions (where you rarely have a freedom to shape your team from people you choose). - SPoC vs Peer-to-peer
SPoC AKA Single Point of Contact. I’ve seen few cases of distributed teams and usually their idea of working communication is communicating via “proxy” - assigned person whose job is to either pass info in both directions or (in the best case) route the information flow.
It’s a life-savior when you’re struggling to have ANY communication, because there’s absolutely no *chemistry* and people just don’t WANT to communicate, but when you consider a truly efficient work in distributed model, there’s no other option - the communication should be peer-to-peer. Otherwise you’ll get both the bottleneck and communication mismatches.
Sometimes such a setting is forced by a team setup -> teams in all locations have the same boss. In this case the thing is clear: he becomes the bottleneck, because all the communication is routed via his mailbox … You can easily imagine the rest. - Feedback
If you have remote team members and you don’t see them each day face-to-face, it doesn’t mean they are no human beings. Treating them as rows in Excel representing the tasks assigned will cause just trouble.
You have to remember about feedback: assigning the task and asking about completeness is NOT enough - people have to feel that their work is necessary and meaningful; they want to know how well did they perform, what went well and where’s “area to improve” (I hate the corporate lingo …). People work also to LEARN and how are they supposed to learn if there’s no feedback loop? - Being on the same page …
… is basically about the information flow. Each team member has to have an efficient way to keep others informed about: how he’s doing, what he’s working on, what are his issues & concerns, what’s his queue, etc. And it has to be clear for everyone, not just this particular person.
Other people should know WHY this team member is performing this task, because otherwise they won’t be sure that their consecutive plans won’t interfere.
That’s why I hate the projects where I have to ASK for information - PULL it out - BEG for it (because people assume that if they know, everyone know). And I hate projects without EXPLICIT area ownership (that affects the information as well) - it should be as clear as possible: who’s the person to ask about a given topic, who to consult the changes with, etc. Otherwise you’ll end up with motherless issues and user-stories implemented twice in parallel … (or worse). - Personality - some just won’t perform well …
Yeah, it’s a very important point, but it refers to people’s immanent characteristics, so I’ve decided to put it as last. Some just don’t fit the distributed model. Period. Why is that?
Distributed model means that people have to make some low-level operational decisions on their own - and yes, there are people who have a serious problem with that: both bosses who have to know EVERYTHING that’s taking place and their subordinates who are AFRAID of taking any responsibility for the decision that ain’t a simple work procedure that was performed before.
Yepp, some people just don’t want freedom, but there may also be some who’d like a bit too much freedom - it’s a general problem of having different aspirations, expectations, overall idea for work - if you work in an on-site team, this will get clear very, very fast. But from my experience, in distributed teams people learn from and about each other much slower, so there’s a delay.
If that’s so tricky, why do the Open Source projects do so well? Why is GitHub such a tremendous platform of distributed work? I’ve partially answered that above: because people match themselves on GitHub - smart people with similar knowledge, experience, interest (they contribute to the same project, righto?) decide to co-operate together and it’s THEIR decision.
They are not a pre-setup fixed team, they have little to none formal obligations, they pick their own rules of cooperation (that are usually much more flexible than what they are paid for when doing stuff for the living) - that’s pretty much unthinkable in corporate environment.
I’m not saying that working in distributed team in corporate conditions won’t work -> it will if you try strongly, but I’ve never met such team that wasn’t seriously impaired by its remote work model.
