How to Manage a Remote Team

I was out to breakfast last week and I overheard the people at the table behind me talking about working in tech and managing teams. I wasn’t eavesdropping, they were just kind of loud. One of them was lamenting how difficult it is to have his team geographically distributed because when an issue comes up, he has to DM a team member and wait for them to respond and say they can help; if they can’t help or it takes too long to respond, he has to message another team member, etc. He was complaining that being remote means he doesn’t get to do that thing you do in person when something goes wrong or you need help and you just sort of flail and get everyone’s attention.

Now, I don’t want to be mean to the loud man at the table behind me, but the problem isn’t that his team is remote – it’s that he appears not to know how to manage a remote team. (To be honest, there are some red flags in general here that aren’t remote-specific as well. Sorry, breakfast guy.)

Your communication sucks

Ultimately, teams that work well together do so because they have good communication. Maybe it’s easier to have good communication if you’re all in the same space, but I’m not convinced. I know a lot of families that communicate poorly and are co-located, for example. I’ve been on teams that were in the same office where no one ever spoke to each other, and teams that have been flung around the world that never felt lonely.

Our breakfast friend’s struggle points to some key issues:

• they didn’t have an established approach for how to ask for help in case of an ‘emergency’, 
• they appeared to not have established expectations around Slack availability / response times, and 
• they don’t have a culture of collaboration. 

As far as I’m concerned, none of these are issues of ‘remote’-ness so much as issues of establishing team practices, fostering a collaborative environment, and building the spaces where your team can thrive. So, how does one build those spaces when distributed?

Your team Slack channel is your “office”

It boils down to one concept: your team’s Slack (or Discord, Teams, whatever) channel is the office. You’re not actually remote; you’re co-located in a Slack channel with your team members. That Slack channel is a safe place to do all the things you’d normally do in a well-functioning office, so if you have a question that you need answered, you post in the Slack channel. If you’re deploying to prod, you post in the Slack channel. If you just got back from vacation and have fun vacation pictures to share, you post in the Slack channel. The Website Is Down? Post to Slack.

It’s honestly important to have some social content in there, so you get the watercooler-y chatting (and cat pictures, good Slack reacts, ‘my kid just puked so I gotta flee’, ‘did you know that tigers are nocturnal?’ facts, etc.) and build a sense of being a cohesive team. The low barrier to communication for non-work things establishes a low barrier for communication of work things as well.

Your team’s Slack channel should be private and should include all of the relevant people that you work with day-to-day. In my case, it’s been the engineers on my team, our associated product and program managers, and the product designers we work with regularly. Sometimes we’ve also included our department Director; other times not. It’s important that folks can ask whatever questions they have without worrying that they’ll be perceived as incompetent or be blamed for something going wrong. You don’t want someone to hide an issue because they’re embarrassed or worried they’ll get in trouble. As a parent, I want my kids to feel safe coming to me when they’ve fucked up so I can help them solve that problem; as a manager, I want my team to come to me for the same reasons.

Failures / bugs / outages are opportunities for us to learn from so we’re better prepared for the next one. It sounds to me like our breakfast friend needs to sit down with his team (and ideally a clever program manager) and figure out a system that works for them. I’m not sure what issue he was trying to fix, but maybe their team needs a support rotation; maybe they need a documented ‘the website is down’ playbook that you work through when an outage occurs; maybe better use of their team Slack channel would suffice. Based on his complaints about waiting for people to respond, establishing and documenting their team’s policies around setting Slack statuses and response times would also be good. 

If you build it they will come?

It might sound like I’m saying that all you need is a Slack channel and your remote / distributed team will run well. Unfortunately, no. The collaboration team space is key, but as a manager, you need to model (and encourage) the behaviour you’re looking for. Every time someone DM’d me to ask a work question, I asked them to post to the team channel instead, where I’d answer in a thread that everyone could see. Whenever I heard about engineering conversations happening in DMs, I’d encourage my team members to move those conversations to the channel. Getting together to discuss an issue in a Zoom call? Post a link to the Zoom room to the channel so other folks can join, and summarize the results of the call into Slack afterwards (maybe use Zoom’s often hilarious and occasionally incomprehensible AI summaries for some team bonding laughs). Not only does it provide more people with context behind decision-making and give other team members opportunity to share their thoughts, but retention policies on Slack channels are often longer than on DMs, so it preserves conversations for future reference for longer.

Does the communication shift happen overnight? No, it requires active work and buy-in from your team. We’d been casually pushing conversations to Slack for a while, but it didn’t necessarily have full traction among the team until a few consecutive Sprint Retrospectives where team members reported that they didn’t feel like they knew what was going on more broadly within our stack. There were a bunch of ideas about how we could address this, and as a starting point, we agreed to try pushing more discussion to our Slack channel for six weeks (three sprints) and see if that helped. I’ll admit, I was pretty sure we were going to stick with it, but change is often easier to take when it’s timeboxed as an “experiment”.

Six weeks later, we agreed this was working, it had become a habit, and we kept doing it.

United we stand

Collaboration and communication that might happen more organically in person (you run into Sally from team A at lunch and discover you’re working on similar things) requires active effort when distributed… and if you don’t put in that effort, you’re liable to miss out. That said, it’s absolutely possible to have good communication and collaboration within remote teams if you establish the spaces and model the communication patterns that help teams thrive. There are clear benefits to allowing distributed teams and with deliberate effort the downsides can be counteracted.

As a manager, I’ve viewed my job as ensuring my team has what they need to succeed and being accountable for ensuring that success. “What my team needs” is very broad and includes operational things like: decisions from product management, software licences, headcount, AWS budget, detailed product descriptions, designs with different breakpoints, etc., as well as tactical and strategic responsibilities, like establishing and fostering good communication patterns within the team, setting expectations and following through on them, and supporting team members’ growth. My responsibilities as a manager are the same whether remote or co-located, but the approaches that work in person may not work remotely. Hopefully this can be a starting point for folks like my breakfast neighbour who need to adapt their practices to reflect the changing work environment.

Working remotely works really well for me and I don’t want to see this hugely beneficial working arrangement end because some managers couldn’t keep up with the times. 

Thank you to Amy Goldsmith and Paul Reinheimer for reading earlier drafts of this post. Thank you also to the loud man in the diner in Ottawa for the catalyst.