Building a Remote Reliant Organization: Part 2
Reducing Costs in Teams
While an organization needs to help mitigate the costs of distributed work, the core day-to-day support comes at the team level. Over the years, I have come to one somewhat contentious conclusion about it.
I have led teams with people around the globe. One in particular is a friend of mine in Melbourne, Australia, which, depending on the vagaries of daylight savings time, can be 14, 15 or 16 hours offset from my own time zone. In this post, I will call my friend “Jane.” We’ll get back to Jane, and my contentious conclusion, in just a moment, after I establish a bit more context.
Asynchronous Communication Best Practices
A key, standard way to reduce the costs for remote work at the team level is to get really good at asynchronous communication. You can learn a ton about this, and keep apprised of new ideas and best practices, by observing and participating in open source communities. You’ll probably be familiar with some or all of these best practices, but here are a few.
For one, emphasize clear, concise text communication, with a clear hierarchy of expectations.
- Key semi-permanent documents should be in known locations like a central, easily accessible repository or company handbook.
- Key announcements can be published in an external or internal blog. Often these will also announce, or request comments on, the semi-permanent documents (the first category).
- Draft docs work well in a tool that supports easy comments and suggestions, like Google docs or Github.
- Shared issues and to-do items are typically stored in a pertinent tool like Github issues, Trello, a ticketing system, or a CRM.
- Transient short-form communication can be in IRC, Slack, or similar tools.
- Transient long-form communication can be in Slack posts or emails.
A related text communication lesson I have learned at Manifold is that it’s impractical to expect everyone to read all transient communication. Returning to Slack to find hundreds of unread, questionably important short messages will quickly lead to people declaring message bankruptcy, marking everything “read” in one fell swoop. As a corollary, question the value of transient, long-form communication like emails. Overwhelmingly large email inboxes are worse than a Slack deluge, because the cost of evaluating the long-form messages is higher. Getting your message lost in an ocean of text is all too easy. Establish expectations and communications hierarchy, so people know what they absolutely need to read, and what they can ignore with reasonably safety.
Another related best practice is to make videos, particularly for educational topics. Many open source communities demonstrate how valuable it is to make videos. A video doesn’t have to have high production values to be valuable: simple video recordings of live tutorials and technical introductions have been highly valuable for us.
A last asynchronous communication best practice is to be as clear as possible on priorities and status, and track them both in a clear, known place. At this instant in time, like many open source projects, we use Github issues as our engineering database. We build on top of that with other tools (currently Codetree epics and manually maintained Trello boards) for status and priority roll-ups. For a more meta definition of status and deeper insights, we’re exploring a couple of tools to give insight into cycle time and how it is composed. Finally, we write up our daily standup status messages in a daily Slack thread triggered by Zapier, so anyone at the company can read (and write) them anytime.
That’s all good asynchronous communication advice, in my opinion, and a good start for partially distributed teams. With that context, though, now I will return to my Australian friend “Jane” and my more contentious position about how to communicate in partially distributed teams.
Synchronous Communication
I am friends with Jane, as I have been with other people I have managed from Australia, New Zealand, and Thailand, even though they don’t have any natural work hour overlap with me. When I managed Jane, we’d often have long, productive, and fun one-on-ones. We’d connect via email, and all the other asynchronous tools at our disposal. She did great work, cared about our product, and cared about our team.
She also was isolated. Conversations had to be scheduled for me and others, especially in the northern hemisphere’s summer when the time zone difference was the least convenient, and I would often have to start talking to her at 9PM, after my children were in bed. She could rarely ask anyone for immediate help on a problem. While we could fly her to team retreats and build Jane’s connection to the rest of the team, it was at a much higher cost than teammates who lived closer to a central point, so it encouraged us to do it less frequently. Moreover, she didn’t get to share the bond that a team can build with live, daily status, banter, celebrations, and commiserations. We scheduled an optional, regular after-hours team meeting for people to connect with her, but it was sparsely attended.
The team got significantly less value from her than if she had been closer, and she got less value from the team. She was still a leader, and I still wanted her to stay, but I was unsurprised to hear her tell me that she was quitting to work with a local company. This is indicative of the isolation and related problems I have seen for all of the instances of teams that don’t have easy, daily times to connect with one another…synchronously.
I would not be surprised to hear that some people believe that they have figured out a way to mitigate the cost of teams that don’t have work hour overlaps, but until I see something new to convince me, my somewhat contentious conclusion is that good working environments for partially distributed teams should include daily opportunities for easy synchronous communication. Therefore, teams should be within a six or seven hour time zone span. Time-shifts can be possible if they aren’t too far, but I am cautious about them, verging on skeptical.
Make sure that everyone on a team has at least an hour or two of work time overlap, and ideally more. Ask everyone to establish core, reliable working hours, and make them explicit in the company calendar, so people know when synchronous communication is possible. Make unscheduled meetings as easy as tapping someone’s shoulder in an office, and establish easy ways to claim an hour or two of focus, like using Slack’s “do not disturb” feature. Have regular one on ones with leaders, and encourage peer one on ones.
And make good meetings! Scheduled meetings get a bad rap, and they are essential. Work to make them efficient and show value. Some of the following advice is general purpose, and some of it is specific to partially distributed teams.
- Ask for feedback on meetings, listen to it, and act on it.
- Consider leveraging asynchronous communications before moving to meetings.
- If a meeting is collaborative, make sure that everyone sees one another equally, on the same footing. We like Zoom for these meetings: everyone in the meeting gets on the meeting on their own computer even in the office, and then we use gallery mode (a.k.a. Brady Bunch mode) so that all participants are visible at the same time. This makes a huge difference to some people for feeling like a team. It also makes it easier for speakers to “read a room” and know when they need to address concern, boredom, excitement, or other emotions from the rest of the participants
- If a meeting is more of a broadcast, gallery mode may be less important. Using hangouts and a single mic/camera/tv set for the office group might be OK. That said, reading a room the way you can in Zoom’s gallery mode will still be very valuable for some remote speakers.
- Build personal connections and fun in your meetings, even while pursuing efficiency.
- Brainstorming and retrospective meetings should leverage shared tools like Trello, so everyone can participate on equal footing.
Finally, the last synchronous communication I’ll mention is team, or company, retreats. At Manifold, around four times a year or so we see each other live, twice as a full company and twice in smaller teams. As we increase in size, we will probably need to meet by team more, and meet as a company less. These live meetings are expensive but I find them to be incredibly important. It helps us remember who someone is when we read their Github code review or Slack comment, and have empathy to interpret them generously: “no, Will’s not angry — he’s just serious like that sometimes.”
In sum, asynchronous communication is necessary and very valuable, but in my opinion it can’t entirely replace synchronous communication. See this post from MeetEdgar for a similar position, with some more details.
Hiring
The last key component of reducing costs for teams is hiring. Aim for a significant percentage of remote workers — in my opinion, at least 40% — within a team. Otherwise, co-located teammates, and especially co-located leaders, may have a hard time feeling the necessity of investing in the tools, patterns and processes necessary for supporting a distributed culture.
While having a partially distributed team adds many possible hires to your search, it significantly increases the factors that you need to consider. For instance, we already discussed my opinion that a team should have overlapping time zones, so candidates shouldn’t be too far from everyone else that they will work with.
It’s also a corollary from our discussion of asynchronous communication that having strong writing and reading abilities will help your potential employee find success. If a candidate doesn’t enjoy reading, he or she may not be a good choice as a remote employee. Consider incorporating writing and reading into your hiring process, so you can evaluate communication skills.
Beyond time zones, writing skill, and reading skill, look for empathy, an innate desire to grow, persuasion and discussion skills, self-motivation and self-awareness. They are always valuable in candidates, but they are especially valuable to teammates in a partially distributed organization.
You may need to warn potential hires that they will need to invest in social time, and improving social skills, to a degree that they might not have considered in the past. In particular, for remote hires, emphasize the need for social support and the risk of loneliness, if they have not worked remotely before.
When you hire a remote employee, strongly consider scheduling an on-boarding trip for about a week, sending them to an experienced peer who can shepherd the new hire to success. This builds empathy, communication, and confidence from the very beginning. The cost has been worth it, when I’ve seen it done.
In sum, teams should focus on asynchronous communication, synchronous communication, and hiring in order to mitigate the costs of being a remote reliant organization. But teams are made up of individuals, and they have a big role to play themselves.
This post is part of a series
Part 2: You are here
