Those of you with a global remote staff: Does your team need to work in the same general time zone (+/- a few hours) to be effective? How important is co-location to successful DevOps?
Sort By:
Oldest
Director in Manufacturing2 years ago
And to clarify one more point, even within CENTRAL TIME ZONE, most people did not work in the same city or state. We were early remote collaborators, but did it over the phone and with very crude screen sharing. The issue is really Time ZONE related, not physical location related.
CTO in Software2 years ago
+/- 3 hours if you want to have regular team meetings at optimal times. Chief Techical Officer in Software2 years ago
Ideally a 2-3 hour overlap works well. That said I’ve had success with team members that are 8 hours apart. Some like to start early some like to take mornings off and work into the evening. It’s easy to make it work if you remember not everyone wants to work 9-5 in their time zone.Chief of DevOps and Partner in Healthcare and Biotecha year ago
>Does your team need to work in the same general time zone (+/- a few hours) to be effective?No
>How important is co-location to successful DevOps?
It is not that important .
It is not strictly necessary to work in the same general time zone to be effective, although it can help in certain situations. The importance of co-location and time zone alignment in a successful DevOps environment depends on various factors such as communication, collaboration, company culture, tools and processes.
To make joint working sessions possible, some team members had to work during non-core hours, which often meant joining calls in the middle of the night. I have lost count of how many calls I hosted that started at 11 pm my local time and went on until 1 am, 2 am, or even 3 am. In my opinion, this kind of schedule is unsustainable for long-term projects.
On the other hand, from an operations standpoint, having a more diverse team with members from different time zones can be beneficial. It means that fewer people have to be on-call during non-core hours, allowing for a more rested team overall. With wider time zone coverage, the team can work and troubleshoot during their most alert hours, which can lead to more efficient operations. I believe that it is possible to work successfully with a DevOps team spread across many time zones, but the impact of non-core hours needs to be addressed upfront and fairly distributed across all time zones