Working across time zones
I have worked with many teams that span from Europe to the west coast of North America, both at Shopify and at my previous company. 9 AM PST is 6 PM CET, their work days don’t even overlap!
So we have to be a little bit flexible if we want to ever have a meeting with everyone. But at the same time we want to keep things sustainable and as pain-free as possible, and there’s a lot of good that comes out of embracing a more asynchronous working style:
- More focus time for makers.
- Defaulting to writing means getting in the habit of externalizing information.
So we lean into async communication by default.
Some practices that can help work effectively with time zone differences:
- Default to writing in a place that externalizes information, and then sharing just a link to it in chat. Then you get future benefit from it, e.g. putting something directly into documentation or a GitHub issue or the project board instead of ephemeral chat.
- Keep all-hands meetings to the absolute minimum. At most one per week. If it requires a big stretch for those at the far ends of the time difference then also do them at alternating times and make it acceptable to watch a recording instead.
- For all meetings consider the purpose and whether it’s the type that can be done partly or fully as writing instead. Think document-centred communication instead of meeting-centred communication. If you do need a meeting for final alignment or decision-making it’s much higher-leverage.
- For all meetings, assume some people won’t be present. Take notes and share them with everyone who was invited. Don’t rely on recordings, a good written summary is a lot more efficient.
- Normalize turning off notifications outside of work hours. This makes it easier for anyone to send messages freely without worrying about bothering people outside of their working hours.
- Set working hours in your calendar and block any times that you’re unavailable (lunch time, caregiver times, etc). This makes scheduling meetings easier.
I still encourage lots of pair programming between folks who do overlap comfortably (even though this does tend to partition the team a bit), but for most other things I think it’s beneficial to default to writing.