Working in a cross-ocean team: how to find your way through time

You look at the clock and it’s ridiculously late. Your friends post photos of themselves eating dinner with friends and you’re counting minutes to the last meeting of the day, which starts at 7:30 pm. If you’ve been in such a situation in your life, you probably know very well what it means to work in a cross-ocean team.

I do too. I work in remote teams for 6 years now. Different setups, different companies, different people, but what remains unchanged is a huge time difference between people working in the same team. During the years I learned there are some patterns to make this setup a bit smoother. Bare with me if you want to find out more.

Be agile, but plan ahead

It seems like most projects developed in engineering teams across the world are utilizing agile methodologies. Agile is great for software development because it does not imply any strict rules to the team, but it rather allows the team to build the development process around the environment and surrounding conditions. Many people understand Agile to be “something opposite to waterfall”, automatically assuming that it’s OK to juggle priorities and have the work requirements prepared “as they go”, just before development. You can most likely get away with it when the entire team is co-located (I would not recommend that though), but when working in a cross-ocean team, this will simply not do. At least a minimal level of planning ahead is essential for the team to be able to work smoothly.

I believe it’s perfectly OK to plan ahead enough so that the person on the other side of the globe doesn’t have to wonder what to start working on when they’ve just finished one of their tasks and you’re well into the deep phase of your sleep. Just make sure the team has enough stuff in the pipeline for the team to always be able to pick something up — clearly defining the requirements for future tasks always helps, especially when you do it a bit more than a day before the actual work starts — it gives everyone the time to read through it and ask for more details if needed. If you’re working on scrum or kanban, make sure the team members have all they need to start working on a ticket at the backlog refinement sessions.

Refine your task descriptions

No matter what tool you use for managing the projects and keeping the information about upcoming tasks (Jira, Trello, something in-house maybe?), it’s crucial for all team members to face the question of “Do I know everything I need to start working on this story?” in the right moment (at backlog refinement for example) — this makes everyone in the team responsible for understanding what’s really to be done there. I assume you already run a meeting where the team discusses the upcoming work. If you’re often facing a problem of your teammate being afraid to start working on a specific task, there’s a fair chance it’s because they don’t know how to start. What helped me in such situations was asking team members at the meeting what would be the first couple of steps they’d take at the start of their work on the task. This ensures that folks on the team understand not only what is required from them but also, that they know how to achieve that.

Understand (and embrace) cultural differences between team members

There’s a big chance that your team members living in different parts of the world were also born in different parts of the world. This means there’s a cultural gap between them. It can be big or it might be smaller, but it’s a fact that cultural differences are real. When it comes to working with people, there’s never enough education you can do to help yourself understand how they operate. There are many possible actions you can take to get to know more about your teammates, like reading the literature on overall culture in different countries and social standards in workplaces around the world, but for me, the most powerful one is talking — have the team meet together to find out a bit more about themselves. If it is not possible to do it in person, then using video conferencing is fine. Let them define how they prefer to work, what they are interested in (both in and outside of work) and what kind of things they’re not big fans of. Ask your team members how they prefer to get feedback from each other — do they prefer a conversation or a written form?

In the end, your ultimate goal is for the team members to trust each other. The better the teammates know each other, the bigger the chance to create a sense of stability and comfort, leading to building trust.

Do not leave your work in an unknown state (at least at the end of the day)

This one is very operational but also important. In order for software development in a cross-ocean team to be effective, you should avoid situations when one person tries to pick up where the other one left things and finds out the software doesn’t even compile / work / is a huge mess. There are a couple of rules that you can advocate for inside the team to help in avoiding these situations, such as:

• Writing the documentation right away whenever you’re adding a new feature in the code
• If you’re using a version control system (I really hope you are) try making sure the app works (does not blow up at least) when you commit your work
• Leave the information about the state of your work at the end of the day (using communicator, in a ticket in the project management system, or in a pull request description — have it unified so folks don’t have to look around all the tools to find it).

If you’re using GitHub and Travis / Jenkins, you can easily set up unit tests runner or even just a code build to be run after every change to make sure there are no commits that break the build. You can also set up git hooks to run a task on your machine before the commit is done in the first place, to avoid making a commit in the first place if it breaks the app.

Help yourself with reminders

If you know you’re working on something in collaboration with another team member from a different timezone, set yourself a reminder to let them know what you were able to achieve throughout the day of your work. You can use Google Calendar to do that, Slack also has a lot of apps that you can integrate it with and use for setting reminders. It even has a built-in reminders feature. Now you’re sure your colleague knows where to start continuing what you’ve worked on. I wouldn’t set the reminder to repeat every single day as at some point you’ll just stop caring (especially when not working on stuff with another remote team member). Set it when you know you’re working with someone in a remote location — Calendar will do the rest (triggering a reminder when the time comes).

Look for improvement ideas

Work in a cross-ocean team can be effective and all you have to do is to eliminate the communication problems along the way — rules can help, but you’ll figure out the most fixes to your team’s problems by asking for feedback and observing how the team works on a continuous basis.

A retrospective is a great place to do that. Instead of running a standard “what went well / what can we improve” retro focused on the last sprint, ask people about their satisfaction from the current software development process in the team — ask them for ideas to make it better and discuss if it makes sense to try some of them out.

Try new things

It applies to all the teams I’ve been a part of, not only the cross-ocean ones. Don’t be afraid to experiment with the process. If one of the developers has an idea for improvement of the process but the rest of the team is unsure if it can make things better, suggest to try it out for a day or a week to gather thoughts and results.

Great ideas are flowing everywhere, but a lot of them need a driving force to be implemented, that driving force being someone courageous enough to make it happen.

There is hope

I do believe that cross-ocean teams can work, but it requires consistent work on improving the communication step-by-step for the teams to find the right ways of understanding and completing each other. Cross-ocean teams have some advantages over co-located teams:

• Much bigger timezone coverage (if something breaks, there’s a great chance that someone in the team is not sleeping and can fix it)
• There’s an exchange of cultural views that rarely happens in co-located teams
• It’s easier to hire when you have multiple markets when you can look for employees, not just one city or country.

Make use of these. Make use of the communication skills you have. Make it work! And remember — improving communication is important not only in cross-ocean teams but in the co-located ones as well. This article was written with cross-ocean teams in mind, but the tips described can introduce a positive change even if the team is not distributed.