Menu
Search
6 February 2010

6 tips for better collaboration among distributed teams

I recently realized that you don’t hear the word “globalization” all that often any more.  And I think it’s because globalization has moved from being a buzz word to a reality that is just part of the way we do business now, making it unnecessary to give it a fancy name.  As we become more comfortable with managing companies and projects across multiple locations, it’s easy to assume that geography does not matter any more.  And certainly the technology is there to support the around-the-clock collaboration that is so valuable when you work across time zones.  With cloud computing now a reality, and plenty of collaboration applications to choose from, working together has never been more efficient.

But I believe geography does still matter, and can result in decreased efficiency if not managed correctly.  The difficulty with working across multiple locations is not technology limitations, it’s human nature.  We tend to not trust what we can’t see, and that’s a problem if developers, product managers, and marketing folks sit in different offices and different time zones.  Once different work philosophies come out and you’re not able to talk about it, things can escalate out of control and make for really bad relationships if conversations happen intra-office but not inter-office.

This is not an insurmountable problem though.  Here are some things I believe can help distributed teams run smoothly.  Please also add your tips and ideas in the comments section!

1. Meet in person. Now.

People get along so much better once they’ve shared a meal together.  This is just a fact of human nature — we thrive on in-person social interaction (yes, even us introverts).  If you have distributed teams, it is imperative that they meet each other in person as soon as they start working together.

If a trip can be planned during a major software release — even better.  Nothing binds people together like the stress and exhilaration of getting a new product out in the wild.  Work hard, but also make time to go have dinner together.  You’ll find that after the initial trip, you’re able to understand each other a lot better over IM/phone calls.  I do think it’s worth getting teams together at least once a year, but even if it’s just once at the beginning of the relationship, it will go a long way to improve working relationships.  So go ahead, spend the money on that trip.  It’s worth it.

2. Be respectful of time zones.

10am in San Francisco is 8pm in Cape Town.  Not a great time to have a meeting… Now, it won’t always be possible to line up time zones, but at the very least it’s important to trade off meeting times.  Don’t make the guy in the smaller office always dial in at 9pm.  Alternate between meeting times to give everyone a chance to have a life outside of work.  Try to have all night-time calls on one or two nights, not spread out across the week.  It’s the little things that count.

3. Use the right technology.

When it comes to collaboration across teams, there is no excuse for inefficiency.  We use the following applications, and I can highly recommend all of them:

4. Keep it human

One of the most important aspects of team dynamics — and especially distributed team dynamics — is not losing your sense of humor.  Even when things get really stressful, keeping funny alive is essential because it reminds you that there are real people on the other side of the phone line/email address.  And, of course, it relieves stress.

I’ll give an example from a project I recently worked on with a developer team in our Cape Town office.  They built an environment for us to test the new product flows, and the screens can live either in a website or a pop-up window.  The normal (boring) thing to do would be to put a link there that says “Open in pop-up” when you want to test the pop-up dialog version of the flow.  Instead, the developers called the link “Pop that collar,” and the following image appeared when you hovered over the link:

Now, I don’t know if they did this to amuse me or themselves, or a little but of both.  But for some reason the joke doesn’t get tired for me, and it made working on the project so much more enjoyable.  Always bring the funny on your projects.

5. Trust each other

A recent article called Forced compliance is an obstruction to discipline really got me thinking about trust within teams — especially distributed teams.  I agree with the author on how damaging it can be if team members don’t trust each other:

A forced compliance style of governance is a lot about trying to compensate for lack of trust and admitting that we are more likely to fail than succeed. On the other hand, discipline is not pain, suffering and anguish. It’s only sadistic if you implement discipline for nothing.

We need to trust our team members — they are (usually) smart people who do the things they do for a reason.  It doesn’t mean you don’t have tough conversations when someone makes a mistake.  But making a mistake doesn’t make you untrustworthy — who among us would be able to meet that bar of excellence anyway?  Ask questions before you judge…

6. Don’t stop talking, especially when you disagree

The book Crucial Conversations: Tools for Talking When Stakes are High is a must-read book about having those tough conversations when things do go wrong, or when disagreements arise.  At the heart of the book are tools to ensure that everyone on the team gets listened to, and that no discussions happen behind peoples’ backs.  I much rather prefer an open dialogue about a product disagreement, than having to find out 3 months after launch that someone on the team didn’t like the way we did things.  As Product Managers, our role is to gather information from a variety of sources and channel that into the best possible ideas and products.  How can we do that if we don’t listen to everyone?

I often remind myself that as Product Managers, we are not judged by the number of times we ask for input, or how often we change direction based on new and relevant information.  We are judged by the success of the live Product.  So why would we not want to hear everyone’s ideas upfront so that we can launch the best possible experience?

So these are a few principles I try my best to apply when working with teams on different continents.  But I have hardly figured it out, and we’re basically making this up as we go along.  I’d love to know your thoughts and ideas: how can distributed teams work better together?