Going Remote (Even for the Experienced)

How is everyone doing with the work-from-home mandate? In a conversation with executive leadership at my organization, when asked how I was handling the new work arrangement, I joked that I was a programmer—I've been prepared for this my whole life. Some personality types do adjust better than others to working from home (or working remotely), but that doesn't mean there aren't obstacles to adjust to an asynchronous work arrangement—especially in the face of a pandemic that has left some feeling isolated and anxious.

At my organization, my team has been well-equipped to work remotely since its inception. In fact, due to office space constraints, we were rotating work-from-home days just to reduce office noise. One of my team members had just finished a multi-year stint working partially from Nepal, while another had worked remotely for a decade at his previous job. All of our source code is available remotely, our continuous integration and deployment pipelines have been in place for some time, and all of us are avid users of Microsoft Teams for video, one-on-one chat, and group chat communication. We even have a shared OneNote document (through Teams) that allows for some community-driven note-taking and knowledge sharing.

Even for teams with experience working remotely, there is a difference between the option of working remotely and the mandate of working remotely. Removing the option of face-to-face, in-person collaboration creates additional barriers that you have to be conscientious of. You are essentially moving from the option of working remotely to an asynchronous organization that still needs to get work done.

No team is going to be able to tackle all of these obstacles in a few weeks—building out an asynchronous organization takes time—but there are a few keys points you can emphasize to get your team up-and-running quicker.

Document the world

GitLab is a handbook-first organization. With our applications team, we are currently establishing a manual in the same spirit. The idea is to create a single source of truth for processes, best practices, and other important information as it relates to the team and organization. You want to shift left in a traditional support model, only in this case, you're shifting self-service to individual team members instead of application end users. This single source of truth for your organization will detail the best ways in which your team should communicate, escalate issues, deploy applications, switch processes, etc. in a manner that doesn't require synchronous communication and decisions-making. By focusing on the manual (or handbook) first, you create this singular source for changes in your department or at your company. Before any team member asks for help, files an issue, or makes a request, they should consult the manual first to see if there is already an answer.

For more advanced teams, if the manual is in source control, the missing, conflicting, or confusing information can be addresses via a pull request (to request changes) to the manual's source control repository, or by filing an issue in the repository's backlog. In this way, changes to the manual are done in public where they can be debated among team members.

Having a manual is great, but not everything belongs in it. People communicate on a regular basis, and with a remote team, it's not so easy to look over your shoulder and ask a team member to clarify something from a meeting earlier in the week. This goes beyond emailing meeting notes that will get lost in inbox black holes (email should be a last resort). Instead, pick a way to document stand-ups, retrospectives, meetings, and chat-conversations where a decision is made.

Our team keeps stand-up notes in a shared OneNote document. The same is true for retrospective notes (we run retrospectives after every three week iteration). One-on-one or team chat conversations or back-and-forth emails where decisions are made need to be documented as well. Chats and emails are temporal (blocked in by the timestamp) and fade into the background quickly. Collate those chats and emails into a better format that concisely details the decisions and put them somewhere that the entire team can access them. This could be a shared OneNote, a GitHub issue, etc.

Effectively documenting everything as if you were preparing it for an outside audience is paramount for success.

As an example, at my organization a request came in from several different faculty members and students for a way to better ensure that communications aren't lost in the shuffle (many more communications are going out as a result of students learning remotely). About eight different emails were forwarded in my direction. I collected them, collated them, and then produced a one-sheet document outlining the problem, the potential solutions, and some questions. I also produced some bare-bones mock-ups of the functionality, and then sent this information back. The mock-ups, the one-sheet, and the details from the emails were all collected into a section in a shared OneNote document, so that anyone on my team could review it, pick it up, and run with it. Once the one-sheet is approved for a rough draft minimum viable product, it'll be transferred to GitHub as one or more issues with task lists, descriptions, and links back to the original document.

Nothing should be left up to remembering chat conversations, emails, or Zoom calls. Document it all; Share it all.

What is your communication plan?

Have we crashed Zoom yet?

The first question in moving to a remote work arrangement is: How do we communicate? Experienced teams already use something like Slack or Microsoft Teams for chat communications (and video conferencing). Likely, your company has jumped on one of these, or uses a tool like Zoom, GoToMeeting, or WebEx. It's also likely that you're using them frequently, and have replaced in-person meetings with video conferencing.

For day-to-day communication, you likely will need a chat tool. Emails are fine, but they aren't really for times when you need some synchronous back-and-forth. Chat tools provide chat rooms (i.e., channels) that let people hang out together virtually. This isn't just good for multi-person communication, but is also great for mental health if the remote work arrangement was suddenly forced (like from our current COVID-19 pandemic).

Chat tools and chat channels increase informal communication, which is great for mental well-being, collaboration, and innovation. Just remember to document decisions and ideas formally when you're done.

Even with remote organizations that work the same hours, not everyone is going to available all the time. Whether it's lunch, a phone call, you're highly concentrating on something, or a bathroom break, there are going to be times when you're not available. Most chat tools offer a status—even something simple like busy, away, etc. Please use it. It's a good way to know that if you ping someone, they might not get back to you right away. Nobody is expected to be available immediately all the time, so be sure to keep your team aware of your status.

This is especially important for managers. It's easy with on-premise work to see if somebody is at their desk or busy. The same isn't true for remote work. Managers who are used to on premise work have a tendency to think that a lack of immediate response when the person is working remotely means that they aren't working at all, or they're off playing around instead. This is far from the truth, and managers need to be aware that remote work has the same breaks in flow as on premise work.

Limit meetings

Another part of your communication plan should be to limit meetings. It's easy to replace an in-person meeting with a virtual one. Please ask yourself if you really need the in-person meeting, or if you'd be better served using chat, email, or some other form of communication.

Generally, you should limit meetings to begin with. Meetings should be about strategy, collaboration, and innovation—not about statuses, reporting up, or other list-based communications that can easily fit in an email or chat window. This will be harder for business process people whose days are usually filled with meetings, but it's a necessary step for efficient remote work (and efficient in-person work too, in my opinion).

Limit emails

Did I say use email? Use a different tool, if you can. In a document everything endeavor, it might be best served to use chat or a shared notes document that you then formalize and post internally on something like SharePoint or an internal web site. Save emails for official communications, lengthy communications, or recaps/summaries (list-based communications) that you want to send to prevent meetings. Emails are easily lost or missed, especially when your inbox volume is high.

Limit tools

The hardest part of a large organization moving to a remote work policy is that every person and department has it's own tooling and communication stack. What video conferencing software are you using? Microsoft Teams? Zoom? WebEx? For every new piece of technology being used, it might be another piece of software to install on the end-user's computer and another set of training documents that need to be produced. It causes confusion and frustration. Have a set policy for which tools are used when and how to access them (e.g., the aforementioned documentation).

A bare minimum would be:

• One shared document repository/collaboration tool
• One shared chat tool
• One shared video conferencing solution

Individual departments and organizations might have their own localized solutions, which is fine if their expertise requires it, but the organization as a whole should embrace a streamlined approach to limit help desk support calls, limit support emails, limit troubleshooting, and centralize policy, best practices, and knowledge. To embrace multiple solutions at the organizational level will only create complexity that will overwhelm support personnel in a time when they might be needed elsewhere.