At Atomic Object, we value co-located teams. But not every team member can always be co-located. Larger project teams may have members from multiple offices. Some projects might involve working closely with other vendors. I experience this “remoteness” when I support the infrastructure needs of teams in our Ann Arbor and Detroit offices.
When these situations arise, it helps if your communication style is already what I would call “remote-first”.
What is remote-first communication?
Remote-first communication prioritizes communicating with those who are not here now. Whether that’s a team member who’s working from home with a bad head cold or your client on the coast, successful projects go the extra mile to communicate effectively with those who are remote.
Generally speaking, remote-first communication means preferring written, searchable methods of communication that work even when the sender and receiver aren’t engaged at the same time. This means that phone calls, while potentially much better at conveying tone and establishing emotional connections, cannot be the default method of connecting with teammates.
Remember, the group of people on your team who are “not here now” also includes anyone who might work on the project at any point in the future, including yourself. Remote-first communication has the knock-on effect of acting as a form of documentation—recording conversations had, decisions made, resources shared, etc.
Privacy Limits & No-blame Culture
Remote-first communication that clearly documents problems encountered, ideas proposed, and decisions reached works best in organizations with strong no-blame cultures. The extent to which team members fear their words being used against them in the future limits their candor in ways that can greatly impede coming to solutions. This is is generally true, but the lasting verbatim record of remote-first communication greatly amplifies the need to tend to this culture.
Remote-first Tools used by Atomic
Remote-first communication is not just about the media used, but also the way in which they are used, the patterns of communication. Teams may use a variety of tools to communicate, but remote-first communication patterns have, as a default, a medium that favors communication with remote team members.
Here are some tools I’ve seen used in this way at Atomic:
- Trello
- Jabber/XMPP/GTalk
- HipChat
- Slack
- IRC
- Pivotal Tracker
- Basecamp
What is important to note is that these platforms can and are used even by team members who work right next to each other.
Remote in the Open
One downside to our open office environment can be distracting noise levels from neighboring project teams. While we’re exploring ways we can change our space to mitigate such issues, remote-first communication also helps keep noise levels down.
Another benefit of remote-first communication is that it can create a space for people who prefer written communication to speaking aloud. This might be a team member who is shy, or whose first language isn’t English, or who is hard of hearing—there are a lot of reasons people might be more comfortable communicating through text. I know that I sometimes value having a moment to switch contexts and collect my thoughts before responding to an instant message, a luxury not always afforded by direct in-person questions.
Remote-first Is not Remote-always
Remote-first communication does not mean that your only communication should be written. There are certainly times when in-person conversations or phone calls will be much more effective. Particularly when it comes to delivering disappointing news or when first getting to know your client or team, it can be much better to converse in a way that allows an emotional connection.
In short, teams that use text-based communication tools as a default communication medium are better equipped for remote communication across both space and time.
How do your teams practice remote first communication?
Further Reading on Communicating with Remote Teams:
- Tools & Practices for Remote Teams by John Croisant
- Working with Remote Software Teams by Shawn Crowley
- Working remote, 8 months in by Julia Evans
- How I Work Remotely by Matt Blodgett
- Open, Closed, Remote?!? by David Parmenter
- Getting Virtual Teams Right by Keith Ferrazzi
All of this is an improvement over voice only communication, but do you have contingency plans in case any of your information repositories shuts down (maybe an acquihire)? Some teams I’m working with have started to move a lot of information to Trello and I wonder what happens if they have to close. There is a JSON export but then what? Maybe an import into http://git.libreboard.com/libreboard/libreboard if an import exists. I’m using Google Docs to share specs also because it has convenient way to extract files and use them even if they’ll close the service.
The first comment brings up a good point, what happens when information is scattered across multiple tools (like JIRA, Google Docs, Trello, Basecamp, email) and what happens when the information gets locked in by a vendor? I like the idea of using tools that allow easy export of data.
Knowledge workers require good tools and good organization abilities and it’s sad to see so many teams failing at this even if they aren’t remote. Without written text, civilization would be in the dark ages. It’s kinda why we developed the alphabet, writing and more advanced modes of texts, so that information can be recalled easily and so that we as a species could advance further. Amazing how many offices are okay with unwritten communication and how many workplaces encourage that for the more crucial decisions.
There is an assumption here that remote working means text. But tools like Talko contradict that. The human voice is needed to create empathy and rapport.