What I Learned From Transitioning My Company to Remote-First

tt
• Having a remote first culture really has nothing to do with where your team lives. It's all about having a certain standard of excellence for communication in your business. Some examples:t
  t
  • Is there documentation for how your company communicates?
  t
  • Does the team default to having a video call link for every meeting?
  t
  • Are all-hands meetings recorded so FTEs who miss it can catch up? What about someone taking and sending out minutes?
  t
  • Is there a framework for clear ownership and accountability in the organization? Can you within 2 minutes find out which teams are behind on goals and which team members need support?
  t
  t
t
• In-person time still matters. We fly all remote team members out to the Boston office for at least 1 week a quarter. I've heard 4-6x a year is ideal.t
  We are considering offering this as a perk for part-time employees too after their reach a certain tenure with MCt
  t
t
• Some people are just more motivated by being in-person and that's okay. It's good to support multiple types of work environments
t
• This is a perk that opens up all kinds of new talent pools

tt
• If you aren't building hardware, you can probably be remote
t
• Don't pursue it if you're trying to cut costs. That's definitely a outcome, and I would still not recommend it as it being your primary focus. Better reasons in my mind include:t
  t
  • It's good for employees
  t
  • It allows you to recruit in more diverse talent pools
  t
  • It increases productivity
  t
  t
t
• This is a very very polarizing topic. Try to understand the set of experiences the people you are talking to about this have had. Most people--especially in software engineering--have only experienced local OR remote, and often have a fairly dogmatic perspective
t
• In engineering, remote can mean a lot of different things:t
  t
  • We hired a team in India and have no real control. The code is crap and always behind on timeline
  t
  • We hired part-time contractors in the US
  t
  • We have 1-2 remote engineers and the core of the team is local
  t
  • We do not have an office anywhere
  t
  t

Based on my research and experience thus far, I strongly recommend becoming a remote first organization by improving accountability and communication norms in your company. The rest will almost happen as a by product without any nudging. For example:

tt
• You might have a long standing team member suddenly move to a new city, and then find out a few months later the outcomes are the same
t
• Or have a team member work remotely from a new country for a month and realize they still hit their goals

(These are both real examples from MC). Based on this, you become increasingly flexible until you start hiring team members you've never met in person (also happened).

On other neat thing we did was send me, a leadership team member, to be permanently remote. We figured having someone on the leadership team being remote would give me a really big stake in making sure the remote experience was as good or better than the local one. Don't let there be a dual level of team membership.