The phases of remote adaptation

The phases of remote adaptation

As teams grapple with transitioning from a colocated environment to a remote one, it’s common to see differing levels of adaptability. For some, the transition is fairly smooth, as a remote-first infrastructure was already established. For others, the shift is thoroughly disruptive.

The amount of disruption is generally tied to two maturity factors: culture and tools.

To better understand this, we’re using this page to detail the phases of remote adaptation.

  • Phase 1: Skeuomorph
  • Phase 2: Functional
  • Phase 3: Asynchronous
  • Phase 4: Intentionality

In the GitLab Unfiltered video above, Darren (Head of Remote, GitLab) and Luke (Founder, Friday) unpack the phases of remote adaptation, and discuss projections for societal shifts related to remote work.

It’s important to frame one’s transition to remote in terms of phases, as opposed to an all-or-nothing approach. Breaking adaptation down into smaller chunks creates less overwhelm. The goal for any suddenly remote company should be to graduate from one phase to another in a sustainable and efficient manner, instead of what will otherwise feel like a massive leap from nothing to mastery. This is iteration in practice.

Phase 1: Skeuomorph

GitLab all-remote laptop illustration

In Phase 1, a remote organization will look to imitate the design, structure, norms, ebbs and flows of an office environment. The primary goal is to merely continue to operate the business, but remotely.

Like for like scenarios

For example, a typical hallway conversation will become a one-on-one direct message, and a pre-planned meeting at the office will be replaced by a video call with the same participants and preexisting meeting hygiene.

Organizations in Phase 1 will attempt to copy the in-office environment and paste it into a digital, remote environment. Replicating the in-office experience, remotely, is a telltale sign that an entity is in Phase 1 of remote adaptation. Here’s how Sid Sijbrandij, GitLab CEO and co-founder, explains it:

The first phase is this: instead of having your meeting in a conference room, you have it on Zoom. Your hallway chatter — instead of having it in a hallway, you have it on Slack. That’s the first phase of remote. You’re not taking advantage of what remote provides.

In the second phase of remote, you use what remote enables. For example: instead of just having a meeting on Zoom, you also record it, so the people who couldn’t be there [live] can still watch it.

Instead of using Slack to have a direct message conversation with someone about work, you have it in a public channel so people get context.

The “Whiteboarding Fixation”

The inability to project beyond Phase 1 is crippling. An organization fixated on questions such as “How do I replicate the whiteboarding experience, remotely?” is failing to see the potential of later phases. The above question is not altogether useful. Focus on outcomes, not mediums. A better series of questions is as follows.

  • Have we documented what positive outcomes came from conventional whiteboarding sessions in the office?
  • Now that we are able to operate asynchronously, is there a more efficient, inclusive, and robust way to achieve the same positive outcomes?

A company which remains in Phase 1 indefinitely will struggle. While it is not practical to assume that all leaders will understand that there are different ways to achieve outcomes (referencing the aforementioned whiteboarding scenario), the simple act of asking the question and seeking new tools, processes, and expertise is a prerequisite to entering Phase 2 and beyond.

Learn more in GitLab’s guide to remote collaboration and whiteboarding.

Recognizing opportunity

Most in-office procedures translate poorly to remote, but the more critical issue is this: remote creates an entirely new landscape in which to conduct business, and failing to maximize that opportunity will ensure that your business is less efficient than a competitor which moves into later phases.

Some businesses will choose not to invest time, energy, and resources to moving beyond Phase 1, declaring remote work a failure. These entities will place the bulk of their efforts in moving back into an office — going back to what they were accustomed to.

Phase 2: Functional

GitLab all-remote illustration

Entering Phase 2 is simple. It begins with leadership asking a fundamental question: “What if we didn’t do things the way we’ve always done them?”

Remote enables you to function differently than a conventional colocated company. It challenges preconceived notions and it provides new opportunities to increase efficiency of work and agency of people.

Evolving processes

Companies in Phase 2 will begin to take advantage of technology to replace things which were manually done, or not done at all. For example, a company will begin to:

  • Record all meetings and automatically upload them, plugging knowledge gaps created by undocumented gatherings.
  • Attach a Google Doc agenda to every business meeting, writing questions, answers, and conversation down in real-time as the meeting transpires so that knowledge is archived for reference, and for viewing by attendees who are not able to attend live.
  • Converse about a work topic in a public chat channel instead of a private channel, so that more input may be gained.
  • Documentation will occur in most instances, but there is no overarching guidance on how to document, where to contextualize takeaways, who to share documentation with, and how others will ever find anyone else’s documentation.

Phase 3: Asynchronous

GitLab all-remote team

Phase 3 is marked by a company’s comfortability in completing work without mandated synchronicity.

Maximally efficient remote environments will do as little work as possible synchronously, instead focusing the valuable moments where two or more people are online at the same time on informal communication and bonding.

Embracing forcing functions

Synchronous actions aren’t seen as bad or necessarily inferior, they simply are not the default. Instead, team members in a Phase 3 environment will do the following:

  • Hatch an idea or ask for input in an issue tracker rather than a chat tool, meeting, email, or other private forum where information is immediately siloed and fragmented.
  • Work handbook-first, thereby documenting protocols, updates, solutions, or guidance in a single source of truth first. Only after documentation occurs should dissemination occur, creating a culture where answering with a link is expected.
  • Instead of simply having stacks of unsorted issues, you categorize in a systematic way using roadmaps and milestones.
  • Expire your chat (Slack or Teams) messages after 90 days, creating a forcing function to only use Slack for informal communication, thereby creating a saner and healthier atmosphere.

Learn more in GitLab’s guide to using forcing functions to work remote-first.

In the GitLab Unfiltered video above, GitLab’s Head of Remote discusses the topic of reenvisioning Slack’s potential as an informal communication tool, and forcing functions to create a more asynchronous work environment. A portion of the discussion is transcribed below.

We expire all of our Slack messages after 90 days. So, nothing on Slack can be queried after 90 days. This serves as a forcing function for all work to begin where it needs to end up, which is in GitLab.

Everyone understands that if you were to start a project in Slack, it wouldn’t work out well for you, as you won’t be able to search for any context or prior conversation after 90 days.

This counteracts the human instinct to start a project in a chat tool. It forces us to ask a simple question: ‘Where does the work need to end up?’ (Answer: GitLab)

This structure also solves another common problem with remote teams, which is people tend to feel isolated or disconnected from people. Given that we cannot practically use Slack for long-term work projects, we maximize its use as a tool for informal communication. Our team has access to a plethora of topical channels — fitness, music, mental health, parenting, etc.

Using GitLab for remote collaboration

Leadership can create a more humane atmosphere by leaning on a tool (or tools) that enable asynchronous workflows, thereby reducing meetings and creating more time for focused, deep work. GitLab uses GitLab to accomplish this.

GitLab is a collaboration tool designed to help people work better together whether they are in the same location or spread across multiple time zones. Originally, GitLab let software developers collaborate on writing code and packaging it up into software applications. Today, GitLab has a wide range of capabilities used by people around the globe in all kinds of companies and roles.

You can learn more at GitLab’s remote team solutions page.

Phase 4: Intentionality

GitLab collaboration illustration

Phase 4 is marked by an extraordinary amount of intentionality, particularly in areas that are typically assumed to need minimal guardrails. The list below is not exhaustive, but showcases examples of this approach.

  • Measuring output (results) rather than input (hours). This requires a deliberate choice to not measure hours spent working, as well as a strong commitment to outlining deliverables and expectations that can be measured. This enables team members to work towards their goals in any manner they choose.
  • Hiring outside of a company’s home geography without relocating. By intentionally opening one’s talent acquisition pipeline to the globe, you assume certain risks (time zone headaches, legal and regulatory hurdles in foreign nations, etc.) understanding that the ability to hire the world’s best talent is worthwhile.
  • Structure social interactions and non-work activities. While colocated companies allow fate to dictate these interactions, remote companies look to their people group to brainstorm ideas with functional leaders and put opportunities to gather as a team on the calendar.
  • Create team building opportunities that are even grander than those in colocated spaces, such as team-wide talent shows, trivia events, show-and-tell gatherings, virtual lobbies for water-cooler conversation, global pizza parties/celebrations, and even global family-oriented chats.
  • Divest real estate before you have to. Intentional remote companies will make deliberate moves to reduce real estate costs, relying on their ability to adapt in order to create a thriving remote work environment. In other words, there is a deliberate removal of the office safety net. When you sell your real estate, or stop leasing, you have no fallback — you must create a thriving remote atmosphere, and evolve it such that it remains a best-in-class workplace.

Maturity

In the GitLab Unfiltered video above, GitLab’s Head of Remote discusses the topic of cultural maturity during an interview with Mårten Mickos, CEO of HackerOne.

An organization’s ability to transition quickly from Phase 1 to Phase 3 is dependent on maturity. Consider the below questions, all of which will be important for suddenly-remote firms forming a remote leadership team.

Cultural maturity

  • How mature is management, and are they willing to be transparent with their team on how they are iterating on-the-fly as they move between phases?
  • Are managers naturally willing to adopt a mindset of trust and empowerment as opposed to command and control?
  • Is there a natural inclination to open up a feedback mechanism to shape a company-wide transition, or is leadership’s first instinct to implement strict rules and check-ins?
  • Does management default to creating a single source of truth for processes and protocols, or are FAQs and communiques created behind closed doors and only by executives?
  • Does management seek to listen to newly-remote team members to understand what voids exist and need to be addressed? Said another way, do they default to servant leadership in early phases of remote adaptation?
  • Does management seek to maximize the advantages of a remote environment once stabilization occurs?

Technical maturity

  • Do team members have a preexisting understanding of digital communication tools?
  • Do team members have preexisting methods of accessing sensitive information (e.g. established VPN protocols)?
  • Does a company’s business operations or IT department have preexisting protocols for enabling team members from locales outside of the office?
  • Does a company have preexisting documentation for core company processes (communication, client service expectations, socializing and relationship building, onboarding, in-person interactions, expensing, working hours, metrics and goals, owners/DRIs, etc.)

GitLab Knowledge Assessment: Phases of Remote Adaptation

Anyone can test their knowledge on the phases of remote adaptation by completing the knowledge assessment. Earn at least an 80% or higher on the assessment to receive a passing score. Once the quiz has been passed, you will receive an email acknowledging the completion from GitLab. We are in the process of designing a GitLab Remote Certification and completion of the assessment will be one requirement in obtaining the certification. If you have questions, please reach out to our Learning & Development team at learning@gitlab.com.

Is this advice any good?

GitLab all-remote team illustration

GitLab is one of the world’s largest all-remote companies. We are 100% remote, with no company-owned offices anywhere on the planet. We have over 1,500 team members in more than 65 countries. The primary contributor to this article (Darren Murph, GitLab’s Head of Remote) has over 15 years of experience working in and reporting on colocated companies, hybrid-remote companies, and all-remote companies of various scale.

Just as it is valid to ask if GitLab’s product is any good, we want to be transparent about our expertise in the field of remote work.

Contribute your lessons

GitLab believes that all-remote is the future of work, and remote companies have a shared responsibility to show the way for other organizations who are embracing it. If you or your company has an experience that would benefit the greater world, consider creating a merge request and adding a contribution to this page.


Return to the main all-remote page.

Last modified March 27, 2024: Change shortcode to plain links (7db9c423)