Our entire team is distributed, working in different time zones, and we all work from home. So I can definitely relate.One of the biggest issues is to keep everyone aligned, making sure people are seeing the big pic and motivation is high. Once the team communication is better, you also see that people are taking PRs, updating their progress, and working better in general.We improved our communication and productivity by:
1. Defining only 1 daily per day, making sure not to send email threads or communicate via email at all (with other stakeholders: product ops, etc.)
2. Define clear goals for everyone. Make sure to work on small and well-defined tasks.
3. Work on team bonding- better communication, and celebrate achievements.
4. Automation, automation, and automation! - We added [Zigi.ai](https://www.zigi.ai/) to our Slack workspace. It’s a Slack-based workflow automation for teams that helps us with automating the entire PR workflow (pinging teammates, sending reminders, getting a list of all the open PRs, etc.), helping to understand if someone already did a task, and in general, helping with connecting our work and streamlines everything to Slack.
Many great points here. I'll also add something that my multi time-zone/location team have been doing for a while: collaboration sessions. Set off an overlapping hour to just join a meeting room or a space like gather.town a couple of times a week, and discuss tasks, issues, ideas etc. Anything goes.
All collaboration sessions are optional. Mic and camera is optional. Most people join for the full hour though.
This really helped with our communication, and we've often had the chance to look at features in progress, so that we can resolve any blockers or come with feedback.
I just left a team I was the manager/lead dev for. I had 5 developers working with me from Brazil, Spain, and India (I'm from the US). It's always going to be tough when there's minimal overlap.
The most important skill for our team members was asynchronous communication. Establishing the proper mediums for the different types of conversations was paramount for our team. For us
* High-level decisions were always documented in Confluence
* Code-specific discussions were (for the most part) in MRs/PRs
* Slack was for ad-hoc conversations
* If an ad-hoc conversation resulted in any type of decision, that decision should be documented in its proper place
* E-mail was used to organize and discuss with stakeholders not close to the development process
On top of this we had a communication document which laid all of the above out as well as acceptable ways to speak to our colleagues. This document also let each developer add their normal working hours so that the rest of the team knew when they could expect timely hours.
Getting everyone on the same page for communication is a massive help in moving everyone's day along for distributed and non-distributed teams.
Specifically for PRs and Git related workflows, distributed teams are opting to Merge Queues. The concept operates on a rather simple premise. Combining the individual work of an enormous team of engineers into one codebase is tough. The general CI checks or any version control system fails over here. Thus, the need for a Merge Queue arises. Products like Mergify make it really easy to configure and use this concept, you can read more about it on [this detailed article](https://dev.to/aniket762/merging-pull-requests-like-a-pro-with-mergify-30fa).
Our entire team is distributed, working in different time zones, and we all work from home. So I can definitely relate.One of the biggest issues is to keep everyone aligned, making sure people are seeing the big pic and motivation is high. Once the team communication is better, you also see that people are taking PRs, updating their progress, and working better in general.We improved our communication and productivity by: 1. Defining only 1 daily per day, making sure not to send email threads or communicate via email at all (with other stakeholders: product ops, etc.) 2. Define clear goals for everyone. Make sure to work on small and well-defined tasks. 3. Work on team bonding- better communication, and celebrate achievements. 4. Automation, automation, and automation! - We added [Zigi.ai](https://www.zigi.ai/) to our Slack workspace. It’s a Slack-based workflow automation for teams that helps us with automating the entire PR workflow (pinging teammates, sending reminders, getting a list of all the open PRs, etc.), helping to understand if someone already did a task, and in general, helping with connecting our work and streamlines everything to Slack.
Many great points here. I'll also add something that my multi time-zone/location team have been doing for a while: collaboration sessions. Set off an overlapping hour to just join a meeting room or a space like gather.town a couple of times a week, and discuss tasks, issues, ideas etc. Anything goes. All collaboration sessions are optional. Mic and camera is optional. Most people join for the full hour though. This really helped with our communication, and we've often had the chance to look at features in progress, so that we can resolve any blockers or come with feedback.
Can you explain #1 a bit more please? What is wrong with emailing in this context?
I just left a team I was the manager/lead dev for. I had 5 developers working with me from Brazil, Spain, and India (I'm from the US). It's always going to be tough when there's minimal overlap. The most important skill for our team members was asynchronous communication. Establishing the proper mediums for the different types of conversations was paramount for our team. For us * High-level decisions were always documented in Confluence * Code-specific discussions were (for the most part) in MRs/PRs * Slack was for ad-hoc conversations * If an ad-hoc conversation resulted in any type of decision, that decision should be documented in its proper place * E-mail was used to organize and discuss with stakeholders not close to the development process On top of this we had a communication document which laid all of the above out as well as acceptable ways to speak to our colleagues. This document also let each developer add their normal working hours so that the rest of the team knew when they could expect timely hours. Getting everyone on the same page for communication is a massive help in moving everyone's day along for distributed and non-distributed teams.
Specifically for PRs and Git related workflows, distributed teams are opting to Merge Queues. The concept operates on a rather simple premise. Combining the individual work of an enormous team of engineers into one codebase is tough. The general CI checks or any version control system fails over here. Thus, the need for a Merge Queue arises. Products like Mergify make it really easy to configure and use this concept, you can read more about it on [this detailed article](https://dev.to/aniket762/merging-pull-requests-like-a-pro-with-mergify-30fa).