The 5 Steps to Building an Effective Remote Team
Before COVID-19 changed the world and remote working became the new normal, I had the pleasure of becoming the Product Manager for a team that was split over 6 cities, with a maximum time difference of 9 hours (from San Francisco to Barcelona). They were struggling to be an effective team and had never had a Product Manager before. I’d managed plenty of teams with remote members before and had done my best to make sure they were included in the team as much as possible: “Always on” screens, digital kanbans, etc… but had never had to dig much deeper than that. I’d heard about how GitHub does it and had the benefit of working with expert colleagues like @colettecello, but hadn’t taken the time to “walk a mile” in those shoes yet.
On this occasion, I simply had no choice: this team needed to change its mindset to match that of being fully remote — we needed to treat the times when we were in the office together as a bonus, not the norm. For someone as extroverted as me, who is far better with his words than his keystrokes, this remote team conversion was a painful education. As George Bernard Shaw said:
“The single biggest problem in communication is the illusion that it has taken place.”
Step 1: Make sure people are hearing what you’re saying
Just as computers need a “digital handshake” to ensure they are communicating correctly, humans are no different — we use body language, eye contact and our physical contact to check people are hearing what we’re saying. However, in the remote world, you are often not able to do any of these, even with the best video conferencing software around. I’d always relied on the ability to book a quick meeting at short notice to get everyone on the same page: suddenly this was not possible and we needed to find a way for all our communications to be via Slack.
Members of this team had a problem they weren’t aware of — they were simply unable to communicate effectively. They realized they needed to make Slack their default communications channel, but had over 20 channels, one for each department (Marketing, Finance, Legal, Tech, Research etc…). This was a structure that had been copied from the UK organization, however we only had 18 people in our team, whereas the UK business had 1,500. They had planned ahead for growth, without realizing their immediate needs were different and far more important. They were beginning to appreciate that the chances of achieving growth without effective communications were slim.
Each member of the team was a member of a selection of these channels, with none of them being the default (and dominant) channel for general communication about work and decisions. This meant there was no way for me (or anyone else) to write a message and be confident everyone would see it, let alone read it. That is a big problem for a small team.
This was the first problem that needed to be solved, and luckily I knew the short term solution: a single Slack channel in which 80% of our communications happened and everyone checked as their first priority. This channel would need to be the equivalent of someone saying your name loudly in the office. But how do you implement this kind of change without being able to talk to the team as a whole about it?
Step 2: Learn to make decisions by consent, not consensus.
This felt like a real Catch 22 — How do you make the decision to change your communications when you can’t communicate decision making?! Add to this that I was new to the team, so hadn’t met anyone before and may not even meet some colleagues face-to-face for months. I hadn’t built the trust you need to make significant changes yet, but you need to make changes in order to be effective, prove your worth and build trust.
Unsurprisingly the key to unlock this problem (as with so much in life) was, and will always be: “Speak to people”. However there is a caveat: you will need to dampen your expectations. It’s going to take a lot longer than it would if you were co-located.
To get buy-in for my changes, I sense-checked the problem and my solution in virtual 1on1s, wrote a short proposal on the issue and shared it across multiple team Slack channels. I explicitly asked for comment and an emoji reaction stating whether they were happy for it to move forward, or if they had objections that needed to be addressed first — I sought consent. Once this consultation phase had concluded, the team collectively approved to archive 13 of the channels, leaving us only 7 — crucially with one explicitly designated to be the default channel for communication, as well as decision making.
Although it may sound trivial, these two steps combined were game changing, as they allowed us to make improvements to the ways we worked in an asynchronous manner, meaning without everyone being present at the same time. People were now able to write a short proposal, know everyone had seen it and had a chance to reject — then proceed based on that model of consent. It was simple for someone to show support or an objection via an emoji and for the person proposing the change to have the confidence to proceed. Once this system was in place, everyone felt empowered to make change, knowing that they weren’t treading on anyone’s toes without realizing.
This doesn’t mean we don’t want consensus, consensus is great, it’s that magical moment that leaves everyone in the room feeling warm and fuzzy. It does mean that consensus in a fast paced remote team may not always be possible and the quest to achieve it might lead to more pain and be unrealistically time-consuming, than the solution solves.
Stage 3. Find a way to make team rituals work
The team had rituals (planning, standups etc…), but they were poorly attended and ineffective. People went because it was in their calendars and therefore routine, but wouldn’t have been able to tell you why or what benefit they provided. This is a common problem on teams and one that is easier to solve if you’re co-located, but the principle is the same — you’re going to need to make their purpose explicit, by making them amazing.
First things first, I think you can tell everything about a team by attending one standup. This team had standups in the late afternoon, so people on the west coast could participate. Makes sense. However, they had them at 8am west coast time, 4pm UK time — for no apparent reason. We had to find a way to change that, 8am in the world of technology is not sociable. So after building some empathy, standups became 9am west coast time, and suddenly attendance from people based there improved.
For those in an office, meeting rooms were not booked in advance, so poor acoustics meant you often couldn’t hear what people were saying and there wasn’t always space for everyone to dial in independently. So I spent a few hours booking rooms for weeks in advance. Now everyone could ensure that they would be able to hear what others were saying.
The team didn’t have an up-to-date kanban board; this meant standups were ephemeral and only half the people there gave an update; there was no accountability for work in progress. It’s easy not to give an update when people are dialing in and put themselves on mute. We implemented a Trello board, made it up to date and started “walking the wall” during standups. Now everyone spoke and people started offering help to collaborate with each other. Suddenly we had an atmosphere where serendipity could thrive: “Oh you’re working on that, I know about that”.
Standups, now in the evening UK time, might look and feel different. They might take longer, will need to have energy injected and be worth everyone’s time. Make them awesome, make them the most important 20mins of everyone’s working life and people won’t want to miss out.
The same logic can be applied to the other rituals (Retrospectives, Planning, Show & Tells): put the effort into planning them, use great digital tools, make sure they are at a time everyone can make and facilitate the hell out of them.
Stage 4. Learn to video conference, but don’t stop traveling
The team is now communicating well, is able to make decisions and your awesome rituals have allowed you to start shipping. Things are starting to happen, now is when you need to keep them going.
Firstly, everyone in the team should acknowledge that remote meetings are harder than face-to-face, so you will need to dampen expectations slightly. Remote meetings often deprive us of the audio and visual cues we rely on, so they might feel more formulaic, with less room for jokes or fun. This is often exacerbated by the “culture of muting”, where our default state is on mute, creating a physical barrier to joining a conversation. This, along with the fact that things break down if more than one person speaks at the same time, means remote conversations often involve less people than their in-person cousins. These factors can combine to make remote meetings the bane of many a working day.
So, if you can, agree as a team not to use mute, agree to use certain language to double check the other person is hearing what you’re saying and of course make sure you have good internet. If remote meetings make you feel more anxious than normal, remember that everyone is feeling this in one way or another.
However, we should all acknowledge that nothing will beat getting everyone in the room together — so make it happen. Some teams agree to do it every 3 or 4 months, others base it around a specific need. For us, we’d conducted some awesome research to identify user problems and now we needed to decide how to solve them — so we got everyone to the same place and ran a week long design sprint. It was the first time the entire product team had been in the same room.
As well as designing some awesome solutions, we had lunch, dinner and drinks together. It’s simple, but it works. Don’t underestimate the work required behind the scenes to make it run smoothly though, remember it needs to be awesome.
Stage 5. Be explicit in everything you do.
You trust each other, you’re shipping regularly and you’re able to agree on what to build next. Now the most important thing to keep up the momentum is to ensure everyone is being as vocal as they can.
You’re going to have less time speaking face-to-face, less visual cues and often won’t get second chances to clarify your thoughts after a meeting. This combined with the natural lack of context that Slack can give you means problems can arise. Being explicit and speaking directly does not mean being a dick, it does mean oversharing what you’re thinking and exactly what action you plan to take.
You need to be explicit about how you’re feeling, what you think about an idea and when you have an objection. Do not assume that someone else will magically read between the lines of what you actually say. Trust is a bucket with a hole in it and must be constantly refilled, in a remote scenario this is harder and being more vocal will help. It allows everyone to have the confidence to do the thing they need to do, as assuming they have shared their thinking, they know you will let them know if there is a problem.
Talk about the “why”, Slack the output of the conversation two people had in the corridor and summarize the meetings that were missed by team members. Being a Product Manager is about making sure people know what they are building and why. Being remote is going to make that much harder if you’re used to a whiteboard and a room full of people. So get better at concise writing, get better at asynchronous feedback and be prepared for a very different day-to-day life.
What about you?
I’m sure there are a whole host of people who know much more than me about this topic, so what are your lessons learnt? Let me know @BenjiPortwin
