Is your global team sustainable? A case study in optimizing work-life balance in geo-distributed product teams

Sanika Mokashi at UXDX Community: Building Balanced, Research-Driven Product Teams. Video: https://youtu.be/H6s-pBDtkrQ

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Why work-life balance across time zones became a problem

[00:00:07] Today I'm going to be presenting a case study on how you could optimize work-life balance in geo-distributed product teams. A quick introduction: I'm Sanika, and I've worked at Nutanix in the US design team for almost 10 years now. I joined when the team was just a few people in San Jose, and over the years I've seen it grow to almost 80 people across multiple continents.

[00:00:32] In my personal life I am a mom of two energetic little boys. My day job is UX design, and this work on cross-geo collaboration is just something that is an initiative I took up over the years. Because I started noticing that meetings outside of work hours started to impact our team effectiveness and morale. And so making sure that we have a sustainable, high-functioning team has since become an area of deep interest for me.

[00:01:02] I will start with some recent stats that I have seen from a survey from Bapper [?]. Here you can see that almost 75% of people said that their company operates in multiple time zones, and we live in a global world. What's interesting is that 62% said that not just their company, but their immediate teams, whom they regularly collaborate with, are actually also distributed across multiple time zones. And this has certainly been true for us at Nutanix as we have grown over the years.

[00:01:28] This is what collaboration looks like for us. We have our core team HQ in San Jose. Then we have a big team in Bangalore. And we also have a few team members in Berlin. And for good measure, we also have people dispersed over other areas as well: we have one person in Australia, a few people in other places in the US. So you can imagine this kind of geo-distributed team collaborating across time zones.

[00:01:59] When time zones collide, you get scenarios like this. Imagine one team member who is scrambling to finish dinner to get on a call, and another who hasn't even had their morning coffee yet. Or one person is missing their regular morning routine two days a week to connect with a teammate who is on the other side of the world, who is in turn missing bedtime with their kids. And so I realized that this was starting to come up more and more in informal discussions, and people were feeling this. This was starting to become a problem for our team.

Empathizing: the survey and what it showed

[00:02:29] What do we do? Well, we're the design team after all. So we decided to apply design thinking to this problem. We started with the first step, empathize, which means we really wanted to understand this problem deeply. Is it something that was mostly affecting people in one geography, or all of them? We wanted to understand the extent of this problem. And so we planned a survey which captured a bunch of these different kinds of details, and also free-form inputs from people all across our team.

[00:03:03] The results were quite illuminating. Clearly this was a problem. What you see on this chart here is the number of people from each geography, and overall, who said how much their home and personal lives were disrupted by meetings that took place after hours, outside of the regular eight to five times that we usually have in the office. You can see here that almost 75% of our overall team said that their personal life was at least somewhat disrupted, which is a four or more on our seven point scale, because of these meetings across time zones.

[00:03:40] I'll give another quick example of the kind of data we collected. We tried to capture when meetings start earliest and when they end for different people in different time zones. There were people who were taking meetings as early as 6:00 am and 6:30 am. There were people who were attending meetings as late as 11:00 pm and 11:30 pm at night. And sometimes this might be the same person. So clearly this was not very sustainable.

[00:04:05] There was a lot of other data that we collected, but I'm just going to highlight a couple of quotes which really reflect the overall sentiment of the feedback that we received. One key thing was that people just really wanted clear guidance; they wanted clear expectations from the design leadership. Another one was that there was this uneasy sense that not all geos are being treated equally. And the third one was that scheduling meetings was really hard because we're across three time zones. The only convenient time that everyone can meet at a reasonable hour is this 7 to 9:00 am slot in the US time zone, and those slots fill up really quickly. So there is no time to do meetings, and things keep getting pushed out.

Defining the problem and the guiding principles

[00:04:54] Armed with all of this rich data, we set out to clearly define the problem statement. Number zero is that there were just too many meetings, and we realized people were getting burned out with these meetings that were happening after hours. But the other three problems that we clearly defined from all of this data were, one, the lack of clear expectations, both in terms of the volume of meetings, the timings, and how to deal with different kinds of tricky situations and scenarios. We also realized that scheduling meetings is getting hard and we needed to do something about it. And a third important insight was that cultural expectations differ in different geographies, and I'll talk a little bit more about this as we go further in.

[00:05:37] With a clear problem statement, we got into our ideation phase. We conducted multiple brainstorming sessions, first in smaller groups and then larger sessions with these geos, to brainstorm and refine the plan and to make sure we are solving the problem in the right way.

[00:05:56] There were four main guiding principles that we followed when we came up with our eventual guidelines. The number one thing, which is obvious, is that we wanted to create these guidelines in a way that enables people to establish boundaries and maintain appropriate work-life balance. This is very important, as it's the basis of everything that we did. The second was that we wanted to provide very clear guidelines and set the right expectations throughout.

[00:06:27] The third really important thing was that we were all in this together. We wanted to make sure the guidelines reflected that all of the different geographies would share this burden equally. And then, of course, in coming up with these guidelines, we wanted to be sure that we took cultural norms into account. For example, people in San Jose might be okay with taking a 9:00 pm meeting after dinner is done, but for India we realized that that was peak dinner time, and people really did not want to be disrupted at 9:00 pm. So we took some of these kinds of things into account when coming up with our final setup.

Setting expectations for cross-geo collaboration

[00:07:03] Now that we had a clear goal of what we want to achieve, we came up with the first version of the cross-geo communication guidelines. I'll walk you through some of the key recommendations, why we made them, what the thought process was, and what we've found to be useful, and I'll share some practical tips as we go along.

[00:07:25] First and foremost is this understanding that we are a cross-geo company. We have teams in different places. And so some non-zero amount of collaboration needs to happen outside of working hours. This is just an expectation that we wanted to set with the team. But even more than just saying there is going to be something non-zero, the design leadership and executive team came up with very clear guidelines in terms of how many hours you should expect to spend on collaboration with other geos, taking meetings outside of the core nine to five. This was different based on the level of each team member.

[00:08:02] If you're a more junior IC, you would typically be working with others in your own time zone, and you might have a little bit of cross-collaboration. If you're a lead, you're probably working with multiple teams across time zones, so that goes up, and if you're a manager, it goes up even more. We came up with these guidelines, and what that ensured was that people now have a clear understanding of what the expectation was. Which also means that if they were exceeding that, they clearly know what to do. It made it easier for them to bring this up with their peers and with their manager and have this conversation: hey, this is going far beyond what we've decided as a team, and we need to figure out mitigation strategies.

Async communication principles

[00:08:44] Next, we shared specific things we could do to simply reduce the overall need for meetings by improving how we are communicating. And beyond replacing meetings, I think async communication is something that needs to become a core part of the culture. It's how creativity can travel across time zones. Here are a few principles we shared with people in terms of communicating.

[00:09:06] The first one is just share your work. Don't wait for a meeting. Don't wait to be able to schedule the meeting three days out just to share some quick design work you've been doing and get some feedback. So we shared some strategies about how to share your work in an async way. The other important thing with async is you want to make sure that what you share is designed for clarity and action. It should be very easy for the person you are sharing it with to know what exactly you are sharing and what your question is.

[00:09:34] A side effect of this is that it brings a lot more clarity of thought when we're going through a design process. Because now you have to think clearly about it: this is what I'm sharing and this is what I want people to answer. You can't rely on the ad hoc meeting where we'll just hash it out. You have to think more clearly about what your goals are.

[00:09:58] A third and really important thing is that when sharing things, you want to keep everything visible and centralized. What I mean is, this is probably something a lot of you have experienced. There is something in Notion. There are a dozen Slack channels and DMs. There's something going on in an email thread. And once you have these multiple different channels where things are being discussed, it becomes really hard, especially if your company is remote, to keep on top of things, know what the latest decisions are, know what exactly is going on.

[00:10:29] And the fourth one is a more meta one, which is knowing when to use meetings intentionally versus when async communication would work better, and I'll give some examples of that as we go forward.

Practical async tips

[00:10:43] Here are some practical tips that have really worked for us. Don't wait for a meeting; just share something quick. Sharing just your design file is often not very helpful, especially for other cross-functional team members. PMs and engineers find it very hard to provide feedback that way. So record a quick video walkthrough on Loom. Just have a quick voiceover so that people know exactly what you're sharing and what kind of feedback you're looking for.

[00:11:10] Another thing: we are designers, so there's a lot of brainstorming and collaboration we do. What we started doing was to set up an async brainstorm first in Figma and have it open for a little bit. Then the meeting organizer would go in and collate things, and then we would do a live session to hash it out. This is where we're leveraging async communication to make live meetings more effective, and also to reduce the amount of time we spend on these meetings, which often happen late at night and super early in the morning.

[00:11:39] Then centralizing feedback, and I will give an example of something that has worked really well. In our team there is a temporary Slack channel that gets created for a release. We have long release cycles; I'm in an enterprise company. But there is one Slack channel that gets created for a release and for a feature. If you are working on that feature, you are in the channel, and it is expected that any updates, any communication, even if you have updated something somewhere else, or if there's an email thread, gets summarized in that Slack channel. And everybody knows this.

[00:12:09] That makes it more straightforward for people to know: okay, this is where I go and this is where I get all of my updated information. And now some of these AI summarization tools, like we have Glean [?], can help summarize long threads and things like that. That really helps us keep on top of things.

[00:12:26] Another tip that has really worked well is just sending end of day updates. If I'm collaborating with someone in Bangalore, right before I wrap up my work day, I will write a short paragraph of what has happened during the day, any updates, anything that my collaborators in India should know, and I just send a quick update. So once they come online in their morning, they know exactly what's going on, they are up to date, and we don't spend a 24-hour cycle of going back and forth on questions and answers.

[00:12:56] And the last tip I have for you is scheduling messages, and I've had a lot of success with this. Slack lets you schedule messages very well. Slack even tells you what time zone the other person is in and what time it is for them, which makes it really easy. If I have something that I need to share with someone in India, but it's 2 pm for me and it's 2:30 at night for them, I will schedule it for when they will come online. That way they actually get to see the messages when they are likely to be in front of their laptop.

When cross-geo meetings are worth it

[00:13:29] Now, coming back to when you actually do need cross-geo meetings, when they are actually helpful and you can't just rely on async, recording things and sharing them. There are a few areas where we have found meetings, even if we have to do them across time zones, to be really, really valuable, and I'll talk a little bit about that.

[00:13:48] One is having a global design all-hands. Everyone across all of our different geos will tune in. This happens once a month, and we find this is very important for everyone to keep up with what's going on across the design team. We make sure that this meeting is collaborative and very interactive. People will ask questions in chat. There are a lot of things going on. It's not just one person talking.

[00:14:13] Then we do some UX strategy reviews, and this is another area where we found it important to have these face-to-face Zoom conversations rather than everything being async. This is where a core group of more senior design leadership will meet once a week or once in two weeks to review really important areas of our UX strategy and make sure that we're doing the right things. There are other things managers need to sync up on regularly, and that becomes important.

[00:14:43] The last one is doing one-on-ones to build trust with team members who are in different geos. This has an interesting downstream effect, because once you build trust, further communication can be more effective. You build that trust, and now you know how to interact with that person, so that initial investment actually pays out quite a bit.

Meeting hygiene

[00:15:06] The other thing that we shared in the guidelines is meeting hygiene, and this is really important. This is still about when you have cross-geo meetings, but what it ensures is that those meetings are effective. You don't get stuck in a cycle of, hey, we just talked for an hour and we still don't know what the next step is. Good meeting hygiene reduces the amount of cross-geo meetings overall. There are a few things that we have started following very diligently.

[00:15:32] One is that the meeting organizer is always expected to share the agenda and the goals of the meeting, what the expected outcome of the meeting is, in advance. The other one is that there has to be at least a 24 hour heads up for scheduling and canceling these cross-geo meetings which happen outside of regular work hours. Because you don't want to wake up and realize that someone just scheduled a meeting overnight while you were sleeping and now you have to be on in 2 minutes. Or, on the other hand, you cleared your entire personal schedule for the evening and then you realize 15 minutes before the meeting time that it's been canceled for some other reason.

[00:16:11] The third important thing is coming prepared to meetings. We haven't gone quite as far as the Amazon model of having a memo and everyone reading it, but we've become a little bit better in terms of how prepared the organizer is: what exactly we need to share, what the expected outcomes are, and things like that. And then we diligently follow up with meeting recordings. Again, AI makes this really easy, because now you can also share an AI summary of the meeting. We share notes and action items, and tag the people who need to take things up.

Green, yellow and red zones

[00:16:43] Now we come to the most important part of our cross-geo meeting guidance, and this is the one that has made among the biggest impact of everything that we have done so far. This is where we lay down clear boundaries about what time is reasonable and unreasonable to schedule meetings with other people. We don't want someone to schedule a meeting with you when it's 11:00 pm for you. And along with that there are a few other follow-up things we wanted to make known, like when do we have global team meetings, and what do we do when it's standard time versus daylight saving time. Because India does not follow daylight saving, and so the time difference changes. And of course weekends, and that there is no expectation that you take meetings outside of your core working hours then.

[00:17:30] What we did was come up with this kind of model where we had green, yellow and red zones. Red zones mean do not schedule the meeting. You don't want to be scheduling a meeting in the middle of the night when people are sleeping. But we also made sure that this was equitable, and every region had a clearly defined green zone, a couple of yellow zones, and then red zones to protect the most important time.

[00:17:58] We also made sure there was a slot where all three geos could talk together. You can see this is between the 8:00 am to 9:00 am slot, and for anyone who's tuning in, thank you for taking time out of this really packed slot where we have a lot of meetings. We made sure that there is a slot where all three geos could collaborate on things together, but also individual slots where some people could talk just to Bangalore, or some people could talk to Berlin, and things like that.

[00:18:28] This is for daylight saving time, and then things get a little bit different when you go to standard time, because now India is one hour further; the difference changes a little bit. What works in the summer doesn't really work once it becomes winter, and so we had a slightly different model for that.

[00:18:44] Once we had this, we of course shared it with everyone and made sure they know when and how to schedule meetings. But then each of us individually went in and updated our Outlook calendars to reflect this. I have a block on my calendar which says, "I'm sleeping, don't schedule meetings at this time." This has worked really well for us, because now the expectations are clear: this is when you can schedule meetings freely, but these are times when you absolutely shouldn't. And I will go through some scenarios we shared with people in case things go differently.

Scenarios for tricky situations

[00:19:20] The last part I want to go through in terms of guidelines is how we shared some examples of specific scenarios people might encounter. This was really helpful, especially for the more junior team members, to know what to do when something happens that they're a little unsure about. Let's say someone in your design team sets up a recurring meeting and it's in one of your red blocks: ask them to reschedule. If you're not comfortable doing that, if it's someone very senior, someone you don't have a good rapport with, feel free to ask your manager for help. If it's a wide meeting, a team-wide meeting or even wider, figure out if your presence is necessary or if it's just an FYI for you, and then ask them to record it and send you the notes.

[00:20:00] Another fun, interesting thing we did was a flowchart of what happens if a single meeting is set up. You figure out: is your input required? No? Then just ask for recordings. But if your input is required, does it need to be live? Can it be async? We shared these and a bunch more scenarios with the design team to help them in their decision-making process about how to go about meetings that get scheduled.

Testing and iterating: follow-up surveys

[00:20:26] With these guidelines in place, we went into our test and iterate phase. We implemented these guidelines, and then about a year later we did a follow-up survey. Things had improved. There's one example here, and there is a bunch of other stuff which I probably won't share today, but I just wanted to highlight this. Remember how we said earlier that there were... [unclear in captions] ...substantially.

[00:20:58] Things were helping. We also captured in the survey what was actually working and what was not working. This is just one snippet of that kind of information. We captured that async and better notes and recordings were actually helping quite a bit. But we have a no Friday meeting policy, and that was not really being implemented. So we knew what was working and what was not working, and this helped us iterate further.

[00:21:23] Another thing I want to highlight is that there was a big intangible benefit to this effort. Just doing this made people more comfortable talking about cross-geo meetings and made it easier for them to speak up. It also made the team feel more empowered and feel like they are a part of the solution. That really helps, and people are taking initiative and trying to figure out how to make sure their own schedule is sustainable and working for them.

[00:21:49] With that we went into our iterate mode. I just shared data about the two surveys, but since then we've done three more, so we've done a total of five surveys so far, about every nine to 12 months. As we move forward, other things come up. For example, return to office happened for us a couple of years ago, and so we captured details about how that impacts cross-geo meetings and being able to drive into the office. We realized that our scores went down at a certain point, and we noticed that this was because it was a critical product launch time for us.

[00:22:21] There are these peak meeting periods which happen, and we started capturing data about that. I'll give a quick example. We had set expected ranges of maximum cross-geo meetings. Now we capture, in an average non-peak time, how many do you have, and obviously anyone who is above that, we would follow up and figure out what's going on. But then we also capture data about times when the volume of meetings is more than average due to events like upcoming product launches or other things that are going on.

[00:22:58] We capture information about how many people are within the lower bound of the expected range, the upper bound, people who are slightly above, and then people who are more above the expected range. This helps us figure out which guidelines were working, which specific areas and which specific product teams might need more help, and we went on iterating from there.

Conclusion

[00:23:20] With that I would like to conclude and just say that work-life balance is an evolving design challenge. It's not like this is done. We continue to benchmark, we continue to improve. One key learning for us was that as a design team, we are part of multiple different product teams. We work with engineering and PM teams from multiple different products, and we are working on multiple different products. This makes it especially harder for designers.

[00:23:47] So we are now working on getting these kinds of guidelines adopted across other teams. Because it's helpful if we follow this practice within the design team, but it's not fully helpful unless everyone you collaborate with is also on the same page about some of these things. Those are the things we have going on, and those were some examples of what has worked for us. With that, I would like to conclude. Thank you so much, and thank you for this opportunity. Please do let me know if you have any questions.

Q&A

[00:24:23] Host: Two seconds. Fantastic, we had a lot of questions. When people cancel last-minute meetings, it's been really a big issue for us. Yes, I heard you. I think it's also respecting people's organizations. I love clean-up meetings, actually. Lovely. That touched on the majority of the questions. Then I want to go back to earlier questions around team size: a really good team size for ideating.

[00:25:19] Sanika: For this particular case, we started with the brainstorming and the ideation process in smaller groups, just three to four designers, locally, brainstorming about this. Then once we had an initial idea of the direction, we opened it up to our entire team, across locations. The reason for this was mainly to understand and get inputs on the cultural expectations and individual experiences that people have. So I would say, for initial ideation and brainstorming, not more than three to five people. And then once you have a structure in place, it can be 20, 25 people, but you have to have a good structure in place at that point.

[00:26:01] Host: It's really worth knowing. Many work outside nine to five with international teams and clients. This is more of a statement than anything else. I guess, what is the hardest thing about working with globally distributed teams?

[00:26:24] Sanika: It's hard to pick one thing that is the hardest, but I think last-minute meetings and cancellations have been the biggest topic that we keep seeing come up in every survey. That, alongside the sentiment of: how do I even schedule the meeting? There are no slots for everyone I need to attend this meeting, so clearly I need to figure out a better way. I think those are the two biggest things which people really feel strongly about, from what we have seen in our team so far.

[00:26:52] Host: [Question largely inaudible in captions, about teams spanning the globe, different structures, meetings, and whether there was pushback.] What was the pushback? I love the base time, by the way: here's your expectation, so we all know what the expectation is.

[00:27:57] Sanika: I think laying out that expectation clearly made a big difference, because up until then things were just very ambiguous. The more junior and the more introverted people would just go along with whatever, and the people who've maybe been around longer, or people who are more vocal, would be more okay with pushing back. Laying out this expectation really helped with that.

[00:28:21] The pushback we have seen is more along the lines of: we have the 8:00 am slot for San Jose, or the 10 pm to 11 pm slot which is still yellow for Bangalore. That's something we arrived at with consensus within the team. But even these individual teams are large. The San Jose team is about 30 people. The Bangalore team is even larger. So clearly this is not going to work for everyone in the team. There are some people for whom these slots are just inconvenient. Maybe it's someone in San Jose who needs to do a school drop-off every morning at 8:00, and so it's really hard. And there are people in Bangalore who are like, I am an early bird, I get to the office super early, and this is very inconvenient for me.

[00:29:05] We've received that kind of feedback, and we keep taking it into account and trying to figure out what to do. But in terms of structure, we still need some structure, and within that structure there is now a lot of leeway for people. If you're doing a one-on-one, feel free to do it at a time that's more convenient for you. But if there is a critical product-team-wide meeting that's going to happen, we all need to make sure there's something that works for all of us.

[00:29:32] One thing I also want to highlight in terms of pushback, and this is where the peak time versus average time came into the picture: the pushback was, these last few weeks have been really crazy, every night I have had meetings or every early morning I have had meetings. That's when we realized that there are these crunch times that we really need to address and make a big improvement on. A lot of our effort in the more recent few months has been figuring out what exactly happens during these crunch times, and how we can frontload the work that happens there. Not just meetings, but more structural, more fundamental changes that we make in order to address that kind of pushback.

[00:30:21] Host: About the initial getting agreement on guidelines globally, in places like Berlin and the US: when you say agreement, what exactly... I guess when you talk about culture... how did you get cultural agreement? The initial stage of that agreement, the front part with those three to five people, versus the latter part?

[00:31:02] Sanika: With the three to five people, we had an initial idea of what things should be there. For example, initially we started with making the 8:00 pm to 9:00 pm slot also available for Bangalore, or something like that. But then we realized people in Bangalore actually preferred to have dinner during that time, and that is the feedback that we received from the team. So before making any of this official, after that initial brainstorming, we did individual sessions, almost like design critiques, with each geo. We shared some of the proposals with them and got feedback on this and many other things: the exact time slots, and some of the other guidelines that we have in place.

[00:31:46] That helped get more buy-in, because these people could make sure that their voice was heard and they could vote on things. For example, Bangalore voted on having it from 10 to 11 pm rather than starting earlier at 8:30 or 8:00 pm, because again, the culture there is a little bit different. Telling that, and just knowing that we are all in this together and that we are trying to build a system that is fair across all of the geographies. I think those two things.

[00:32:13] Host: Fantastic, that was amazing, thank you, really. I think even outside product. Thank you for sharing.

[00:32:22] Sanika: Thank you.

[00:32:26] Host: And we will see you again. Thank you, everyone, for joining in.

[00:32:29] Sanika: Thank you for this opportunity.