Working as a reliable and productive remote team is achievable when you have the right processes in place. But because your team is remote, engineering team meetings are all the more important to get right.
When you can’t rely on in-person physical and social cues during meetings (or bumping into people in the hallways and getting a sudden reminder that you need to discuss something), you need to make sure that best practices are followed to get the most out of everyone’s time.
Whether it’s deciding on meeting cycles, sharing the burden of asynchronous communications, or figuring out how to make Agile practices work for your team, there’s plenty of value in considering how to tailor processes for your unique circumstances.
Fortunately, a number of other people have already done the hard work experimenting with these processes, and shared their experiences and recommendations of best practices.
Today we’re covering exactly what those best practices are, so that remote meetings for your engineering team go as smoothly (and productively!) as possible.
Looking for top talent fast? See how Arc can help you:
⚡️ Find developers, designers, marketers, and more
⚡️ Freelance or full-time remote + fully vetted
⚡️ Save up to 58% with global hires
Hire top talent with Arc risk-free →
1. Have a Reliable Technology Setup
One of the most important things to get right for remote meetings is a reliable tech solution so everyone can come together to discuss work. This means everyone involved in the meeting needs a reliable enough network connection to keep up, and reminders set in their calendars that they’ll receive and follow.
This may be done (preferably) by video conferencing, but otherwise by audio conferencing, with the ability to screen share, make notes, draw on the screen, etc. There are plenty of options on the market (Zoom, Microsoft Teams, etc.), so the team can easily test out and find a solution that works for them.
It can pay to have a solution that also works easily for mobile, so even team members who may not be “on shift” can be involved if necessary.
Read More: On-Site vs Remote vs Distributed Engineering Teams: How to Choose?
2. Choose Appropriate Meeting Cycles
Agile for remote work
Agile is a software methodology framework that uses an incremental, iterative approach to deliver software products with fewer bugs and integration issues, on more achievable timelines than traditional “all at once” software deliveries.
The Agile project management framework focuses on team communication, with regular meetings. Originally, Agile was designed for co-located teams, so can it work for remote teams?
For the Agile approach to function effectively in a remote work context, the right communication tools need to be put in place. Without smooth and effective communication, Agile simply doesn’t work. It’s also recommended that you have an experienced Agile practitioner, such as a Certified Scrum Master, to be able to run typical Agile meetings with maximum effectiveness.
Aside from communication tools, the content of communications needs to be written in a way that can be understood by everyone. If there are shared definitions, the need to be in writing, and accessible to/agreed-on by everyone. What is the team’s definition of done? Everyone should know.
If the team also has asynchronous team members, it is particularly important to share the burden of communication fairly. Just because most team members are in one timezone, it’s unfair to always make one or two people take meetings at an inconvenient time of night. Share the timezone load (and help build empathy in your team for cross-timezone communication)!
The takeaway? Agile can work for remote teams as long as the company completely embraces the fact that it is a distributed team. Build processes and communications from a remote-first perspective, ensure the team culture is open and respectful, and good things will come.
Daily standups
Standups are a brief, 15-minute catch-up with the whole team — generally at the start of the day — to see how everyone is going with their work and what they are currently doing. It can be a time for a quick update about a problem that needs solving (and finding another team member who can help), new info from a client, urgent security patches, etc.
That said, figure out what works best for your team. The distributed team at HelpScout, for example, has ditched the daily standup meeting in favor of a daily Slack channel update from each engineer covering:
- What have they done since yesterday’s update?
- What do they plan on doing before the next update?
- Is there anything blocking them?
But the HelpScout team do still have meetings. In particular, they have kept the practice of a video meeting for the post-sprint retrospective (see below).
Read More: Why Employee Development is Good for Business and Your Dev Team
End of sprint meetings
Development tasks are broken down into small pieces that are due for completion at the end of a ‘sprint,’ which is typically 1-2 weeks long.
In an end of sprint meeting (or “retrospective”), each team member will give an update on what they have achieved, what didn’t go as planned, and how they can improve estimations/processes/skills to do better.
Once the wrap-up is complete, the next sprint can be planned, including distribution of tasks and responsibilities, backlog (re)assignment, etc.
Weekly updates with managers
In general, thought should be given to who is invited to meetings. For example, it’s not required that the project manager sit in on all team meetings, as it is expected that many of these will be of a technical nature.
Instead, a weekly update between the team lead and the project manager may be enough to ensure things are going smoothly. It’s recommended that project managers sit in on end-of-sprint meetings, too, to understand what is happening from a technical perspective.
Read More: How to Manage Developers on a Remote Engineering Team
Monthly project meetings with all stakeholders
Having a monthly meeting with everyone involved in the project — the team lead(s), project (and other) managers, and/or stakeholders — will give a good idea of how much has been accomplished within a month and what other issues have come up from a business perspective.
This meeting should focus less on the technical aspects of the project, and more on everyone reporting “big picture” progress.
You can also try Arc, your shortcut to the world’s best remote talent:
⚡️ Access 350,000 top developers, designers, and marketers
⚡️ Vetted and ready to interview
⚡️ Freelance or full-time
Try Arc and hire top talent now →
3. Take Time Zones Into Account
Is your team working within the same time zone or split (asynchronous)? If there is a split, then you may need to do daily handover meetings.
Firstly, it is beneficial to have a visual representation of which timezones everyone is working across, with names and color codes for the team(s) and/or team roles. This way everyone can see where there is overlap if they want to chat with someone in particular.
A daily handover meeting between asynchronous team members can help to ensure things go smoothly. This may be just a quick 10-15 minute talk to identify any issues/completions so teams can hit the ground running and continue to work on critical issues.
4. Have Dedicated Meeting Roles
Without clear, coordinated, and documented meetings, you may find that the same issues keep occurring meeting after meeting — or people forget what they are supposed to be doing.
Having clearly assigned (and followed) meeting roles will reduce this risk. Examples of these are leader/facilitator, scribe, time-keeper, and participant. Meeting roles can be rotated if desired, to give everyone the opportunity to learn different roles. The crucial thing is that there is no ambiguity to the roles: everyone in the meeting should know who is contributing ideas, and who holds the power to make the final decision.
An example decision-making model used in remote engineering team meetings is DACI. This model is optimized for speed and clarity of decisions. Used by Zapier, and other distributed companies, “DACI” refers to four distinct roles: Driver, Approver, Contributor, and Informed.
- The Driver manages the meetings (but does not have approval authority)
- Approver(s) have the final say on decisions
- Contributors are consulted for their (unique) opinions
- Informed are not directly involved, and have no decision authority, but are kept updated
Remember that for remote teams, meeting documentation is key. Ensure that someone is in charge of setting meetings, and also in charge of distributing the agenda in advance, as well as the meeting notes afterwards. This information should be available to all who need to see it.
Read More: How Data Science Managers Can Effectively Lead the Team to Production
5. Have Agendas, Clear Meeting Structures, and Set Times
Free-form meetings are best left for the amateurs. Even if the team is doing a brainstorming session, have some rules in place, e.g. a specified documenter, not spending too long on each idea, an end time for the meeting, etc. Always have a set list of rules for your meetings.
Different meeting types will have different structures, agendas, and timing configurations, but these always need to be in place before a meeting is held.
Making sure everyone on the team is aware of the rules beforehand can prevent issues like one participant taking up half the meeting time talking, while others sit and wonder what they need to collect from the grocery store.
6. Review and Update Meeting Processes
Over time, you may notice that your meeting practices need tweaking for them to be more productive and efficient. As with any business process, if it is no longer efficiently serving its goal, updating it is well worth the time investment.
Rather than waiting for problems to arise, it is worth checking in with your team about these processes a couple of times per year. Simple, elegant processes are always best — and often these arise from natural solutions (then get refined). The best processes, however, are the ones that are written and crystal clear. This is even more important for remote teams.
Read More: How to Objectively Measure Software Developer Productivity
7. Know When Decisions Should be Made
One of Amazon’s key principles is the bias for action. What is a bias for action?
Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.
Amazon
This means making decisions now, perhaps even when we aren’t fully aware of what the outcome might lead to. It’s risk-taking in business.
Now, calculated risk-taking, particularly in a dev team environment, is best left to the most experienced team members. In some cases, it will be the person most familiar with a particular framework; in other cases, it will be those who’ve worked in a particular industry for the longest amount of time. Sometimes, however, it’s just the person with the best social skills, if you’re talking about how to break some news to a shareholder.
It’s not always necessary to have a bias for action. You don’t need to make a decision now when tasks aren’t so time-critical, or the pipeline is a little slow. In these cases, there’s more time to do research and recon, check analysis tools, and model predictions. Knowing when you need to make a move is sometimes just as important as the move itself.
8. Empower Your Team to Move Forward
That said, particularly when working remotely (and even more so when working asynchronously), it’s important to trust your team members and empower them to move forward with projects.
As noted by Andreas Klinger, Head of Remote at AngelList, “People are fast and capable unless they are blocked”. He states that autonomy and abandonment are different — working remotely isn’t about isolation, but about “avoiding unneeded inter-dependencies and blocking.”
The take-home? Trust in your team, establish good decision-making processes, make information available to those who need it, and empower remote team members to keep working.
Having team members unnecessarily blocked while they wait for a decision is a frustrating waste of resources. Save putting off making decisions for when it really counts!
Read More: The Journey to Product-Market Fit: From POC to MVP to Prototype to PMF
Wrapping Up
Running meetings for remote engineering teams is a learned skill, and one that’s definitely worth learning! While your company may have used the flexibility of being a distributed team to assemble a team of superstars… none of that matters if they can’t work together.
Decide on the right communication tools and techniques, agree on your meeting cycles, and remember to empower people to keep themselves working (and also know the limits of their authority).
With this approach, your team can sidestep the challenges of not being co-located, and stay productive.
You can also try Arc, your shortcut to the world’s best remote talent:
⚡️ Access 350,000 top developers, designers, and marketers
⚡️ Vetted and ready to interview
⚡️ Freelance or full-time
