4 ms·

For now!

by pc 7y ago

For now!

ingenieroariel 7y ago
If you want to test out workers outside of USA but not have to solve the timezone related issues I recommend Colombia. There is at least one interested person there.
- kypro 7y ago
  As someone who's worked remote with "timezone issues" before they're not for the company to solve. If you live in Europe but work for a US company that requires you to work US times, it's simple, you work US times. This is how I've worked before and it's worked out perfectly. In fact, I'm a bit of a night owl so I much preferred it.
  - jhgaylor 7y ago
    I work at a company where everyone is expected to be in the office. But we have early birds and night owls employed by the same company to work together. We don't have a formalized solution as night owls do as you described and get on up if they have work due in the morning. Or the early birds will stay up late to help the night owls finish. But a lot of companies take on "Core hours" and essentially solve the timezone problem even with a physical office. With core hours management is deciding that they don't want to solve the "timezone issues". I wonder how well the opposite end of the spectrum would work. Our async communication tools are pretty good these days. You could keep someone solving the problem all day long with just 3 or 4 hires but instead people choose to work on the problem in scheduled bursts of 6 hours with their entire team.
    - jypepin 7y ago
      if you are interested and want to solve this for your company, look into Gitlab. They are solving it and have very good public documentation on this.
      - emilycook 7y ago
        GitLab employee here, yes we do! I honestly couldn't go back to a company without asynchronous communication. https://about.gitlab.com/handbook/communication/ https://about.gitlab.com/handbook/communication/
    - brodock 7y ago
      Also GitLab employee here. I work for the Geo team (geographical replication and disaster recovery), and funny thing is we are also sparsely geographically distributed. No single person in the same country. We have people spread out with all impossible timezones combinations, from US west-coast, Brazil, Europe (east/west) going all the way to Australia.
  - peterjmag 7y ago
    I disagree — those issues are totally for the company to solve. Or at least, the company should be prepared to meet employees halfway. If a North American company is going to insist that I work North American hours whilst living in Europe, I'm just not going to work there. And I'm sure I'm not the only one who feels that way. I live in Europe and work for a very remote-friendly, NY-based company, and I work pretty normal European hours. I have 2-3 hours of overlap with the various members of my team, and that's all I need. (In fact, I'm more productive in the morning here because it's easier for me to focus when our group chat is mostly quiet.) Of course, it's not as simple as saying that you can work from anywhere for anybody at any time, but I don't think it's fair to say that timezone issues are not for the company to solve.
    - lugg 7y ago
      > And I'm sure I'm not the only one who feels that way. Your not, what AP thinks is reasonable would be considered rediculous if you frame it under normal satellite office scenarios. Can you imagine Sydney Googlers all catching the late train into the city to work the night shift. Like come on. Re stripe limiting to NA only I get their concerns but its a failing approach. They're going to build out remote teams and a bunch of practices that rely on this timezone sync. Swapping out real-time communication to async communication is going to be much, much harder once those practices are ingrained. They also need to add more than just engineering into this remote hub. Having all your non engineers in offices is going to create a very odd adversarial culture.
  - jypepin 7y ago
    No, this is not how the timezone should be solved, and great if it works for you, but this is just not sane for most people. To solve the timezone issue, you put in place as much tools and processes as possible around working asynchronously instead of having meetings all days. This is why most remote setups work better in fully remote companies - they are more incentivised to put those things in place.
  - geofft 7y ago
    I think one of the fundamental things about remote work culture is default working async with occasional blocks of scheduled sync time, instead of default working sync with occasional affordance for async time (when you're at a meeting away from your desk etc.). You're working more the way an open-source project works, with higher-bandwidth higher-latency communication channels like email or code review tools instead of in-person conversations. If you have timezone issues at all (outside of your on-call rotation), that means you haven't figured out your remote story yet. Which is totally fine! I'd have trouble imagining how you figure it out without already doing it. So it makes sense that they're starting in a half-remote state and then intending to get really remote at some point.

For now!

by pc 7y ago

For now!

If you want to test out workers outside of USA but not have to solve the timezone related issues I recommend Colombia. There is at least one interested person there.

kypro 7y ago
As someone who's worked remote with "timezone issues" before they're not for the company to solve. If you live in Europe but work for a US company that requires you to work US times, it's simple, you work US times. This is how I've worked before and it's worked out perfectly. In fact, I'm a bit of a night owl so I much preferred it.
- jhgaylor 7y ago
  I work at a company where everyone is expected to be in the office. But we have early birds and night owls employed by the same company to work together. We don't have a formalized solution as night owls do as you described and get on up if they have work due in the morning. Or the early birds will stay up late to help the night owls finish. But a lot of companies take on "Core hours" and essentially solve the timezone problem even with a physical office. With core hours management is deciding that they don't want to solve the "timezone issues". I wonder how well the opposite end of the spectrum would work. Our async communication tools are pretty good these days. You could keep someone solving the problem all day long with just 3 or 4 hires but instead people choose to work on the problem in scheduled bursts of 6 hours with their entire team.
  - jypepin 7y ago
    if you are interested and want to solve this for your company, look into Gitlab. They are solving it and have very good public documentation on this.
    - emilycook 7y ago
      GitLab employee here, yes we do! I honestly couldn't go back to a company without asynchronous communication. https://about.gitlab.com/handbook/communication/ https://about.gitlab.com/handbook/communication/
  - brodock 7y ago
    Also GitLab employee here. I work for the Geo team (geographical replication and disaster recovery), and funny thing is we are also sparsely geographically distributed. No single person in the same country. We have people spread out with all impossible timezones combinations, from US west-coast, Brazil, Europe (east/west) going all the way to Australia.
- peterjmag 7y ago
  I disagree — those issues are totally for the company to solve. Or at least, the company should be prepared to meet employees halfway. If a North American company is going to insist that I work North American hours whilst living in Europe, I'm just not going to work there. And I'm sure I'm not the only one who feels that way. I live in Europe and work for a very remote-friendly, NY-based company, and I work pretty normal European hours. I have 2-3 hours of overlap with the various members of my team, and that's all I need. (In fact, I'm more productive in the morning here because it's easier for me to focus when our group chat is mostly quiet.) Of course, it's not as simple as saying that you can work from anywhere for anybody at any time, but I don't think it's fair to say that timezone issues are not for the company to solve.
  - lugg 7y ago
    > And I'm sure I'm not the only one who feels that way. Your not, what AP thinks is reasonable would be considered rediculous if you frame it under normal satellite office scenarios. Can you imagine Sydney Googlers all catching the late train into the city to work the night shift. Like come on. Re stripe limiting to NA only I get their concerns but its a failing approach. They're going to build out remote teams and a bunch of practices that rely on this timezone sync. Swapping out real-time communication to async communication is going to be much, much harder once those practices are ingrained. They also need to add more than just engineering into this remote hub. Having all your non engineers in offices is going to create a very odd adversarial culture.
- jypepin 7y ago
  No, this is not how the timezone should be solved, and great if it works for you, but this is just not sane for most people. To solve the timezone issue, you put in place as much tools and processes as possible around working asynchronously instead of having meetings all days. This is why most remote setups work better in fully remote companies - they are more incentivised to put those things in place.
- geofft 7y ago
  I think one of the fundamental things about remote work culture is default working async with occasional blocks of scheduled sync time, instead of default working sync with occasional affordance for async time (when you're at a meeting away from your desk etc.). You're working more the way an open-source project works, with higher-bandwidth higher-latency communication channels like email or code review tools instead of in-person conversations. If you have timezone issues at all (outside of your on-call rotation), that means you haven't figured out your remote story yet. Which is totally fine! I'd have trouble imagining how you figure it out without already doing it. So it makes sense that they're starting in a half-remote state and then intending to get really remote at some point.