A rip current is a powerful flow that can drag an unsuspecting swimmer out to sea. When visiting a beach with rip currents, you’re told that if you get caught in one, you shouldn’t try to swim back toward the beach, against the current—it’s too strong. Instead, you should swim parallel to the beach to get out of the current, and then you can get back to shore more easily.
I’ve seen a lot of people starting to work remotely—a lot of them involuntarily these days—and struggling with it. They’re swimming against the current.
As the Tao Te Ching (and Bruce Lee) tell us, water is powerful because it is shapeless and adapts to its surroundings. It is always flowing downhill and penetrating cracks. Similarly, when we work remotely, we need to adapt: we need to figure out which way is downhill and go that way. We should flow like water.
I’ve been working remotely and leading fully distributed teams for close to a decade now. Whenever people ask me what it’s like to lead remote software teams, and how to make remote work successful, these are the things I emphasize. There are lots of great resources out there that can tell you what to do. I’m more interested here in motivating why the practices they identify are important, as well as how to think about the upsides and downsides of distributed teams.
Distributed is different
The first point is recognizing that distributed work is fundamentally different. It’s not just about taking the thing you do in an office and doing it at home. And it’s not the same as that one day a week in your office job that you’re allowed to work from home.
Critically, what is important is not where you work but how the team is organized: whether it is organized around everyone being in different locations or in one location. For this reason, rather than using the word “remote” to describe teams or companies, I prefer to distinguish between “distributed” and “colocated” teams. An individual might work remotely for either a distributed or colocated team, and the implications are very different.
When someone tells me they have a team working in their office and are interested to start hiring remote people, my response is that they need to invert things in their mind—and in their company culture. Instead of having a colocated team with some remote workers, they need to become a distributed team that happens to have a set of people working in the same location.
Compared with a colocated team, certain things are easier for a distributed team and others are harder. The key strengths of a distributed team are (1) that they can hire talented people who live in different places and who may have life circumstances that prevent them from being in your office from 9-to-5 and (2) that being remote can make it easier for people to carve out blocks of quiet, uninterrupted time to focus and get work done. In contrast, it is harder to build and maintain personal relationships on the team, and some leadership and decisionmaking is more challenging when everyone isn’t in the same room.
To say that some things are easier and other harder is a pretty basic observation, but some important insights follow from it. For one, the question isn’t whether one way of organizing is strictly better than the other: there are tradeoffs, and each may be better at some tasks than the other. Moreover, some people may be better disposed to remote work and distributed teams than others.
You can either fight against your weaknesses or play to your strengths. Often when people discuss tips for working from home, it seems like the focus is on the former: looking for ways to make working-from-home less difficult. But that’s not the best way to think about the challenge you face. If you have a distributed team, you shouldn’t act as if you have a colocated team—everything will seem so hard!
In my experience, it’s most constructive to focus on ways to harness the advantages of your working situation: don’t swim against the current. For distributed teams, that means looking for ways to organize work that protect individual focus time and support people that work in different time windows. That said, we must be aware of the disadvantages, know that we can’t rely on the same practices for team-building and communication as a colocated team, and create different opportunities for fulfilling those needs.
Embrace asynchronous
The first message people get when they start working remotely is that they have to use tools like chat to communicate with others, and since they can’t physically see that the other person is there, they should expect communication to be asynchronous: you ask a question and you may not get an immediate response. Lots of remote work resources stress async communication.
The reason distributed teams should prefer asynchronous and public communication is that doing so helps them take advantage of one of remote work’s strengths: the potential for quiet, uninterrupted focus time. Rather than pinging an individual with a private message, post your request in a public channel. One of several things may happen: you may get an immediate response from the person you asked, just as if you’d walked over to ask them physically. But maybe that person is busy, and someone else who is available sees the question and answers it first. You still get your answer, and faster than if you’d only asked one person. And—importantly—you haven’t interrupted anyone’s focus time. Regardless of who answers and when, because it was done publicly, now everyone knows the answer and can be helpful next time something similar arises.
Many people struggle to truly embrace async. And just because you use chat doesn’t mean you’re being asynchronous. If you switch from walking to someone’s desk and interrupting them to pinging them with a direct chat message, you’ve still interrupted them, just remotely.
Truly embracing asynchronous communication empowers your team to structure their work day in the way that is most effective for them, which is another key strength of distributed teams. You get to work with talented people who don’t necessarily live in your area, who may care for children or older relatives, or maybe they are active in other ways in their community. Or, maybe they’re the kind of person who gets their best work done at 1 A.M. These are all great people who can make valuable contributions and have unique perspectives. Asynchronous communication gives them the ability to respond to questions and requests in the most effective way, and doing it publicly lets them catch up on discussions at their convenience, during their working hours.
Create structure with flexibility
I think some of the resistance to asynchronous communication is the fear that if someone doesn’t respond immediately, they’ll never respond. Remote work can allow for greater flexibility, and to work with other remote workers, we need to be flexible with them. To make the flexibility work, though, it helps to establish some structure and to be clear about expectations.
For your own sanity, when working from home it helps to have regular “work hours”. If your place of work and your place of rest are the same, it’s all too easy to have work take over everything. Most people benefit from creating some sort of structure or ritual that divides the work day from the rest. For me, I have young children, so my workday is mostly bookended by daycare drop-off and pick-up. My “commute” is walking my daughter to school because when I return to the house, I’m “at work”. And when the kids are home in the morning and after work, my attention is on them.
Keeping a regular schedule isn’t just for your own benefit, however. The rest of your team needs to know when they can expect you to be available—not that they should expect an immediate response from you, of course, but whether to expect that you won’t get back to them until tomorrow, for example. It’s really important to know who is available when so that you can avoid asking people to do things when they’re not around. That stresses them out getting notifications when they’re not working, and it stresses you out waiting for a response.
That said, while it is important to maintain structure and boundaries between work and life, it’s good to be flexible, particularly when working with people in different time zones. I sometimes get up early to catch a meeting with my European colleagues before my kids wake up, and likewise (more often, honestly) they hang around a little later in their day for meetings with us.
Distributed relationship building
As I suggested above, the biggest challenge distributed teams have is around building and sustaining the personal, human relationships among everyone on the team. Teams are most effective when they have a clear, shared understanding of their mission, and when they feel personal—not just professional—loyalty and accountability to each other. They’re doing their best work because they know everyone else is and they don’t want to let their teammates down, and they seek out ways to support each other.
Building that personal rapport is much, much easier to do in person, which is why I find that having in-person team meetings a few times a year is essential for sustaining high-performing distributed teams. In a way, these in-person meetings let you be a colocated team from time to time.
But, remember that the point of the time spent together isn’t how much “work” gets done: going to a quiet room alone and cranking out code is what you do when you’re at home, in distributed mode. In-person meetings are great for planning and decisionmaking sessions, which can be harder to do remotely, but even more important is the time spent just hanging out, getting dinner and talking about your families, going out for a hike together, exploring that new coffee shop across town.
This challenge of maintaining relationships is also a reason I am much more in favor of inane banter on chat tools like Slack. Some people claim that chat is terrible for productivity, but the kinds of chatter that they criticize actually serve a function on a distributed team: they help build a sense of camaraderie and team culture that is otherwise difficult to do when folks are not in the same location. We can’t go get lunch together or grab a beer after work, but we can make each other feel appreciated and humanized by sharing animated GIFs, developing an idiomatic use of certain emoji, and other forms of colorful expression.
Sure, a noisy chat channel can be a distraction, but sometimes we need a distraction after hours of solitary focus time. With appropriate moderation, this kind of unproductive chat banter is exactly what is needed to sustain human connections that are made in our periodic in-person gatherings, reinforcing the bonds that hold the team together. A colocated team might need less of this since they can get their informal relationship building more naturally, and they perhaps should try to tamp down on it because it undermines attempts at creating intervals of focused work time. But on a distributed team, we have a surplus of isolation, so we can afford to spend some of it on dank memes.
Distributed coordination
When everyone is at a physical distance, all communication is mediated by some electronic system. It’s important to be aware what signals they amplify and what they dampen in order to use them effectively.
Overcommunicate
On a distributed team, you should be more explicit in communication than you think is necessary and repeat messages more times than you think you need to. This is especially relevant for leaders. There’s something about having everyone in a room or an office working on the same project that reinforces the sense of mission and priority: everyone is talking about the same thing, and you can see that they’re all working on it. It’s in the ether.
But when you’re remote, you’re not immersed the same way. You have to be more intentional with your communication because everyone else can’t just pick up the signals informally. A risk of a distributed team is that people will drift away and feel like they are on their own. Leaders should reinforce their messaging on goals and priorities at every opportunity to provide more structure, which they probably wouldn’t have to work as hard at if they were colocated.
Find the right forum
Imagine that we are working out the technical design for a software project, and we’re trying to determine fundamental features like the underlying data structures that will support it. Someone will put together a proposal, we’ll review and debate the merits of some aspects of it, and then we’ll make a decision on any questions raised.
Each of these stages involves a form of communication of ideas, but they’re all very different. On one extreme, a technical proposal can require hours of focused effort preparing a single document; on the other, a decisive, executive decision can be made quickly. The speeds of thought and communication required to be effective are very different.
Similarly, different methods of communication vary in latency: how long there is between request and response. In-person or video conversations have low latency, while you could think of “let me get back to you with a proposal document” as a very high latency exchange.
We should be mindful of how well the communication medium we’re using matches up with the task at hand. Problems that require a lot of thought before speaking can be difficult to solve through real-time communication. Likewise, problems that require a lot of back and forth suffer when there is high latency in the communication.
Trying to solve a problem with the wrong communication medium can be very frustrating, so we shouldn’t be afraid to suggest changing forums. On a distributed team, often we’re starting in chat, and we either need to (1) slow this down to an email discussion so that people can formulate their opinions better and so others who aren’t at work right now can participate; (2) slow it down even further and have someone put together a more organized document that synthesizes the discussion so that we can make sure we’re talking about the right things; or (3) jump on a quick video call to be able to more quickly work through confusion. I’ve participated in too many half-hour or longer chat discussions that would have been more effective as either a 5 minute call or as comments on a concrete proposal, if we could just stop chatting long enough to write it.
This can be really helpful to get the participation of different people. Not everyone performs well in a rapid-fire meeting, but they may have great ideas if you give them space to develop and express them.
Guerrilla warfare
Insurgencies don’t defeat much stronger conventional militaries by following conventional tactics. They adopt techniques that turn their on-paper weaknesses into strengths. Similarly, if you have a distributed team, don’t try to force it to act like a colocated one. Look to what opportunities being distributed provides and pursue those.
The various practices and norms that are generally recommended for distributed work—ways to communicate and organize—are important because they reinforce the strengths of distributed teams. They make less sense for colocated teams because they have different natural advantages and disadvantages.
I’m the kind of person that likes to understand why I should do something, particularly when it’s not obvious that I should. (I have a question for one person, but I should ask it in a public channel, and I shouldn’t expect an immediate answer even though it’s a simple question?) It helps me to know that the best practices for remote work aren’t just things to do for their own sake—we prefer asynchronous communication because it lets us harness the power of deep work that being remote encourages. It helps me to be able to flow like water.