4 ms·

Speaking as an employment _provider_ I fully agree nomad != remote. I'm actually hesitant to employ nomads if they are likely to move without warning to time zo

Speaking as an employment _provider_ I fully agree nomad != remote. I'm actually hesitant to employ nomads if they are likely to move without warning to time zones that aren't convenient for the rest of the team. For example, one of the things that makes distributed teams work is to have a small number of very stable meeting times that remain invariant for long periods of time. The reason is that people need to structure their lives (e.g., dinner with family) and if you change things capriciously it affects relationships with families or other things in their personal lives. Having team members suddenly move and then want meeting times changed for everyone is a real non-starter for me.

jpgvm 7y ago
I have been on remote teams with 2 different types of coordination. Meeting coordinated, which is usually centered around 1 or 2 weekly meetings when status updates and some amount of discussion of planning occurs. This model works best when a large portion of the team is on the same timezone or there is a physical office somewhere but isn't ideal for nomads or people that are permanently located in an inconvenient timezone. These meetings often come at a very high cost so if someone isn't getting value out of them then they don't feel great about them usually. The other is async/adhoc coordinated that mostly does synchronisation and planning through async means like chat, email and issue tracking. This I found works way better for travellers/nomads and people that generally don't need or want structured meetings. Especially if you mostly work on long tasks and the vast majority of your updates are "still doing the thing". If you couple this with adhoc/on-demand meetings where you grab small portions of the team to talk about smaller scoped things I find it works really well. Managers (well less good ones) in particular are less of a fan of this model because instead of having well defined sync points they need to be continually on top of how things are changing. Both have trade-offs, I find the second one works way better but is much rarer. I experienced my most productive time as an engineer working under such a model.
- hodgesrm 7y ago
  I'm definitely open to getting better at this so I'm glad the second model worked for you. I have run into practical problems with ad-hoc call when working across a lot of time zones (like 10 in our company). It's hard to slot in engineering ad-hoc meetings because the slots are limited to begin with and already used up with other things like talking to customers. We definitely try to avoid burning people's time. Slack has been helpful for intermittent communication.

jpgvm 7y ago

I have been on remote teams with 2 different types of coordination. Meeting coordinated, which is usually centered around 1 or 2 weekly meetings when status updates and some amount of discussion of planning occurs. This model works best when a large portion of the team is on the same timezone or there is a physical office somewhere but isn't ideal for nomads or people that are permanently located in an inconvenient timezone. These meetings often come at a very high cost so if someone isn't getting value out of them then they don't feel great about them usually. The other is async/adhoc coordinated that mostly does synchronisation and planning through async means like chat, email and issue tracking. This I found works way better for travellers/nomads and people that generally don't need or want structured meetings. Especially if you mostly work on long tasks and the vast majority of your updates are "still doing the thing". If you couple this with adhoc/on-demand meetings where you grab small portions of the team to talk about smaller scoped things I find it works really well. Managers (well less good ones) in particular are less of a fan of this model because instead of having well defined sync points they need to be continually on top of how things are changing. Both have trade-offs, I find the second one works way better but is much rarer. I experienced my most productive time as an engineer working under such a model.

hodgesrm 7y ago
I'm definitely open to getting better at this so I'm glad the second model worked for you. I have run into practical problems with ad-hoc call when working across a lot of time zones (like 10 in our company). It's hard to slot in engineering ad-hoc meetings because the slots are limited to begin with and already used up with other things like talking to customers. We definitely try to avoid burning people's time. Slack has been helpful for intermittent communication.