Can you migrate a company from on-premise to remote-only?

As I prepare for my talk at Digital Warriors 2020, entitled "from office to remote in 48h", I want to share some thoughts about the process of moving a company from office to remote-first and then to remote-only. This post represents what I've learned over the past eight years working at the best remote companies on the planet.

It's important to clarify that there are different stages of adoption of remote work. As a company moves towards remote only, they will go through these, and knowing the advantages is essential. It is also necessary to understand the risks.

Initially, a company is mostly, if not wholly, on-premise. The fundamental dynamics at work are that there is no trust that people will perform at the required level unless they are present in person and supervised. On the other hand, people working in these dynamics will optimize to succeed in them. So they will make sure they are visible in the office, always appear busy, and do their best to be either diligent supervisors or competent executors. Of course, not all companies have these kinds of issues. This kind of company perhaps reserves the term "work at home" to describe days where people can work without coming to the office. Working from a holiday destination is unthinkable unless people are doing so during the holidays.

The next stage of going remote is remote-first. The idea is that the company can still be partially on-premise, but the processes change to accommodate remote workers, i.e., people who work remotely all year long. This stage has been accurately described by my old friend and OK-est boss David Fullerton in his excellent post "Why We (Still) Believe in Working Remotely":

There's no halfsies in a distributed team. If even one person on the team is remote, every single person has to start communicating online.

While this point is accurate, it is not all that is needed to move from on-premise to remote first. What is required is that all the tools become remote. Today, it is much easier to accomplish this feat than a few years back (for example, many teams use GitHub as source control, and GitHub is already a remote tool. If a team has on-premise git, then access needs to be granted through a VPN. As many people are remote, but not all, there's a risk of having the company split culturally between remote and on-premise. Regular retreats or in-office rotations are necessary to keep the bonds straight. For example, we had one yearly remote and non-remote retreat at Stack Overflow. Still, other London-area remotes and I also went to the London office regularly, and this paid off handsomely in making everyone feel part of the same company.

The final stage is having fully distributed companies. While this seems like a no-brainer from remote first, it's another involved step. This step is tricky is because remote-first companies have the luxury of choosing which parts of the job will happen on-premise and which other areas can be remote. This possibility allows them to move to remote the "easier" 80% of the jobs and keep on-premise the part that is not easy to change. Logistics, such as sending off Christmas presents, is not easy if people are working remotely. Retreats become necessary to be able to know your teammates personally.

All in all, there's a clear path to move any company from the office to telework:

1. You need to trust your people and know that it is possible to have people working without being in the office.
2. Migrate the tools and affect your office's culture, so everyone works with remote-friendly applications and devices, even in the office.
3. Migrate people from the office to their remote locations while fixing and improving the tools and processes that need change to take these steps.