Product development: good practices on working in different time zones
There’s a 9-hour difference between Warsaw and San Francisco. When our development teams are having their first coffee at 8am, a product owner they’re collaborating with is watching “just one more episode” of their favorite Netflix show at 11 pm. How best to deal with such a big time difference when working on a complex digital product that involves dozens of people separated by nine hours? Let’s take a closer look at the best practices we’ve developed while working with one of our American partners, a leading US e-commerce company.
Table of contents
The Setup
In this particular case, we worked with the client’s internal development team. Our team started the day around 5pm, with the daily Scrum meeting at 5.45pm Warsaw time which translates to 8am and 8:45 am in California respectively. Our Scrum events (like sprint retrospectives, reviews and plannings) were scheduled between 6-8.40 pm Warsaw time. Thanks to this, all the people involved were able to meet in real time.
This timeframe also had a big influence on how we built the team but we will speak about that a bit later. Let’s focus now on the good practices we established working across different time zones!
Best practices for working in different time zones
1. Planning is the key
Make a team development roadmap as soon as possible to establish the necessary events, meetings, kick-offs, and feedback sessions (yes, we do them on a regular basis!) Most of the meetings should be planned in advance, so that there is no feeling of things being constantly ‘added to the calendar’.
2. Create a communication contract
This is a mutual agreement regarding the rules of communication. It should be a combined effort by both involved parties so that everyone can express their needs and limitations. It’s especially important to take care of urgent issues.
Exemplary rules to include in a contract are: “The team leaves no question without an answer”, “You can expect to get the answer within one hour, if the question was asked between 8am and 11am, California time”, or “We always ask questions by mentioning a particular person on Slack”, etc.
Thanks to such “contracts” signed by the teams, you minimize the risk of situations in which the client waits for an answer for the entire day because the overseas team … sleeps (this also works the other way around!)
3. Maintain balance
Especially between big, important meetings and the time the team has to spend on work. It’s okay to have two longer meetings during a week, but four is definitely too much - for both sides.
4. Set an active time overlap
If the client’s in-house team is involved, make sure both teams have a time period they can spend on pair programming or working together. The better they know and understand each other, the better their work will be. Make sure both sides know the exact time window when they can communicate with each other directly, and that both are online.
5. Be very specific
Communication rules and time windows when both teams are working must be very clear to avoid misunderstandings. The same goes for definitions of done and deadlines.
6. Take care of the people
Plan a space for your team to check on their well-being - working evenings might be very tiring for some and it is worth observing the situation and taking action when necessary.
Building the team
From my perspective, the time period when we are assembling a team to work on a client’s product is crucial. Not everyone can, or likes to, start their workday in the late afternoon/ evenings. Some people have family and household duties that can’t be skipped. We need to be truly mindful of those aspects so that only people that can be fully focused are picked for such a team.
That’s why when we set up a team for a partner from the US (or any other country in a different timezone), we make sure:
- That people are aware that for the next couple of months (or even longer) they may end up working around 8 p.m. (or later!) and it can influence their private life.
- That the team is made of people who are fully engaged in this particular product, so they can avoid working on two different products across various time zones.
- The developers (and product designers and also the scrum master) who are asked to work “night shifts” (to share a time window with the client’s team) are completely fine with this solution and understand the commitment.
Practice makes perfect
Here at Boldare, working with clients based in America or other continents is nothing new. Partners from the United States were and are an important part of our portfolio, and the good practices I mentioned above are not built only around this experience. It’s just a good example of how to take care of the tiny details that make work seamless for both sides.
If you wish to learn more about our American partnerships, explore these case studies:
Share this article:
