How to successfully work in a distributed team

Working in a distributed team is becoming more and more popular. With the power of Internet, today we can easily work together without worrying about physically travelling to work. It saves time, fuel, and personal energy. Can anyone imagine anything better?

But, all the convenience comes with a price. Co-located workers have the advantage of direct communication, which is often underestimated. When you have all of your coworkers in a room, they will answer you immediately when you ask, “Is that document is ready?” or “Can our original design support these new requirement changes?”. When the team are distributed in many locations (and possibly many time zones), things are quite different. We must wait for our emails being answered, or the chat reply message, while the others are on their other tasks. We may get stuck and need help from another team member who are sleeping while we are at work. That’s not only irritating, but also become a real challenge for any distributed team want to push their productivity toward their maximum potential.

I have been in this position more than once. Some were school projects, some were start-ups with my friends, and some in my work elsewhere. Some of them failed desperately, the rest succeeded. What I learned from them is: the way we do things as a programmers have a big impact. And success is not only for the Project Manager – it’s something we programmers can be proud of – when we contributed in it.

There are three key principles to success: Communication, Trust, and Enthusiasm

Communication

Communication, communication, communication. I can’t stress this enough. Making sure everyone is on the same page is critically important, especially when you’re building a product a continuously changing product. In a fast-paced environment, a developer may take harmful shortcuts or forget important details if the rest of the team is not aware of their actions. Many times, I had to remind a team  member about a requirement he forgot, or explain the reason for our design the third time to the same person. It’s annoying, but it’s far better than letting developers make assumptions and cause irrepairable damage to the project.

Given that the team is potentially distributed all over the world, communication is harder but not impossible. All the team should sit together (via Skype or similar) to agree on a “communication plan”. In our case, we had two teams: client and server which works on different places with different time zones. we decided that everyday the server team would build a new version at 12:30 pm, then the client team would check to see if there’s any problems. Then, at 4pm when everyone in the server team went home, the client team will begin their work and give feedback to server team by the next day. The check at noon guarantee s that the build is not broken so badly that the client team can’t fix it.

One of the other ways to enhance communication is building a “responsive” culture. “Respond early – respond often” – that’s our motto. When you get an email and don’t have the chance to read it thoroughly, just mark them as “to read” and send a message that you’re doing on another task and will look at their problem as soon as you’ve time. That will help the people on the other end switch to another task in the meantime. (*)

Trust 

Believe me, trust is very important. If people think you are not doing your best, they won’t either. Trust others and they will trust you. Do your work so that your team can trust you, and they will be much more inclined do their work. Be as transparent as possible. Make it clear what you’re working on. All of those things are easy to say, but it requires attention and care to get them done.

Once, I joined in a start-up where everyone was eager about what we were going to build. But we were located in different countries, and also had day jobs. Several weeks passed and we got our infrastructure setup ready. But then we got stuck in a vicious cycle: late response time, endless discussion about what the project will do, and soon everyone was tired of meeting without seeing anything done. The project got cancelled.

The lesson to be learned here is: we wanted to build something, but we failed to show each other that we wanted to put forth our best effort. As a result, any trust could have been cultivated was destroyed.

Enthusiasm!

Share your vision. If you don’t love what you’re doing, you are killing the morale of others. We all love working in a enthusiastic environment, so just make it :-).

Being passionate about the project’s goal is a sure path to victory: I have noticed that when myself and other team members have a positive attitude, all team work better with less conflict and miscommunication. We even feel much better.

Enthusiasm is infectious. Coming up with new ideas (sometimes stupid) is a way to show passion. That means you don’t only do your work, but you do it with heart. If you think of any cool idea, tell others right away. Don’t be lazy and say: “I will catch up with him tomorrow” because that tomorrow will never come. Tomorrow, other tasks will pull you away along with your best ideas. If you think the idea is not mature enough to present, put it off somewhere you will absolutely look at when you have free time. I feel that a sticker right beside the monitor is not a bad idea.

Last but not least, keep a close eye on what’s going on. Revise early, revise often. No matter what you’re doing, which role you’re playing, you should be responsible about project’s success. Tell the people in charge about any risk early.

In closing, a programmer is not simply a technical worker. That’s not the spirit – any laborer can learn their work for once and apply it the same way for many years, but that’s not us. We live and breath in the ever-changing technology environment, and we come here because we love it. Working in a distributed team is not only a difficulty, but also a challenge that many of us seek to overcome.

(*) Manage your time wisely. Time management: Answer too many requests and you will not get anything done. Don’t answer then they will wonder why you don’t respond. They can’t see you are busy. Balancing the workload is an art. But for starters: Speak the truth and try to be as simple and as clear as possible.

(**) The images used in this post are credited for Stock Exchange