On February 20, 2020, we officially moved out of our amazing San Francisco office and became an all-remote company. Few people have worked at an all-remote company before, and I frequently get questions—especially from candidates—about what led to this decision. This blog post documents our journey to all-remote.

Remote-friendly engineering

Many of our early engineering hires were distributed across the world, so we have had remote-friendly practices ingrained in our culture from the very beginning. As a result, we strongly value asynchronous written communication, personal responsibility, and autonomy; nothing else works when your teammates are in different timezones.

Distributed days

Since we were open to hiring engineers from all over the world, our engineering team organically grew to be more distributed over time. As we grew the team, it was important that we continue to be a remote-friendly place to work. In late 2018, we started experimenting with scheduled days where San Francisco teammates were encouraged to work from a location other than the office. We called these "distributed days".

This experiment had two goals:

1. Give San Francisco teammates more focus time to optimize productivity (e.g., fewer interruptions, skip the commute, etc.).
2. Generate more empathy for distributed teammates by having San Francisco teammates rely solely on written communication and video chat instead of in-person conversations.

After doing this a few times, we surveyed the team to see what everyone had learned. Here’s a summary of feedback we collected in early 2019:

• Empathy
  • Don’t be late for a video chat.
  • Write down meeting notes so anyone who wasn't able to attend can catch up and participate in the conversation moving forward.
  • Have discussions and document decisions in public Slack channels or GitHub issues.
  • Use headphones for video calls to avoid echo.
• Productivity
  • Some people were more productive due to increased focus time and time saved not commuting.
  • Others were less productive because their preferred work setup (e.g., external monitors, nice desk, nice chair) was at the office.
• Conclusions
  • We don't need to continue having coordinated distributed days to achieve productivity. If individual teammates want to periodically work from a different location, they should do so.
  • Distributed best practices should be documented and practiced as part of our culture.

Remote-first

In the middle of 2019, we decided to formally communicate to the team that we wanted Sourcegraph to be a remote-first company.

In practice, this meant:

• There was no expectation that teammates within commuting distance of our office needed to show up at the office on any given day.
• We were open to hiring remote teammates in non-engineering roles (and we hired some soon after).
• Existing teammates in San Francisco could choose to move to a different location in the world if they wanted (and a few did).
• We stopped flying remote candidates to our office for interviews.

We made this change because:

• Remote-first reflected the reality of the team—it wasn't a big change.
• Remote-first was a huge benefit for our teammates, allowing them to live anywhere they wanted and not have to commute. This was especially valuable for teammates with families.
• Remote-first gave teammates and candidates even more confidence that we were committed to maintaining good distributed team culture.

All-remote

Near the end of 2019, we decided to become an all-remote company and get rid of our San Francisco office entirely. As our team grew, we didn't want to create an office subculture that made our distributed teammates feel second-class; we wanted to treat everyone equally. We knew that continuing to have an office would be an increased risk to our remote-first culture, so we decided to go all in.

Once this decision was made, we needed to:

• Update our benefits and perks so they made sense for an all-remote team (e.g., we removed our lunch benefit for San Francisco teammates and paid for every teammate's home internet instead).
• Give everyone a budget to set up their home office and/or work from a coworking space so everyone would have a productive place to work (as we had discovered was important during our distributed days). Check out some of our home offices!
• Create explicit travel budgets so teammates could meet up regularly (we supported travel before this transition but the budgets weren't well defined).
• Update our employee handbook to codify all of the communication tactics we had learned as a remote-first team.
• List, show, and negotiate a sublease for our existing office space, and get a new minimal office address for mail, as well as state and federal paperwork (we chose to get a desk at a coworking space near our old office).
• Pack up all our stuff (office supplies, company swag, banners for events, furniture, art and wall accessories, spare electronic equipment and cables, food, and everything in between) and decide whether we should try to store it (and if so, where), sell it, or distribute it to team members.
• Update all our financial and legal accounts, contracts, and more.

Tradeoffs

We love all-remote, but it doesn't work for everyone (just like an open-office floor plan doesn't work for everyone). Working remotely gives you extra freedom and flexibility, but also requires extra discipline and personal responsibility. Certain things that happen organically in an office environment (e.g., informal conversations at lunch), need to be explicitly planned (e.g., by scheduling small "water cooler" meetings with no agenda, or scheduling 1:1s between random teammates using a tool like donut.com).

We are committed to supporting all our teammates to help them be successful. Check out our tips for working remotely.

If you have any questions about all-remote teams, join us during our Developer Meetup on Tuesday, May 7 2020 at 10:00 AM PDT, and I will be happy to answer them.