Internationalization is a difficult problem is software-engineering. Usually that statement would refer to the technical aspects of providing a good user experience for your customers. Today, however, I am referring to the social aspects.
Just as it has become common-place to have your users spread across the globe, so it has with developers. It is not uncommon to work with teams in another country, or even to have a specific team-member working from a remote location. Being able to cooperate with developers across the globe is a great enabler. But as the case is with - well - everything, it has some obvious - and some less obvious - pitfalls to avoid.
First and foremost - know the time-zones your colleagues reside in.
You already know that some of your teammates tend to arrive a bit early or a bit late. You know it, and you adjust to it. You won't make a colleague who starts 2 hours before you stay for a meeting when you know they should be picking up their kids from kindergarten, right?
Well, all you need to do now is adjust to having teammates arriving at work 10 hours before you.
Yes, that's AM. The one that's confusingly set at midnight.
Now imagine that you're in a UTC-07:00 time-zone (Pacific Daylight Time) and the rest of your team is in a UTC+03:00 time-zone (Israel Daylight Time). Your daily-standup is at 10AM, which sounds reasonable. But that's in Israel. Sadly, this translates to 12AM for you. But you can accommodate that, can't you?
Luckily, in the real-world company HQs tend to be in the USA, not Israel. So you're safe. You can hold your meetings at any time you want, and they'll have to adjust. You can have them wake up early, or stay up late, or just work very awkward shifts. They'll accommodate. But do you really want to make your teammates do that?
It's not that I don't want to, it simply isn't possible.
If you have a large enough time-difference (say, 6 hours difference over a 9 hours work-day) your day starts when your colleagues' day ends (or later!)
No matter how hard they work, they cannot get it done by EOD if EOD has already passed. You can talk about getting things done "by tomorrow", but not EOD. It causes un-needed tension as the need to explain this comes up over and over during planning meetings.
Great. You've just killed of a day's work for your distant colleagues. 9PM San-Francisco is 7AM in Tel-Aviv. Making it a 7AM-4PM downtime for them.
I'm not saying you can't do that, but you should try and keep that in mind.
And on the seventh day God ended His work which He had done, and He rested on the seventh day from all His work which He had done.
Then God blessed the seventh day and sanctified it, because in it He rested from all His work which God had created and made.
And so in Israel we rest on the 7th day, and add the 6th in for good measure.
We work Sunday through Thursday, and rest on Friday and Saturday. And this is annoying.
It is annoying when we need support on Sunday and have to wait.
It is annoying when we travel, and are never sure if we should report Friday as overtime, or Sunday as a day off.
And it is annoying to be expected to work on Friday evening just because it's a working-day for you. You wouldn't want to work Saturday nights, would you? I didn't think so.
Also, you should expect email send on Fridays and late Thursdays to be ignored until Sunday.
This has been a bit of a rant, and a bit of advice as well. I'm not sure which dominated the tone.
This might seem like a minor issue, but it can cause a great deal of pain when ignored.
But in the end, the rules are simple. All you need to do is be aware, and be considerate. You can do it for the people you physically see everyday, and you can do it for your remote colleagues.
Try and set your long-distance meeting at times suitable for both ends. And when that isn't possible - make sure you make an effort as well. Waking up an hour earlier every now and then goes a long way.