Real Advice on Distributed Teams - Part 1

Real Advice for Distributed Projects #

What makes this advice “real”? #

A lot has been written about how best to run a distributed software development project, and a lot continues to be written, because it’s hard, and people keep getting it wrong. Building software is one of the hardest things that we do. As anyone who’s ever had a conference call knows, communication between multiple people that aren’t around a table is also really hard. So, take one of the hardest things that people do and make it even harder by introducing cultural barriers, time zone issues, and time-delayed audio where half the time that people are talking, it’s on mute? A perfect recipe for disaster.

Distributed projects aren’t going away, and it’s part of the job to be able to run them effectively. I feel strongly that the nature of distributed projects is different from those that are done by co-located team, and that embracing this difference is key to being successful. The advice in this article is not something that I’ve found elsewhere, and may come across as counter-intuitive, but it’s battle-proven, and not doing it this way is also pretty battle-proven, in that it’s failed over and over again.

One key element I want to be clear about here is that I am explicitly not discussing the type of “distributed” project where the primary motivator for distribution is cost. They may be substantial cost-savings associated with having a distributed team, of course. However, this article is based upon the premise that all of your team members are trusted, respected collaborators, regardless of what location they are located in. If you want an article about how to effectively build software with a mediocre team of the cheapest people that you can find – go somewhere else. Preferably as far away from the software industry as you can. Managing a team with a varied array of opinions and experiences can be unwieldy, to be sure, but a diversity of opinions and a free exchange of ideas between people aligned to a common goal produces better software every time.

Eliminate “gestures of collaboration” #

One of the themes of this blog is reality. All too often, I see teams that believe that because they have a meeting, or a video conference, or an email list, or an end-of-day email, that they are collaborating. This is false – collaboration is an activity all of its own. Having a conference call is emphatically not collaboration. You can collaborate via a conference call, sure! You can also talk past each other on a conference call, misunderstand each other on a conference call, ignore each other on the conference call, or just generally be annoyed with the person at the other end of the crackly conference line.

Eliminating gestures of collaboration is about being honest about what’s effective and what’s not, and ruthlessly eliminating the latter. This will feel wrong – we’re all taught that the three Cs of project management are “Communicate, communicate, communicate”; how can we eliminate communication? The reality, though, is that by eliminating these gestures, you’re actually creating an environment where there’s more communication, not less.

At a rescue project, one of the first things I changed about how the team worked was to eliminate the daily distributed stand-up. This raised a few eyebrows at first, especially with the off-shore team. They didn’t see what I saw, though, which was the emotion that having that stand-up first thing in the morning created. Because it was every day and so short, technical issues couldn’t be easily resolved in the time. Gathering around the conference call made it hard to hear, and starting the day off with such a frustrating call made the team resentful of their distributed teams, and less likely to view them as true collaborators (since it was so hard to communicate with them). It also surprisingly made it harder to convince people to use written communication – it was a common pattern for the team to say “oh, I won’t put that in an email, I’ll just talk about in stand-up”, and then have that person not be able to communicate in the stand-up or for the confusion to result in an email being sent anyway, only 24 hours later from when the problem was originally identified.

Eliminating this useless meeting made the time we did make to collaborate better in every way – we looked forward to the chance to talk to our colleagues instead of resenting it, and it made the time that we had together both more productive and more fun.