Ask HN: How has your remote team solved communication across time zones?
16 comments
If you're working without any shared hours, then you've got to communicate differently or you will have multi week ping pong sessions.
Sometimes that's not avoidable, but if both parties recognize the situation and change styles, it can help in most situations. Provide all the relevant information in the first message; read the whole message before and while responding. Expect to not get instant feedback.
It's like writing a letter vs having a phone call.
Otherwise, have realtime sync up at the edges of the workday.
Sometimes that's not avoidable, but if both parties recognize the situation and change styles, it can help in most situations. Provide all the relevant information in the first message; read the whole message before and while responding. Expect to not get instant feedback.
It's like writing a letter vs having a phone call.
Otherwise, have realtime sync up at the edges of the workday.
> It's like writing a letter vs having a phone call.
This is the way. If you adopt the same communication style as the old scientists (euler?), you’d get a lot done. You write clear, detailed requests, responses, and notices and the delays with the back and forth won't matter that much. Maybe that's why most of the scientists we know of have been people with good communication skills.
Then schedule meeting with a clear agenda when synchronous collaboration is needed.
This is the way. If you adopt the same communication style as the old scientists (euler?), you’d get a lot done. You write clear, detailed requests, responses, and notices and the delays with the back and forth won't matter that much. Maybe that's why most of the scientists we know of have been people with good communication skills.
Then schedule meeting with a clear agenda when synchronous collaboration is needed.
Thanks! Have you noticed types of communications that typically can't be solved by improving messaging and require a realtime sync up? If so what are they?
Troubleshooting when you don't have enough experience to know what's relevant to share can go a lot faster in real time. Or also when you're pretty far off on what you thought was relevant. If both parties are inexperienced, it can be hard to form the right questions from both sides.
In general, open ended exploration can be hard by letter as well.
In general, open ended exploration can be hard by letter as well.
I've seen two primary strategies for handling cross-time zone communication in teams:
Synchronous: A single time zone is designated, and all team members adapt accordingly. Although, this can be a pain for people far away.
Asynchronous: Flexible “overlap” periods are defined where everyone must be online.
In practice, though, remote teams I've worked in just seem to understand and accept that: A) You don't need a 'call', 'quick chat' or 'meeting' over video or voice most of the time B) If you are in a remote team, there is shared acceptance that there will be A LOT of asynchronous communication and people will reply when they can or are available. C) The situation changes the more time-zones you cover. Be flexible.
Those with roles that are 'mission-critical' or 'perpetually online', are usually on call or have a phone that is always available.
A handy resource for aligning schedules: https://www.timeanddate.com/worldclock/converter.html
Synchronous: A single time zone is designated, and all team members adapt accordingly. Although, this can be a pain for people far away.
Asynchronous: Flexible “overlap” periods are defined where everyone must be online.
In practice, though, remote teams I've worked in just seem to understand and accept that: A) You don't need a 'call', 'quick chat' or 'meeting' over video or voice most of the time B) If you are in a remote team, there is shared acceptance that there will be A LOT of asynchronous communication and people will reply when they can or are available. C) The situation changes the more time-zones you cover. Be flexible.
Those with roles that are 'mission-critical' or 'perpetually online', are usually on call or have a phone that is always available.
A handy resource for aligning schedules: https://www.timeanddate.com/worldclock/converter.html
For time zone awareness, my go to is https://www.worldtimebuddy.com/
Really depends on the kind of communication. We have a few tips in our handbook https://handbook.gitlab.com/handbook/communication/ but here are my personal observations.
1) Things like code reviews should be more extensive if feedback loops are long. One should be clear whether something is blocking or not. A lot of people use (and came up with) https://conventionalcomments.org/. Personally I really like to assign someone in the States or APAC and come back the next day haben my code reviewed.
2) regular meetings are often being alternated to be friendly between different time zones. e.g. one week APAC/EMEA friendly and another EMEA/AMER. All meetings have agendas and everyone can add points, even if they cannot attend. Also all meetings should be optional.
1) Things like code reviews should be more extensive if feedback loops are long. One should be clear whether something is blocking or not. A lot of people use (and came up with) https://conventionalcomments.org/. Personally I really like to assign someone in the States or APAC and come back the next day haben my code reviewed.
2) regular meetings are often being alternated to be friendly between different time zones. e.g. one week APAC/EMEA friendly and another EMEA/AMER. All meetings have agendas and everyone can add points, even if they cannot attend. Also all meetings should be optional.
Interesting! The handbook contains a lot of useful information.
I noticed that it emphasizes the importance of documenting work to prevent bottlenecks in asynchronous communication. It also discusses choosing the most effective form of media for conveying messages.
What does this look like in practice? How easy is it to find relevant information in the archives or documentation? Are there times when you cannot locate such information and must wait for the appropriate person to be online to get an answer? If so, what types of communications typically cause these delays?
I noticed that it emphasizes the importance of documenting work to prevent bottlenecks in asynchronous communication. It also discusses choosing the most effective form of media for conveying messages.
What does this look like in practice? How easy is it to find relevant information in the archives or documentation? Are there times when you cannot locate such information and must wait for the appropriate person to be online to get an answer? If so, what types of communications typically cause these delays?
> What does this look like in practice?
There are basically _four_ systems where we store information: Recordings of Meetings, good if you want to re-watch a meeting you missed. Google Documents which I would consider more ephemeral, (but then our Frontend Meeting goes back hundreds of pages as a Google Doc). Slack is used, we have hundreds of channels. Actually information is not retained forever in Slack, which I like because it forces people to document things elsewhere.
The biggest benefit: git + issues / merge requests. Most of our handbook and company policies are markdown files in git. So even with renames and reformatting you can track the MR that changed it and 99% of the time find the reason _why_ someone changed it. Either the assumptions are still valid or you can propose another change if they aren't. If it is really dubious as to why something is the way it is, there will be someone responsible for that thing and you reach out.
> How easy is it to find relevant information in the archives or documentation?
Very. (Most) of the handbook is public, so any search engine is your friend. Google Docs search is alright. Otherwise checking things out locally is easy too and the history / relevant things are right there. Furthermore we have dozens/hundreds of Slack channels, where you ask your question and usually you get a relevant answer which you can document in a better and relevant place.
> Are there times when you cannot locate such information and must wait for the appropriate person to be online to get an answer? If so, what types of communications typically cause these delays?
As an employee it happens from time to time, think Finance, or Legal, or Compliance or Human Resource issues.
As an Engineer, you get used to it. You never work on "one thing" any given day, but you kind of adopt a strategy where moving slow means moving fast. It sounds like a contradiction, but if a lot of people have kind of equally important streams of work going on at the same time, each person can move forward and we always have enough relevant things being finished every day/month/year for our users and customers.
So personally I look at my highest priority for the next week / day, try to identify whether I need input from others early (no better: earlier) and make sure I get this feedback and resolve blockers. If I run into new blockers, I solicit new feedback as early as possible, e.g. by pushing a broken/unfinished MR and pinging the relevant people on it, asking their opinion. Once the code is ready, fan out and get all the approvals needed. I think a small bug-fix is mergeable within a day, medium sized addition 3 to 5 work days and big feature better be chunked into Feature Flag + a few of those medium sized additions.
There are basically _four_ systems where we store information: Recordings of Meetings, good if you want to re-watch a meeting you missed. Google Documents which I would consider more ephemeral, (but then our Frontend Meeting goes back hundreds of pages as a Google Doc). Slack is used, we have hundreds of channels. Actually information is not retained forever in Slack, which I like because it forces people to document things elsewhere.
The biggest benefit: git + issues / merge requests. Most of our handbook and company policies are markdown files in git. So even with renames and reformatting you can track the MR that changed it and 99% of the time find the reason _why_ someone changed it. Either the assumptions are still valid or you can propose another change if they aren't. If it is really dubious as to why something is the way it is, there will be someone responsible for that thing and you reach out.
> How easy is it to find relevant information in the archives or documentation?
Very. (Most) of the handbook is public, so any search engine is your friend. Google Docs search is alright. Otherwise checking things out locally is easy too and the history / relevant things are right there. Furthermore we have dozens/hundreds of Slack channels, where you ask your question and usually you get a relevant answer which you can document in a better and relevant place.
> Are there times when you cannot locate such information and must wait for the appropriate person to be online to get an answer? If so, what types of communications typically cause these delays?
As an employee it happens from time to time, think Finance, or Legal, or Compliance or Human Resource issues.
As an Engineer, you get used to it. You never work on "one thing" any given day, but you kind of adopt a strategy where moving slow means moving fast. It sounds like a contradiction, but if a lot of people have kind of equally important streams of work going on at the same time, each person can move forward and we always have enough relevant things being finished every day/month/year for our users and customers.
So personally I look at my highest priority for the next week / day, try to identify whether I need input from others early (no better: earlier) and make sure I get this feedback and resolve blockers. If I run into new blockers, I solicit new feedback as early as possible, e.g. by pushing a broken/unfinished MR and pinging the relevant people on it, asking their opinion. Once the code is ready, fan out and get all the approvals needed. I think a small bug-fix is mergeable within a day, medium sized addition 3 to 5 work days and big feature better be chunked into Feature Flag + a few of those medium sized additions.
Slack. Very few meetings. Defining projects and workflow so people don't get stuck waiting for answers or collaboration.
Thanks! Have you noticed types of communications that typically can't be solved by well defined workflows/projects that require a realtime sync up? If so what are they?
I can’t think of any. We have enough overlap in flexible work hours to DM on Slack. Usually just two people need to chat to resolve issues and answer questions, we almost never get the whole team involved.
I forgot to mention GitHub, used for issues, PR reviews, and documentation.
We encourage developers to work through problems rather than stop and wait for answers. Stub in some code and keep going if they need clarity on requirements. Expect most code to get revised iteratively. That keeps everyone moving.
I forgot to mention GitHub, used for issues, PR reviews, and documentation.
We encourage developers to work through problems rather than stop and wait for answers. Stub in some code and keep going if they need clarity on requirements. Expect most code to get revised iteratively. That keeps everyone moving.
I think using slack asynchronously (and developing norms that support it) is useful. Also imo there's an unspoken tradeoff when you work for a full remote company across time zones. Most workers seem comfortable with trading the convenience of remote work for the possibility of getting pinged outside work hours.
Ya I’m a big remote guy but you gotta be +-3 hours. Anything more and one side needs to alter working hours.
Everyone works and speaks in EST regardless of where they live.
I have noticed that a lot of startups are fully remote and hire globally, so I'm just wondering what the solution to this communication problem is.