How To Keep Meets Inclusive in Global Remote Teams

At Float, we're a fully remote and globally distributed team. We have team members all over the world and across multiple time zones. It's almost certainly the case that at any hour during the day, at least one team member is working their regular hours.

However, our team is far from evenly distributed.

There are hotspots where many colleagues are around the same time zones and other areas far more sparsely populated. In particular, this has interesting consequences for our engineering department and our interactions with the product team. By historical accident, most of our engineering department lives in Europe with a few others in the Americas or the Asia-Pacific regions. However, the product team is primarily based in the Asia-Pacific region.

Recognizing a less than ideal state

For a product-centered company such as Float, the relationship between the product team and the engineering team is, arguably, the most important within the company. Ensuring we are building the right features and supporting and maintaining our existing offering is critical to the product's continued success and Float itself.

In a traditional on-site company, it would be trivially straightforward to get a shared understanding of priorities and have the necessary meetings to thrash out those upcoming priorities for the forthcoming period. However, this is far less straightforward in an off-site (aka fully remote) company, although arguably even more critical.

When I joined Float in the latter half of 2021 there was a weekly call set up with 18 attendees that acted as a progress check on the current feature cycle or for technical debt/catchup cycles. It was an opportunity to plan upcoming features, ticket assignments, and post-launch actions. The whole engineering department was invited along with the product department—including product managers, designers, and our QA team.

It took place at 11 p.m. U.K. time. As a result, most of the engineering department logged into the meeting in the middle of the night (it was very noticeable how dark it was from their Zoom backgrounds). And it made me uneasy having a critical meeting at such an unfriendly time.

The impact on team culture

When thinking about meeting times, it's essential to consider the implications for individuals who attend and those who don't attend a given call.

Individual team members can and will feel pressured to go along with the team to create a good impression, particularly when new to that team. However, there is a genuine danger of resentment building, let alone the lack of proper rest and recovery that time away provides.

It is also worth considering the damage that calendars fragmented by multiple meetings in any given day can have. It becomes far more of a challenge to get into a focused state when there’s no real deep work time between meetings. As a result, work done tends to be shallow or mundane rather than meaningful and impactful. There's a higher likelihood of being distracted and losing attention to other things too. And even worse, your team might start slowly resenting each other for all the unnecessary interruptions in their day, preventing them from living their best work life.

Deciding to make a change

Fortunately, we are committed to questioning the status quo at Float, and our founders aren't afraid to change things up when necessary. When I put the case that it would be more inclusive (and fairer) to replace that meeting with something more asynchronous, it was readily accepted.

There were several other reasons for removing that meeting, although the trigger was the time zones. It was also starting to get too large—18 attendees is a lot! Plus, we were getting to the point where parallel development cycles made the most sense, so it was likely that half the attendees wouldn't have context on what the other half was doing anyway. Lastly, it was eating into people's sleep, resulting in a sluggish, less energetic, and less sharp team, which isn't how we want to be functioning.

We did already have a pattern for splitting this kind of call as we have weekly engineering check-ins which alternate their time so that everyone in theory has one they can attend every other week. But in this case we went a step further and cut that whole weekly meeting from our calendars.

When meetings have to happen

This goes to our overall philosophy of being very strict about what meetings we have—in particular, those that are recurring.

We want our team to be able to make the decisions for themselves on how to spend their time during the day, and having set anchor points in the form of meetings can severely curtail the flexibility we strongly believe in. It's one thing to say that provided you get the work done, we don't care how you structure your day, and quite another to apply a liberal sprinkling of meetings throughout the week that act as constraints on the very freedom we espouse.

In particular, for our engineering department, I'm very keen to allow people to self-organize and lean into more spontaneous calls where it is convenient and makes sense, using textual updates by default or even sharing short video updates where something benefits more from the visual stimulus. I believe that most of the engineering team should only have one scheduled meeting each week (one week will be a regular one-to-one check-in with me, and the next will be the engineering team check-in).

Take a careful approach to have more inclusive meetings

Despite all this, meetings have their place. Here are some recommendations to help you make the most of your team’s time and get more out of your meetings:

• Consider recording them, and having attendance be genuinely optional
• Allow people to provide any updates asynchronously, for example in a shared document or via pre-recorded video
• Consider rotating the time of any critical meetings so that everyone gets a chance to attend at a convenient time, and if they do feel they need to participate at an awkward time, it at least occurs relatively rarely

My biggest recommendation, however, would be to analyze what the purpose and outcomes of each recurring meeting should be. And if these aren't clear or it becomes obvious these are more about reporting progress than actual discussion and decision making, that meeting is a prime candidate to move to something more asynchronous!