Five Things I’ve Learned about Working on Distributed Dev Teams

Working on a distributed development team is challenging. You need to deal with the normal difficulties of software development, as well as managing different time zones and the fact that you can’t just roll your chair over to someone and talk through a feature.

In this post, I’ll go over a few ways I’ve found to make working on a distributed team more productive.

1. Embrace Asynchronous Communication

Open communication is fundamental to all teams. It’s no less important when your team is distributed, but it’s definitely harder.

One of the biggest communication challenges of distributed teams is overcoming the schedule mismatch of working in different time zones. Rather than conversations happening on the scale of minutes, you could be waiting 24 hours for a response. As such, the cost of clarification goes up dramatically, so being clear in your communications is a much higher priority.

I have a few suggestions here:

  • Include extra detail in communications. Give as much context as you can.
  • Plan ahead about what you will need to communicate to complete the story you’re working on. It’s better to identify blockers before you get to them so your team can be proactive about answering questions.
  • Set aside time every day to get caught up on conversations you missed and respond to any questions you can.

2. Meet in Person to Build Trust

Teams work better when there is trust, and trust is harder to build when you have fewer touch points with teammates. While it’s not possible for all teams, I’ve found the benefit of meeting each other in person even once can have a big impact on team dynamics. Getting together on a call to talk through a feature one-on-one can also go a long way.

Building up trust makes code reviews less intimidating, and it reduces the mental barrier behind asking for help.

3. Break Down Knowledge Silos

From specific workflows to data types to new patterns after a refactor, I’ve found it easy to accumulate shared knowledge with developers in my office. However, I often fail to communicate that knowledge with the rest of the team. This can result in the rest of the team getting blocked, pull requests that don’t adhere to new patterns, and all-around team pain.

Here are a few of the practices we’ve adopted to mitigate this problem:

  • Make sure to notify the whole team in a visible place (your messaging tool is probably better than email) any time a note-worthy change has been made.
  • Bring in a larger subset of the team for pairing. We’ve had many pairing sessions where there have been four of us on a call, and it’s helped transfer knowledge.

4. Over-Communicate Expectations

Because the clarification loop is much slower for distributed teams, it’s important to reduce the chance of miscommunication as much you can. This is especially true when creating user stories. Here are a few ways you can add extra clarification on stories:

  • Add checklists of what needs to be done.
  • Document related work that does not need to be done for this story to avoid doing extra work.
  • Attach screenshots or links to design for applicable stories.

5. Be Prepared for Longer Pull Review Cycles

This is one of the more frustrating parts of working across time zones. When there are multiple rounds of change requests on a pull request, it can take many days to get a PR approved. Things will move slower here, and I think that’s unavoidable.

The important thing is to plan for longer pull request review cycles, and be ready to do some other work while you wait for feedback. This may may involve having a small handful of PRs out while you work on another feature.

Those are the most valuable practices I’ve found while working on a remote team. Do you have any tips or suggestions? Let me know!