Announcement
Bearer entered into an agreement to be acquired by Cycode, the complete ASPM.
Learn more ->Cross icon
<- Back to the blog

How to make remote a success

A couple of weeks ago, I attended the P9 Founder Summit in Malta organized by Point Nine Capital. One of the workshops was about remote work. Soon after, I led a webinar for the #p9family and I thought I would share our experience at Bearer thus far.

It's all about sharing and communicating

When you are small and in the same office, it's pretty easy to be aware of everything. The whole team spends a lot of time hanging out together—having lunch, grabbing a coffee, having discussions, and making decisions very quickly. As you scale up, more discussions take place, more decisions get made, and it becomes harder to keep up. You might even become successful enough that your office expands to a second floor or even a new branch in a different country.

At this point, processes are put in place to improve that internal communication. They are best practices that everybody ends up doing, but often after the fact. When you are remote-first, those processes need to be put in place from day one.

I've been lucky enough to be a remote worker for most of my career. Even my first internship was as a remote worker! My last experience at FreeAgent taught me a lot, and I'm applying many of those insights here at Bearer.

Remote as a first-class citizen

I, as Co-Founder and CTO, am myself remote most of the time. I'm visiting the Paris offices for customer meetings, board meetings, conferences, and so on 2 days every 2 weeks on average. I think it's very important for people to see that remote is something we really believe in and view us as an example of how it can be done right. I've attended TechRocks and during one of the talks, Julien Dollon, Director of Engineering at Oracle gave this tip:

If you want remote to work, start by cutting off the head

For him, this meant being the first to work remotely, while the rest of the team stayed in the office.

When the chief is remote, all of a sudden everybody is remote and everybody starts writing down everything. What used to be ephemeral and on a whiteboard became written down and stored.

That's what I saw at FreeAgent too, and I think that's an important part of the process that shouldn't be neglected.

Write down everything!

Select a shared language. For us, that's English. All public communication needs to be in English. Even as French founders, this is something we have done from day one and that means that anybody can look back at why we've made a particular decision.

Use Requests for Comments (RFCs). The Open Source community has a lot of experience in being remote-first. The need to share information while working asynchronously from different timezones is no secret. Every decision made within the project needs to be documented and approved. When someone looks back on it later, they can understand what led to a particular technical decision. Here are a few examples:

Build a Knowledge Base. Having a meeting? Learning something new? Retrospective? How-Tos? These need to be documented and shared! My not-so-secret goal is that ultimately, everything that is in the knowledge base will be turned into a Blog Post like what we did with Infinite Scrolling Pagination with Rails.

Every discussion longer than 10 messages in Slack needs to trigger a call in Zoom and a summary in Slack or the Knowledge Base.

Define your Culture, Vision & Mission. Every employee should be able to easily find the Culture, the Vision, and the Mission of the company. It keeps everyone working toward the same, shared goal and reminds us all what matters most as a company.

A screenshot of our Notion workspace.

Organize Weekly Demos. Every week on Thursday at 5 p.m. CET we gather together and answer these questions:

It's recorded and pushed to YouTube. If someone is off, in a timezone that makes it harder to join, or would like to come back to it later, they can watch it.

Send Out Weekly Notes. At the beginning of the week, send out a note to the team that recaps the week before and the goals for the coming week. Use the weekly demo as a foundation, and cover the following:

Make everyone feel connected

Connect in person. As a remote-first company, we spend most of our time reading our colleagues rather than hearing them. Some team members aren't native English speakers, and sometimes if you don't know the person well it can be easy to misinterpret the intent from their writing alone.

That's why we believe in getting together in-person at off-sites. The last one took place in Portugal.

This also means that you shouldn't expect to spend less money by setting up a remote company if you want to do it right.

Share a coffee break. When you are all in an office, you have those coffee machine moments. You discuss things like what you did last weekend, what you are up to outside of work, and so on. These moments are an important part of getting to know one another. At Bearer we put one on the calendar each week, but I also encourage the team to open up a meeting in our #coffee channel whenever they like.

Conduct smarter meetings. Meetings are expensive. Not just in the time they take, but also in the disruption of everyone's workflow before and after. Make sure to use this time wisely.

Before a meeting, send out an agenda to give everyone a chance to contribute. Whether that is an RFC, a Google Doc or a Notion note, there needs to be something sent beforehand. After the meeting, summarize in the outcome and list the actions that should come from it.

Perform daily check-ins/check-outs. It's important to share your progress with the team. Usually, that happens during a daily standup. While this is not mutually exclusive, some squads at Bearer do catch up every morning. What started as a squad initiative is now part of the Product & Engineering routine. We use Geekbot to allow each team member to answer the following questions each day:

These questions help us measure not only productivity, but also the spirit and morale within the Team. We also encourage people to publish their learnings of the day by answering the question:

What have you learned today?

Tools we use

Like other remote companies, we rely on many tools to help with all of this. Here are a few that we've had success with:

Zoom and Slack are a great foundation to start with. You can trigger a call within Slack using this command /zoom and jump directly into a call for a pairing session, right from where you are.

Geekbot to trigger the checkin/checkout and to get a feeling about how the team is doing.

Notion is basically used as an entry point at Bearer. Everything you need to know is already there. GitHub is used for our code and as such is a great tool to keep track of the technical decisions (RFCs).

Geckoboard and Redash are great to share the metrics to the Team. It's important that everybody has access to the same level of informations that drive business decisions.

Miro is a great replacement for whiteboard and has the advantage that you can get back to it at any point without the fear of erasing somebody's else diagram by mistake.

Clocker is a menu bar on MacOS and that shows you what time it is in everyone's locations.

We're also considering a few more like OfficeVibe and 15Five to measure the Team happiness which is really important to us.

There's always more that can be done

We are only at the beginning of our journey. We will surely make mistakes along the way, but we will continue to learn from them.

Something that is working today may not work tomorrow as your company grows. You will need to adapt, and I'll continue to share our processes around and commitments related to remote work here at Bearer.

For instance, right now, we are mainly in the European Timezone and we ask people to have at least 6 hours overlap within that Timezone. That's a decision we've made intentionally to avoid loneliness and isolation. We also feel like that's the best way to be effective, at least at our stage. This might change later as more team members join in other timezones.

The Bear Den
Share this article: