Five lessons from the mistakes of a remote-work early adopter

I know, I know. There’s been a lot of discussion – some may say too much – about remote work in the last two years. And, while there’s no denying the pandemic quickly and radically changed the office-centric status quo, the move away from super-centralised workforce was already underway.

In fact, according to the The Organization for Economic Co-operation and Development (OECD), more than 30% of people in Sweden, Finland and the Netherlands were already working from home at least sometimes in 2019, as were about a quarter of their counterparts in the United States. 

While the pandemic didn’t cause the shift to remote work, it certainly accelerated it. It also greatly expanded the number of roles being performed from out of the office. But working from home isn’t a new phenomenon, and as such, there’s a lot to be gleaned from those of us who’ve been doing this a while, because we’ve already made – and learned from – all of the mistakes. 

When I founded my company back in 2016, I had no specific plan to hire remotely. Like most startups, I got an office in a nice neighborhood of a major city (Paris, in my case) thinking it would help in recruitment efforts. For some roles it was enough. But for engineers, the competition was too intense. We simply didn’t have the budget to hire candidates with the level of seniority we were looking for, and as a startup, we had zero cache to leverage. We had to look elsewhere to find the talent we needed at a price we could afford. Eventually we made our first remote hire, a digital nomad who was residing in Chile. 

We learned the first lesson pretty quickly: 

Resistance to time zones is futile

Our first instinct was to make our engineer in Chile adapt his schedule to French working hours. A six hour difference may not sound that bad, but starting your day at 3am sure does. He was a good sport and tried to make it work, but after about 2 months, we gave up and, instead, embraced asynchronous communications. 

Like many in the same situation, we implemented tools like Notion and Slack. We were still a small company and even as we grew, slowly, our remote hires were strictly in engineering. There was a bit of a learning curve, but the processes and structures that proved effective had time to develop fairly naturally. 

But then we started scaling, fast, and we learned lesson two: 

Fighting the natural desire for face-to-face communication is a necessity

While we were a small team it wasn’t as obvious, but as we accelerated our hiring, adding different roles to our increasing remote headcount, we couldn’t help but notice that people wanted to meet. All. The. Time. It’s understandable, especially for those who had never worked outside of an office before.

They were used to just walking up to a colleague to ask ad hoc questions and having impromptu conversations by the watercooler. They wanted to replicate this experience with endless virtual meetings. Not only did these interfere with productivity, they eventually burned people out of video calls altogether, so those that needed to be constructive were far less so. 

Fixing this issue took a bit more than just telling people to use Slack and Notion instead. Those platforms had their own issues, which we’ll get to in a bit. What we had to do was build a system that would satisfy that need to meet efficiently and effectively. Thus our “Cadence” system was born. 

Cadences aren’t the same as meetings. They are regularly scheduled, whether daily, weekly, monthly, etc., and they come in various forms such as one-on-ones, town halls, weekly touch-bases and quarterly all-hands. Also, particularly important for a company with a highly-distributed workforce, all cadences are live. This differs from meetings, which can be ad hoc and asynchronous. 

Determining whether or not a cadence is necessary requires establishing whether it will further one of a set list of purposes: synchronisation (ensures alignment and accelerates delivery on goals), growth (encourages bonding, alleviates frustrations and motivates teams), learning (fosters an environment of constant learning and information sharing), focus (helps make sure decisions happen day in and day out) and planning (enables analysis and adjustment of roles, duties, etc.).

So, now we’re having fewer pointless, time-wasting meetings, which is great. We’ve got people using Slack and Notion, and that’s making everything seamless. Or not. Because as we grew our team with more people in more places, we learned lesson three: 

Adjust for – don’t just accept – the limitations of your systems

Our Slack dependence was already firmly in place when we started realising that it was not, perhaps, always the best solution for our needs. After all, it’s built specifically for synchronous communications, so people are used to dashing off quick questions and getting immediate responses. When you’re small this is OK, but the more we grew, the more it became an issue. While not all of the channels were problematic, some were getting way too noisy. For example, the five people we had in HR and finance were getting bombarded with asks from the entire 165-strong staff, which, to them, felt like the impact was that of a category five hurricane.

There was no question that we needed to hack Slack, or at least some of our Slack. So first we exported all of the data to figure out where the deluges were. After identifying those areas, we made modifications that allowed it to function more like a project management tool and less like an unregulated chat room. We did that by building a load balancing and ticketing system. 

With that system, we stopped messages going to an entire channel and instead, channeled them through a different node (i.e., we set up one flow to create the ticket through our project management tool, Linear, with notifications through Slack and another that was 100% through Slack). The sender would get an immediate response, albeit an automated one. Not only does this response indicate “message received,” it points to where the answer might already be found. It also provides assurance that there will eventually be a response, which helps alleviate pressures stemming from the gap between expectation and reality when it comes to immediacy. 

The fact that there are a wide variety of individual differences in styles, expectations and preferences for communications leads us to to lesson four:

Protocols should be clear, codified and applied equally to all

Humans are excellent at miscommunication and misunderstanding. The problems this causes are amplified when you’re working across cultures and in non-native languages. The best way to mitigate these issues is to remove as much ambiguity as possible, and you do that by establishing rules and ensuring everyone knows and follows them. 

At Livestorm, we’ve made our communications protocols an important part of our employee handbook and onboarding process. The less grey area, the better, so we have dos and don’ts for everything from use of emojis to when you should or shouldn’t send direct messages. Since we’re a French company with a lot of non-French (and non-French speaking) employees, we also have strict rules about where it’s OK to write and speak in French versus English, which is the primary language used throughout the company. This helps stave off feelings of alienation or simply getting left out of the loop. 

And that last point, being in the loop, brings us to the final lesson I can impart from my experience of being remote before remote was de rigueur: 

Empower – but don’t force – people to get together IRL

In the context of office or no office, there are three types of people. First, there are those that thrive on being fully remote, perhaps because they’re more productive when they can work without interruption or they just prefer to be close to or at home. Then there are those who prefer being in an office, possibly because they like the energy or feel they perform best in the company of others. Then there are those who enjoy the hybrid model that allows them to get out of the house or not, depending on their mood or needs that day. 

I want to make sure all three types feel welcome at Livestorm, and that’s why I’ve not just kept the centralised office, but, and this is perhaps the most unique part of the Livestorm model, everyone gets a stipend that they can spend to satisfy their preferences. For some, this might be coming to Paris and working at HQ for a spell. For others, it could be paying for access to a local co-working space. 

For others, it can support entire team get-togethers in the location of their choosing. For example, earlier this year, our growth and marketing team wanted to do an offsite with the operations and customer relations teams. After all, the three had been working extremely closely, yet they’d never met. Plans were made for 25 people to meet in Barcelona. Then other teams started hearing about it and they wanted to join as well. In the end, 150 Livestorm employees (or “Stormies'' as we call them) went. Out of a total of 165 employees. All by choice. 

In the nearly five years since we made that first remote hire, the world has changed by leaps and bounds. My company was fortunate to have already learned these valuable lessons by the time the Coronavirus forced nearly every company to become remote-work friendly, and I hope others can benefit from them as well. Because the transformation is surely going to continue, and even when you’re remote, you shouldn’t have to go it alone.