Plugging In: How Going Remote-First Is Challenging Our Engineers to Collaborate More Deliberately

Estimated Reading Time: 7 minutes

Going remote-first isn’t just giving our engineers the freedom to do their best work. It’s challenging them to define what and how they’ll achieve it, forcing them to work together more deliberately –  in pairs and across projects. And that’s an excellent thing.

———————————————

To ship world-class software, our engineering practice relies on several collaborative techniques: pair programming, code reviews, project-wide meetings – I could go on. So when the company decided to go remote-first late last year, I wanted to make sure that we could transfer those practices to the new model as best we could. 

There were challenges.

However, it’s how we overcame those challenges and continue to: creatively, collectively, and iteratively do so is worth talking about. Because from them spawned some surprising benefits, all of which contributed to hitting our stride as a remote-first company.

Focus and flexibility

Let me start with the most straightforward win: our engineers simply love working remotely. Aside from hearing this in conversation and via one-on-ones, our formal surveys read loud and clear on this. 

And it’s not hard to see why. Open concept offices are great for serendipitous collaboration—anyone can approach anyone else to ask questions, jam on ideas, and so on—but for the same reason, they make it hard to do the deep, heads-down work that is a necessary part of developing software. 

By giving our engineers the freedom to work from home, we empower them to take control of their environment, eliminate unnecessary distractions, and work in the best way that suits them. And because we’re remote-first rather than remote-only, people can mix it up depending on their mood, preferred working style, and the nature of the project.

Defining groups

A remote-first approach isn’t just better for individual focus but for defining groups as well. Let me explain.

Before we went remote, engineers effectively had to choose between 100% open environments and 100% solo work (if you wanted to use one of our booths, for instance), making it hard to communicate with just a specific set of people—say, those on a particular project. Granted, we had pods of desks in the office (to cluster groups around specific projects), but that strategy only went so far because it was still operating in a sea of other pods in an ultimately open office.

Compare that all-or-nothing situation to our remote-first approach. On Zoom, and with the support of a few other tools like Slack, Miro, etc., you can specify a precise group of people whose internal lines of communication are clear and open yet receive little-to-no distraction from the outside. A true pod.

In short, remote-first lets you work with precisely those people who are important to do the work that you need to do. No more, no less.

Accounting for lost serendipity

Still, it would be naive to say that nothing’s been lost in the shuffle to remote-first. Serendipity is an invaluable benefit of shared spaces—put a bunch of brilliant people in the same room and just watch the solutions flow—and that serendipity is pretty much obliterated, or at the very least much harder to coax out in a remote-first approach.

Fortunately, there are ways to account for lost serendipity. Specifically, we have implemented a few formalized practices to ensure that people get to know other Connectors outside of their project and get opportunities to converse, interact, and ask and answer questions—and feel comfortable doing so. Let’s break these down:

a. Meeting people outside one’s project

It’s only natural that engineers will get to know the people on their project better than those outside it. That’s why, for each platform our engineers work on—web, Android, iOS—we have weekly, cross-project meetings that bring everyone on that platform together. 

These meetings take one of three predefined formats: “Teaching,” where someone presents something relevant to that platform (i.e., here is a specific thing and here is how you do it); “Learning,” where we present content from outside relevant to that platform (i.e., let’s see what we can learn about this new thing and what should we look at?); and “Critique,” where someone presents something they’ve been working on and gets feedback, which often turns into a great discussion. Each of these brings people together who otherwise might not be.

b. A culture of asking and answering questions

“Critique” platform meetings are an excellent opportunity for people to ask and answer questions, and there tends to be a lot of engagement in those sessions. But that alone does not fill the gap left by the disappearance of in-person serendipity. We also have other rituals, such as cross-pair code review, so that even within your project, you’re getting exposure to perspectives outside your pair.

But the forum in which to ask and answer questions is only one half of the story. The other half is the culture that makes it okay and even encourages to do so. To drive the latter, we highlight and promote examples of teaching and learning wherever we can, socializing the value company-wide. This includes our rituals of kudos, manager katas, demos, cross-project sessions, cross-platform council, AMAs, all-hands, and more. It’s as if we want to clarify, “It’s okay to ask something, to put something out there. In fact, it’s more than okay.” 

Whether it’s because of our efforts at promoting the value or not, we’ve seen an uptick in “serendipitous” conversation on Slack, especially on the platform channels, which pre-remote and pre-pandemic were virtually silent. For those channels—web, Android, iOS—there used to be little more than just a random automated announcement. Instead, there’s actual discussion around technical questions and best practices, which suggests that the flow of conversation is alive and well rather than problems going unsolved and would-be discussions staying silent.

c. Balancing serendipity and focus

In a way, we now benefit from the best of both worlds: the ability to do focused, low-interruption work at home and the ability to join the conversation online when needed. The slight increase in “conversational friction” of a remote-first approach is a good thing: not only is the asynchronous posting of questions to Slack less of an interruption than just tapping someone on the shoulder—but also need to write the question forces people to formalize and think about it a little bit more, which makes the interaction more efficient. That extra bit of friction can even be just what someone needs to figure out how to solve it themselves.

d. Get it from an expert

One final thing that we get in exchange for a reduction in serendipity is a reduction in the randomness of who people ask for help. Let me explain.

A remote-first approach increases the distance between you and the person in the office you might have asked for help—say, the person sitting behind you. And while there’s a cost to that loss of proximity and ease, we’ve also made it less random who you ask, since the distance between you and everyone else is now the same. There is no “person behind you.”

Put differently, you’re now more likely to get help, not simply from the person nearby who may know a bit more than you do on the issue, but from the best person at the company for that particular question—the subject matter expert. Putting your question to the appropriate platform channel will usually solicit the expert(s) to respond or weigh in and course-correct a discussion. 

So while there’s a slightly bigger barrier to asking your question in the first place (which is good—see part C), the audience you’re asking is a lot bigger than it was before: instead of the three or four people who happened to sit behind or next to you, you now have 30 or 50 people who are available to help, including those who know that issue best.

In aggregate, that means everyone is getting better (more accurate, more concise) answers to their questions, improving the flow of knowledge throughout the organization.

It would be a lie to paint a picture that the shift to remote first has been perfect because it’s rife with challenges. But the most significant learnings and accomplishments come from these challenges and, more importantly, overcoming them. And in this case, that accomplishment is Connectors doing their best work and defining how they do it.