Transitioning to a remote software engineering team

Remote work is nothing new, but the rapid growth of the COVID-19 pandemic in 2020 spurred many businesses — including Fender Digital — to implement or expand work-from-home programs. Engineers, for whom a large portion of work activities were already online (version control, cloud infrastructure, Slack, etc), may not have seen a tremendous change in their day-to-day operations. For some parts of their job, however, and certainly for engineering management, the physical separation of remote work presented challenges to the more frequently interpersonal aspects of the job.

We had some experience with one-day-a-week home work, but that was mostly a way to remove distractions and allow for greater focus rather than the entirety of our workflow. Zero office meant a complete rethinking of how to delegate tasks and organize our time. Below are some strategies that have proven effective for the Fender Digital DevOps team’s switch to full WFH.

Get out of the way

Suddenly lacking the ability to informally check in with one’s direct reports via desk drop-ins could tend to inspire overcompensation. We certainly wrestled a bit at the beginning of this journey with trying to find the best way to keep updated on what each of us was doing, if assistance was required, etc. Zoom fatigue was real.

Our engineers, however, often do their best work behind focus and a lack of interruption. It may have seemed counterintuitive that with even less direct contact between levels of the team, we shouldn’t try to regain some of that contact through digital means. We found that trying to completely replicate in-person communications via online methods resulted in a volume of overhead that actually left us with less time for hard engineering. It was important that we not try to completely mirror old processes, but develop new ones native to full WFH.

Of particular concern was how to educate one another on new tools we had developed, processes that had been implemented, and changes to existing functionality or infrastructure. During office work it would have sufficed to simply call out over one’s shoulder to the rest of the desk pod, “hey y’all, I moved the hostname variable definition into the DNS module.” Even if the particulars didn’t stick, there was enough floating awareness that we could recall to ask later if needed: “Hey Taylor, where did you say you moved the DNS hostnames to?” More complex topics like operations for newly-deployed applications could be a huddle and reminder that for refreshers, the process was documented in the wiki.

With everyone being physically separate, it was slow and difficult to try and find time to schedule a Zoom for every single completed task. Notification of small changes via Slack might sprawl when clarification was needed, and though searchable, recalling informal information would become an exercise in frustration as we ploughed through emails as well, trying to remember where something had been presented.

Fortunately, our team is all in more-or-less the same geographical region. Our solution, then, was to set up a standing Zoom on Monday mornings where we could present the previous week’s accomplishments, talking over the tricker or less-obvious aspects, asking questions where depth was needed, and taking notes in each engineer’s preferred style for easy recall. Consolidating these previously impromptu knowledge transfers into a formally arranged, but open format also reduced the number of interruptions throughout the week allowing for greater periods of contiguous focus.

Be available

Being hands-off doesn’t mean disappearing, though. Collaboration between management and engineering is essential to keep time organized and priorities on track. As a manager, I consider it an important part of my role to keep the wheels turning and certainly not be a hindrance to the engineers. This means being available to assist and coordinate without causing a wait. I’m a hawk on my Slack notifications. Distractions are real, so gaps do happen, but I make every effort to respond as quickly as possible to preserve momentum.

We may soon pilot an “office hours” period each day where we have our personal Zoom running constantly, the meeting link pinned to our Slack statuses. During that window, anyone would be able to jump in for a conversation in an attempt to regain a small degree of the flexible informality of stopping by someone’s desk for a quick chat. Limiting it to a time window would ensure that it isn’t overused.

Prioritize communications

In order to stay organized, communications should have an appropriate channel. Disseminating information in the wrong place can make for difficulty in understanding and frustrating retrieval. We’ve found that the following categories work best for us:

Slack:

• Small, quick notifications and requests on INFO-level logging
• Events that require urgent attention (may break out to other channels as needed)

Zoom:

• Subtle / complex topics
• Deep dives
• Brainstorming

Emails:

• Durable, natively threaded
• Lacking the urgency of Slack / Zoom topics
• Most communications outside the Engineering cohort

Voice support

Working remotely means we’re not as visible to each other. It is important to let one another know, explicitly, that we are all still all supporting each other and the team’s efforts.

One of the ways I try to do this as a people manager is by being what an old boss of mine called “the B.S. umbrella.” Requests can come in from everywhere, at inopportune times, and with what we will call “lopsided” prioritization. I have communicated to other team leads that anything that will take more than 5 minutes or whose level of effort is not well known should run through me so that we can schedule and balance effort appropriately. The rest of the DevOps team knows that if they’re getting inappropriate out-of-band requests, they are empowered to say no and/or send the request my way. This leaves room for attending to the crucial drive-by requests when they do occur.

Putting this level of trust in your team is a well-deserved confidence booster. They know they don’t have to “look busy online” — managing time and maintaining an appropriate workload are very much functions of the job, as is taking breathing space when needed.

Keep clear goals

As much time as I’ve spent talking about loosening strictures, it is important to keep things on track. We use a kanban board to manage our workflow. Some tickets come from larger projects dictated by larger business priorities, while others are submitted by engineers themselves. Hands on the keyboard also means boots on the ground, which is the right position to be in for knowing what needs attention from a nuts-and-bolts standpoint. Engineers are expected to keep their swim lanes full — while we don’t track points, we set an upper limit for number of tickets at any one stage. We have found that this strikes the right balance of momentum while not being too rigid — stress is not productive. A weekly planning meeting allows management to assign tasks that are business priorities while leaving time for engineer-initiated work.

Allow for distractions

We’re still getting used to the all new and shiny distractions that working from home can bring — package deliveries, pets, kids, plague of locusts, land mine removal — a lot can happen that wouldn’t if we were all working from an office. Allow for this. When we started working from home, we tended to apologize a lot if we had to step away suddenly to investigate a loud sound or attend to an emergency with one of our smaller companions simply because it’s not something we would have had to deal with in the past and it seemed unusual. It happens. If we’re gracious and understanding about it, we allow the space for it to become part of the fabric of working from home, thereby reducing any stress or stigma associated with it.

Stay Flexible

Keep in mind none of this should be taken as hard and fast. Your organization may use different products for chat and video. We still have Slack threads that stretch on, filled with screenshots and code blocks. The important thing is to try and heel close to these guidelines in a majority of cases, which will allow your team the flexibility to have the occasional “clown car” communication.