When a company hasn't planned for it, going fully remote is a challenge. In order to succeed, you need to create some rules and guidelines.
Due to the current circumstances, even companies that haven’t been working remotely or have only allowed their employees some days of working from home are now faced with a new reality—entire workforces staying home.
This creates an opportunity to practice remote collaboration. It creates new challenges, but also new opportunities to get to know your colleagues even better; in video conferences, you will meet their partners, kids, and pets, who you might not have seen before.
This post is intended to give some guidance at managing your new reality.
We at Container Solutions changed our job listings this spring to offer remote work. We have been a distributed company since the beginning. But we were hiring for our offices in Europe, the U.K., and Canada. We were already moving toward more remote positions, but the COVID-19 outbreak accelerated this change.
But what does this mean for us? While we will employ remote workers who work out of their homes or co-working spaces, we have to maintain a balance between operating a productive office while still keeping different offices connected and working in-sync with one another.
Like many companies after the crisis ends, we will probably not go back to the office setup we used to have. We currently think of our offices more as creative hubs, where our colleagues meet to share ideas and work together on projects—but without the usual assigned desks.
All teams past a certain size become distributed, whether across rooms, floors, buildings, cities, or continents. But tech is only starting to explore and invest in remote workplaces, which means that, as an industry, we don’t really know what success looks like.
There are Google’s Distributed Work Playbooks, and a lot of useful guidelines published by GitLab and Zapier. I want to outline some key aspects of a remote setup.
What makes distributed teams different from co-located teams and people is intention and advance planning. Remote teamwork doesn’t happen by accident, but through deliberate systems and practices.
In a remote setting, our negative attribution bias is prevalent and the default will be miscommunication and misunderstanding. The most important part of remote work is: Always assume everything done by a team member is done with the best intentions in mind. This doesn’t mean that we need to accept anything, but research shows that neutral tones come across as negative, and positive tones as neutral.
We also can’t expect that everyone will read the Slack message, the email, the announcement, or whatever else. It’s hard to gain context when you don’t see someone day-to-day and when you can’t rely on hallway chatter to spread a message or passively keep people on the same page by walking around.
We have tools and control structures in place at CS to deal with this. We have 15Five, a performance management platform, to get weekly feedback from everyone, as a control structure. Also, our planning sessions, all-hands meetings, local all-hands, and show-and-tells help us create organisational clarity.
One of the biggest questions distributed teams face is synchronous versus asynchronous communication. Synchronous communication happens in real time: Slack or Hangouts meetings. Asynchronous communication has a delay between sending the message and receiving the response: recorded video messages, Google docs, and email. Both types of communication are needed, but we need to get the balance right.
When there is the need for a real-time exchange of ideas, synchronous communication is the way to go. Synchronous communication bonds teams and is crucial for bouncing ideas back and forth. That being said, synchronous communication doesn't need to be ad hoc. If you want to involve your team or all of your organisation in a discussion, think about time zones and customer assignments. Find a spot in your team calendar to discuss your idea.
A simple rule: What doesn’t have to be synchronous is better done asynchronously. Default to asynchronous communication for anything non-critical. Whatever you discuss, however, don’t make a decision without involving your whole team. When making a decision, ask yourself: Do I truly need a real-time back-and-forth on this or can a decision wait until the team gets the chance to discuss this?
At Container Solutions, we are several teams working on different customer projects with different schedules, spread between Europe and North America. To sync and align, team members need to be willing to make an effort to accommodate meetings. We have synchronous meetings over video to plan and sync—such as for our executives, for team leads, and remote whiteboarding sessions— and to share, plan, and brainstorm.
With our CRE department and our soon-to-start U.S. operations, the time-zone difference will increase even more and it will be less easy for teams to schedule meetings or react in real time. If the time-zone difference gets big enough, colleagues will inevitably be left out—or be asked to accommodate their life to work. And when you ask team members to adjust their hours, you’re asking for time that belongs to your colleagues and their families. So think about synchronous versus asynchronous communication, and default if possible to asynchronous.
It requires active management that keeps co-located teams from dominating scheduling preferences. Just because there are more team members in a certain time zone, it doesn’t mean that this group will dominate the schedule. To make this work, we need flexibility from all of us.
Distributed teams aren’t any better than co-located ones, but they are different. For me, the differences make my job easier. By offering remote positions, we as a company widen our pool of potential new colleagues significantly, and this will allow us to reach our growth targets.
There are great examples of successful distributed companies and open-source software projects out there. One of them we all love and some of us contribute to is Kubernetes. Kubernetes is a globally distributed product development effort and we can use some of the concepts applied there.
For distributed asynchronous decision-making, a process called RFC (request for comments) or design proposals could be established. This allows everyone to provide input into decisions—and, as a bonus, we have a historical record.
But, we don’t want you all to stay in your homes or offices. Face time is important, and we continue to invest in getting our teams to meet regularly. In addition to online meetings, we believe teams should meet in person as often as possible without making travel a personal burden for individuals or a financial burden for the company.
When you meet, create an agenda, curate talks, have workshops and co-working time, and plan social activities. If possible, bring in people from other teams for information-sharing and exposure. In-person meetings should be almost like mini offsite sessions. Plan them properly.
Use company resources responsibly; social events don’t need to be posh and expensive. Combining sessions with retros and project/sprint planning with other activities can also work very well.
As I mentioned earlier, even Container Solutions, a company that helps other organisations go Cloud Native and enable distributed teams, is learning how to navigate the day-to-day experience of dealing with a workforce that is scattered in home offices. The reality we are all living now is a large-scale experiment from which we will all learn a great deal we can use after the current crisis ends.
Photo by Pascal Swier on Unsplash