This blog post was co-written by Allison Wu and Heddy Stern.
Since our teams at VMware Tanzu Labs (formerly Pivotal Labs) moved en masse out of physical offices almost three years ago, our thinking around remote and hybrid work has changed from it being a temporary stopgap measure to a permanent shift that needs investment and improvement. Being on Zoom all day is exhausting, and our work communities have lost some of their vibrancy. More importantly, some of our teams struggled to deliver software at the same quality and speed. There’s no denying that this new remote and hybrid work system can be improved.
Over the last year, we've turned an eye inward on ourselves to ask, “How do we leap forward rather than make only tiny, incremental improvements?” Being agile practitioners, we approached this question in the same way we approach problems when building software: dig deep on the problem and context, testing ideas early and often, and using data and feedback to refine solutions. To do this, we conducted one-on one-interviews to understand how our teams have self-organized and how they spend their typical days. Due to time constraints, we prioritized surveying balanced teams and representatives for each discipline rather than every single team member. Discussions were analyzed qualitatively and quantitatively.
Here’s what we’ve learned from our build-measure-learn cycles working with client teams spanning numerous industries and across the software lifecycle.
We still consider geography when setting up a team (especially time zones)
When we moved to remote work, we opened up access to a wider and more diverse labor market. Our product delivery teams became more geographically distributed faster than we realized. When we surveyed how these teams were performing, we saw a clear negative correlation between a team’s health and performance with how many time zones were in the team. More than two time zones almost always resulted in a lower-performing team. Again, this is related to the synchronous nature of our work culture. With coast-to-coast time zones, work was stop and go and teams struggled to get productivity momentum in their day.
At first, we believed if people shifted hours (i.e., worked on East Coast time from the West Coast), the teams would still find ways to productively work together. We were surprised by the impact that lunch time had on the team's ability to collaborate. Even when a person shifts their working hours, they still don’t shift their lunch. With Zoom fatigue continuing to be a problem for collaborative teams, we found our teams relied on the lunch hour as an hour for disconnecting. That meant they closed their laptop and walked away from the desk. This limited our collaboration time as we had to accommodate more than one lunch time during the day, which made scheduling key meetings more difficult the more time zones we had to accommodate.
Project health suffers with high time zone distribution. Green = healthy, Yellow = struggling, Red = dysfunction. Spread is defined as max distance between time zones.
We can’t all rely on asynchronous communication
The first thing that failed us was the prevalent advice that asynchronous communication tools, such as Slack and Microsoft Teams, are sufficient replacements for in-person collaboration. Instead of seeing growth in use, we actually saw decreased use of these tools. The unspoken assumption here is that your team’s work is very individualist. Our approach to work (extreme programming) is the opposite. We value close feedback loops and constant collaboration and rely on synchronous communication like paired programming and frequent ad hoc conversations. Our teams were too busy working together face to face; getting messages on Slack was a nuisance more than a help. That reliance on synchronous communication stayed true in the remote context. We rely on real-time collaboration to make quick decisions and build high-quality software with our customers. We continue to pair regularly and maintain regular team sync ceremonies. Remote work did not push our teams to practice more async communication.
Learnings and action items
With these learnings, we began building time zone–aligned teams and are more intentional about geographic requirements during hiring. We highly recommend all leaders evaluate how these conventional ideas are working with an eye to their unique work culture.
We know teams are still very geographically distributed. In the meantime, we created this team template for aligning on core meetings and core hours. Try the template here!
The VMware Tanzu Labs team working hours template
Acknowledging realities and limits
Building culture costs time
As much as we like to think that remote work is basically in-person work online, there are very real physical and social differences that we must acknowledge. We don’t advise blind lift and shifts of software, and we don’t advise the blind lift and shift of office work to remote work.
Before the move to distributed work, we frequently hosted lunch ’n’ learns, hackathons, and speakers. We relied on these “extracurricular” events for community building and innovation. These types of activities have become largely unattended since moving online. No amount of incentives could lure people back. The reality is in remote work, lunch is a rare chance to step away from the computer. That is a structural element of the day that has naturally emerged that made us rethink how we budget time for community activities.
While co-located, it was typical for our team to pair 8 hours a day. Now, they are pairing fewer hours on average.
Remote collaboration is considered more exhausting than in-person collaboration
Another of these structural differences is the impact of being on cameras-on calls. We surveyed our people and found that they feel time on Zoom is far more exhausting than in-person meetings. A combination of tooling issues, such as lag, limited social cues to help conversations flow, and the constant anxiety of being on camera, all contribute to a draining experience. Our team has always embraced a cameras-on culture, so we needed to change that and assure people that going off camera if they need a break was OK.
Most of our team spend more than 75% of their workday on video. No wonder they are exhausted.
Virtual development environment optimizes for security over collaboration
Cameras are not the only things that slow us down and cause exhaustion. Imperfect virtual collaboration tooling created far more toil than we realized. Little things like lag in screen control and mismatched shortcut keys, while merely irritating alone, together compound to an attrition of the smooth developer experience we pride ourselves on having in the office. We took a catalog of all the ways our hardware, network, and tooling were presenting challenges and are actively trying to resolve them.
Less control of our development environment as we moved online degraded the collaboration experience greatly.
Learnings and action items
We built a tool to help our teams and our customers understand what hurdles the collaborative team might face when working remotely. You can try out this tool for your own teams and see recommendations that will help your team work more efficiently and effectively.
New practices need strong support logic
Remote work will never fully replicate everything that co-located work provides, so we need new practices to help compensate. One example of this is office quirks that are crucial to a team, such as overhearing conversations. It’s not possible to re-create eavesdropping virtually, so we tried new practices to achieve the same outcome of information exchange. However, new practices don’t take root on their own, you need to bring people along and explain why they matter.
To facilitate more information exchange, we created intentional unstructured time and space for casual chatter to occur. There are frequently tiny bits of feedback and knowledge that weren’t big enough to warrant scheduled conversation. We tried standing audio and video conference channels on some teams to allow for organic conversation, with mixed success. Some of our practitioners had a mentality that any time not spent pairing is bad for productivity and resisted this type of approach. We needed a public discussion around the changing purpose of time together and the importance of sharing information in service of accelerating collaboration.
Learnings and action items
As we continued the dialogue, we were able to spread other practices that contribute to the same outcome, such as standing virtual offices, audio channels, short standing meetings, and other tooling.
What about you?
We’re constantly learning, improving, and rethinking why we do the things we do so our teams can deliver better software faster. What we’ve found to be successful is to evaluate a team’s practices against their values, support changes with open dialogue about the logic and reasons behind those changes, and be considerate of the unique features of remote work.
If your teams feel like they, too, could stand to be better and deliver faster, join us March 28 for a webinar called Building Healthy and Efficient Software Teams in 2023. We’ll dive further into our research and highlight the patterns, tools, and templates leaders can leverage to build high-performing teams.
Or come talk to us! Let’s figure out what makes a high-performing software delivery team in your unique context and deliver on your product needs at the same time.
