The challenges that come with remote work can be deceptive: If you’ve transitioned from an in-office role, it might seem like the best thing to do is to try and recreate all of the experiences that come with an office environment. But being remote is not the same as sharing a physical space. Instead of trying to replicate the in-office atmosphere, we must adapt—or even wholly reconsider—those experiences for the distributed context.
Thinking remote means being able to distill our interactions and reflect on what we value. What aspects of being in an office do we care about the most? How can we extract these parts and repurpose them to work on distributed teams? Once we identify the most valuable outcomes of the in-office experience, we can begin to recreate them in a remote context.
Ask good questions, provide good answers
The remote work paradigm demands that we’re thoughtful and precise. Imagine asking a colleague a question about a part of the codebase that you’re unfamiliar with while they’re sitting across from you. This setup allows you to exchange questions and answers, and explain your thinking in real time. The conversation might end with them linking to some documentation. This rapid-fire, synchronous exchange of knowledge doesn’t work nearly as well if, for instance, your coworker is 10 hours ahead of you. While potential differences in time zones are only one aspect of the remote experience, if each of you responds during your working hours, that exchange could take a week.
In the absence of instant feedback from our peers by default, it’s up to us to think critically about what questions we ask, and how we ask them. A carefully considered, well thought-out question that provides context and information about what you know, what you don’t, and what solutions you’ve already explored will result in a more useful answer than a question that requires additional follow-up. Learning how to ask one good question rather than a series of less effective ones can help bridge gaps between time zones, recreating the experience of having someone immediately available to provide context and help you get unstuck.
The same rules apply to giving a well-formed and carefully considered answer. Just as a good question provides as much context as possible up front, a good answer explicitly states any assumptions that you might be making about how someone is approaching a problem from the get-go. Answering a question is just as much about explaining why something is happening as it is about how to fix it. A good answer also makes use of things that have already been written down, like internal and external documentation, code snippets, and old pull requests to help provide context.
Consider the right tooling
Effective communication goes even further when supplemented with the right tooling. Smaller, in-office teams might have habits that rely on co-location. A previous team I worked on, for example, would announce—out loud—when they were deploying major releases or rolling back a change. It worked in our context at the time, but it’s not a scalable approach—nor does it enable visibility for remote team members. Conversely, when the entire team is remote, every message ends up dumped into some communication platform, which can result in a lot to sift through. I’ve found that it helps to strike a balance between drowning in too much information and struggling with not having enough. For a small enough team, translating in-office announcements into a #dev-headsup Slack channel for engineering team announcements can provide easy access to real-time updates. This strategy worked well for our team of less than 30, but for larger teams, some curation might be required—important announcements may need to be targeted toward those working on different products or even using specific parts of the technology stack. A #systems-headsup channel, for example, could split out the announcements for systems engineers versus frontend developers, and help cut down on noise.
Sometimes, the outcomes we want from an interaction are less concrete. How do you evaluate momentum when you can’t immediately see whether your team is making progress—or feeling stuck? When I worked in an office, my mornings were structured around 20-minute stand-ups during which the team shared status updates, flagged blockers, and asked for pairing time. But the synchronous nature of stand-ups doesn’t always translate when teams are working remotely. There are a number of alternate approaches you might take. One simple strategy I’ve found effective is setting a Slack reminder that is automated to ping the team at the same time every day with the same questions: What did you work on yesterday? What will you work on today? Are you blocked? Do you want to pair?
When my current distributed team started using this scheduled reminder to touch base, we gained a much better understanding of what everyone was working on. Personally, I felt more connected to my teammates and better equipped to support them as a leader: I could more accurately calibrate our productivity, assess who was stuck or in need of guidance, and identify when we were blocked enough that I needed to bring in additional support or resources. Other teams in our company have since adopted this workflow, and my team has further expanded our automated tooling, leaning into additional integrations and reminders. I haven’t had to think about collating a team update for our weekly all-hands meetings in months—we have a bot that reminds us to thread our updates. These small tweaks to daily processes can cumulatively reduce the number of repetitive tasks that everyone on a team has to remember to do.
Adapt and thrive
Not every aspect of an in-person environment has an easy remote analog, nor can every solution be easily automated. Effective collaboration with those we work most closely with requires a variety of touch points and subtleties that make it hard to get right—even in an in-person context. But before we throw in the towel, consider what outcomes of a healthy relationship with a colleague really matter. Once we identify the essence of what nourishes a thriving coworker relationship, we can adapt our interactions to prioritize those outcomes.
A newer engineer, for example, may be looking for the opportunity to learn new things, a safe space to ask questions, career advice, regular feedback from a trusted confidant, and even an advocate. On my current team, providing this takes the form of multiple weekly pairing sessions between newer and more experienced engineers, as well as deliberate, thoughtful project scoping to ensure that new engineers aren’t working on something too far out of their depth. A nice side effect of this approach to scoping is the impact that it’s had on the rest of the team: Tasks became more defined, and projects with the potential for pairing and learning became more obvious. As a result, engineers—regardless of their level—have better-defined deliverables, as well as a clear path to becoming better at pairing and teaching their coworkers, if they so desire.
The seemingly mundane interactions of day-to-day life in an office have their own outcomes, too. By focusing again on the essence of these interactions, we’ll find remote ways to achieve the best of them. Instead of wondering how to replicate team happy hours, we can ask ourselves how to create a sense of connection to our colleagues. Instead of wondering what to do in place of group lunches, we can ask ourselves how we can create opportunities for team members to learn more about one another. Every team will develop their own solutions, and reconsidering your default can encourage creative and effective outcomes.
Shifting to a remote mindset doesn’t mean giving up on bonding with your team. It just requires a shift in perspective—away from what your interactions look like in an office context, and toward what those interactions actually resulted in and how you can achieve similarly satisfying results in a remote context.
As programmers, we’re quite good at adapting our code to make things work. With the right mindset, we can do the same with the way we work together.