Transitioning to Remote, Async Work

Coming up on my one month 💖 anniversary 💖 of joining the GitHub engineering organization, I'm reflecting on the challenges and benefits of remote, asynchronous teams. I've learned "remote" doesn't just mean "use Zoom a lot", "context switching" isn't the dirty word I've been led to believe and that patience is the sustaining virtue of any healthy long distance (work) relationship ☎️.

Breaking Up Is Hard To Do: Saying Goodbye to In-Person Work

For most of my career as an engineer, I dreamed of becoming that mythical thing--a remote employee. Every time the subway stalled between stations, or I dragged a heavy backpack through the hot and garbage-smelling streets of New York in August, I would close my eyes and imagine what it would be like to work from home. I would fantasize about it--comparing the compute from Brooklyn to Chelsea to the commute from my bedroom to my desk in the living room; my sad desk lunch to a homemade feast; days at the office during which I never ventured outside to afternoon walks in the park with my dog. I developed quite the romantic notion about all the perks of the remote lifestyle.

When I joined the team at GitHub I geared up to make my fantasy a reality--here it was, my chance to live the work life I had always dreamed about. I said a bittersweet goodbye to my old, in-person team and readied myself for my brand new life. I bought a new desk chair! And a little stand to put my laptop on! I was ready.

But the reality of leaving behind the physical office, the tangible company of well-known coworkers and the ease of in-person, synchronous conversations put my fantasy to the test.

I found that the things I anticipated struggling with--missing the camaraderie of face-to-face "water cooler" chats, feeling isolated or uncomfortable with being at home all day--weren't nearly as challenging as I thought they'd be. The switch from "in-person" to "remote" wasn't the hard part. Instead, it was the switch from "synchronous" to "asynchronous".

Remote Work's Secret Side: Async Work

My dreams of remote work didn't often focus on how to work remotely. But when I did think about the "how" I mostly conjured images drawn from my own "work from home" experiences. I pictured lots of video calls and constant conversation over Slack. In other words, I imagined that the pace of my days and the character of my communication with teammates would look more or less the same as it already did, just transplanted to my living room.

The key thing underlying my expectations was the idea of synchronous communication. I could imagine working without being co-located with my team but I couldn't imagine not being in constant communication with them. This was the biggest surprise and the toughest challenge of my transition.

Think about what it means to have a fully remote team. "Remote" means that team members will be located all over the world--including (shocker) different timezones. When a team is distributed in this way, your 9am is someone else's 6am. So the Slack DMs with which I anticipated replacing my in-person shoulder taps would have to wait!

This is where the nature of asynchronous work reveals itself. Instead of simply translating in-person practices into remote ones (think face-to-face convos replaced with Zoom calls), a whole new set of practices and a different type of collaboration culture are developed.

Async Work Loves Writing

When I first joined GitHub, the onboarding process of course covered the topic of how to operate on a remote team--We write issues and PRs they said! We use our own tool to manage our workflows!

I did not understand the full impact of these practices at first. My reaction was along the lines of "Duh--I write PRs too, and I even sometimes put a description there." What I didn't understand was that the written discussions taking place through GitHub issues and in PR descriptions were the meaningful communication that made up my team's collaboration and planning. I kept waiting for the Zoom call or Slack conversation that would reveal the reasoning behind a particular unit of work or goal, not realizing that these conversations were happening all around me, on GitHub itself.

Detailed issues were being written, articulating problem statements and laying out proposed solutions. Engineers, designers and product managers were engaging in productive conversations via comments on these issues. "Work In Progress" PRs were being opened in order to demonstrate proposed code designs or bug fixes and feedback was being provided that the engineer would use to take the work over the finish line. All of this was happening asynchronously and all of it was made possible through writing.

And here's where it gets tricky. Opening a PR with minimal or no explanation, or an issue with little or no description only works when your communicating with people who already know what's going on. It only works when spoken, in-person and synchronous communication is there to fill in the gaps. But when the only way to get the feedback or support you need to fix a problem or ship a feature is through writing, that writing better be good. And good writing is hard to produce. It can be especially frustrating for engineers who excel at writing code and love the thrill of shipping and moving onto the next challenge. We don't want to slow down and articulate our thinking. It's hard to take a step back and explain the code we already wrote that does the amazing thing. "Don't you want the awesome new thing I made?!", we think. "Why do I have to take the time to explain it?!"

But the more time I spent slowing down and focusing on writing--on providing rich context for issues or laying out detailed but concise descriptions of code changes for PRs--the more I could actually start to feel myself becoming a better engineer.

Async Work Makes You Better

Why does all this writing make me feel like I'm getting smarter? Let me explain. With a synchronous team, when I got stuck or had a question (however small), I could always get someone's attention. The nature of in-person and synchronous work also meant that more people shared more context. So I didn't have to work as hard to explain myself when I wanted to raise a concern or make a case for new work. That is not the case with an async team. When the primary means of communication is written and asynchronous, you need to do three things:

Understand and articulate your question, concern or plan with all the clarity and detail your colleagues need to provide meaningful feedback or support

Get ready to be wrong

Wait

Let's dig into each of these points a bit.

Writing Means Learning

The first one comes as no surprise--when we have to write something down, it forces us to understand it better than when we are speaking to someone face-to-face. Even those of us who don't have a ton of experience writing or find it difficult to write down our thought process have likely experienced this benefit of written communication. This is also the part of writing that gets easier with time--the more experiences we have writing information-rich issues or descriptive PRs, the easier it gets.

The next two points are tougher and more painful to learn.

Writing Means Accepting Challengers

When you're putting your thoughts into writing, you're drawing a line in the sand that other people can contest. Unlike in a spoken, face-to-face conversation, you can't easily walk back your questions or claims and you can't hide behind a lack of clarity. When you write something down, it provides something concrete for people to dig into, and this means you're opening yourself up to be challenged. This can be a painful process but it can lead to a tremendous amount of growth.

For example, in the past, if I had an idea to share or an tricky bug I couldn't solve, I might have done some preliminary research and then simply pulled people aside for discussion, allowing that discussion to stand in for the hard work of articulating problems and proposing solutions. Now, I'm taking research and planning further than I might otherwise have done and taking more ownership of my work as a result.

Writing Means Being Patient

While the kind of ownership that async, written communication engenders has been so rewarding, it does require one secret ingredient: patience. Exhibiting patience can be hard for engineers who are used to in-person and synchronous work. Why this difficulty? My own past experiences working synchronously can shed some light here.

Coming from a synchronous team, I was used to getting almost immediate responses to any questions or fast feedback on proposals. If something felt urgent enough, I could literally wave my arms in the air and command the attention of my team. Not so with an asynchronous team. Waiting as a written discussion unfolds; waiting for the answer to a question on a WIP PR--this required a level of patience that I (and many other devs on in-person teams) have not previously had to exhibit.

This patience is not usually a necessary quality of synchronous work. When we work on synchronous teams, we're encouraged to take ownership of one ticket or one project at a time and diligently plug away at it until it crosses the finish line. In this scenario, any blocker, however small, must be immediately addressed. So what happens in an asynchronous environment when you hit a blocker in your code or have a question about a design or approach? Once you open a WIP PR that details your question, what do you do while you wait? You can check your email, maybe peek at Twitter (I see you). Then what?

Well, if that was the only ticket you had in-flight, you're stuck! You panic--I'm not being productive. I'm not contributing fast enough, you might think to yourself. This brings me to the last (for now) surprising lesson I've learned in these first few weeks of async work. It's okay to have more than one thing in-flight. In other words, context switching might not be such a bad thing after all.

Context Switching Isn't Bad

On a synchronous team, we learn that we're meant to focus on one task at a time. We learn to guard our time closely and defend it from distractions. Your PM wants you to fix a bug while you already have a new feature in-flight? How dare they! This kind of attitude only works when you're in a synchronous environment--when the smallest blocker or question can get immediate attention and resolution.

In an async environment, we need to have a handful of tickets or projects in-flight at a given time. When we submit a question on a PR, or open an issue that requires further discussion before work can start, we need to switch gears and work on something that isn't blocked. When we expect that the pace of our work will require us to pause work on one area and return to work in another, then we're in control of the context switching. In this way, taking ownership of more than one piece of work at a time allows us to be productive on an async team.

Once again, this can be a challenge for those of us transitioning into an async team. At first, it made me anxious to have more than one ticket in-flight. I put pressure on myself to deliver things as quickly as possible. Any delay induced a slight panic and made me feel frustrated that I couldn't get immediate responses from teammates on questions or PRs. Eventually, I started picking up more than one ticket at a time and letting myself relax and switch gears if a question on one ticket meant I needed to pause work and switch to another.

This isn't to say that there aren't some projects or tickets that are meaty or high-priority enough to warrant the solo treatment. But transitioning to async work means that we need to ditch the attitude that it is necessarily a bad thing to have ownership of more than one ticket at once.

Async Isn't Async All The Time

While its true that async work has taught me to dig deeper, think harder, take ownership and exhibit patience, it isn't always the right fit for every situation. Sometimes a question does require immediate attention. How do you know when you need help right now and when you can wait for async communication to run its course? The answer is--there isn't an answer. Sorry!

The more time you spend on an async team, the easier it gets to recognize which kinds of questions benefit from a quick Slack message and which ones don't. In the meantime, it's helpful to have an experienced buddy on the team who can help you figure out which type of communication is the best fit for you in a given scenario.

It's also worth noting that async communication doesn't replace all of the collaborative rituals on a team. Sprint planning, retros and pair programming can still characterize remote, async teams.

Async Makes Collaboration Hard, But It Doesn't Have To

Despite the benefits of the async work style, it's still hard. For those of us coming from in-person, synchronous teams, it takes a while for the async processes to make themselves clear to us and to feel meaningful. It's important for us not to confuse the means for the end. In other words, remember that the synchronous processes of Slack messages and face-to-face conversations are just one means to the end of collaboration and shared ownership. Async processes--like leveraging written communication on GitHub issues and Pull Requests--can and will serve that same function. And they'll provide the added benefits of making you think harder and take more responsibility of your own work--I know that's the experience I've had so far, and I'm looking forward to continuing to grow as an engineer and teammate in my new environment.