If you have international teams, they shouldn't be working on the same project, if it can be avoided. Having teams with different working hours work the same project sabotages communications.
I have to disagree vigorously based on my current experience. My team, working on a single project/product, is globally distributed. There are team members in APAC (New Zealand), Europe, and America, and (IMO) we do very well at communicating and producing solid results.
It does take specific effort, mainly expressed in written communications in tickets/issues and other more ephemeral channels (Slack in our case). You have to think carefully about what information must be shared and how to do so. You can't just drop a random comment and hope for a good interpretation. There needs to be a "call to action": a question, a request for specific activity/response, or a suggestion (or several) for possible next steps. There also needs to be trust built between team members, which takes time and similar effort.
But when this is unlocked to its fullest potential it becomes an absolute super-power. The problem you were facing when you finished the day? Fixed by your team-mates when you start the next day, some more progress (hopefully), and they hand back the next problem to solve. Apparent velocity goes through the roof and personally I find it incredibly satisfying.
Mind you, this is all coming from an all remote/all async company. I can potentially see problems if you had two part-teams in separate time-zone separated offices with minimal overlap. Then you'd potentially run into the usual human tribalism and culture drift, and communications aren't necessarily going to solve that.
At large companies, it's unavoidable to a certain degree. In my case, it's mostly East Coast to Europe though which is pretty manageable. Asia to US is definitely tough. You're either going to have people on late-night calls or getting up in the middle of the night. It works for the odd sync but is tough on a regular basis.
> Having teams with different working hours work the same project sabotages communications.
Not really, but you have to become good at written communication. Which has a lot of benefits beyond the immediate one.
In companies where everything happens by people huddling together real-time, the result is (nearly always) that nothing is documented, which leads to disaster longer term.
I've loved working on projects where the team is globally distributed so that there is activity 24hrs and you work with people with zero overlap on working hours.
Instead of relying on ephemeral hallway conversations, you need to build a culture of updating tickets with informative content, documenting plans, and so on. This fill the immediate need of daily communication but more importantly now you have everything documented and a paper trail of every decision and bug fix which is incredibly valuable.
It does take specific effort, mainly expressed in written communications in tickets/issues and other more ephemeral channels (Slack in our case). You have to think carefully about what information must be shared and how to do so. You can't just drop a random comment and hope for a good interpretation. There needs to be a "call to action": a question, a request for specific activity/response, or a suggestion (or several) for possible next steps. There also needs to be trust built between team members, which takes time and similar effort.
But when this is unlocked to its fullest potential it becomes an absolute super-power. The problem you were facing when you finished the day? Fixed by your team-mates when you start the next day, some more progress (hopefully), and they hand back the next problem to solve. Apparent velocity goes through the roof and personally I find it incredibly satisfying.
Mind you, this is all coming from an all remote/all async company. I can potentially see problems if you had two part-teams in separate time-zone separated offices with minimal overlap. Then you'd potentially run into the usual human tribalism and culture drift, and communications aren't necessarily going to solve that.