Remote Hustle in a Hybrid Environment
If Covid-19 has shown us anything, is that communication is not easy. With more and more companies adopting hybrid or fully remote models, we’ve run into a new set of problems, most of which we were not prepared for. And while remote work may be what keeps SecOps people awake at night, it is the hybrid model that could kill most companies’ remote work desires.
The pandemic made the video call necessary for meetings. Suddenly we were forced into a hybrid environment, some remote, some in the office. Even with the unavoidable remote situation for those at home, we kept doing the same things; the only difference was that we were in a video call.
After the first bouts of the pandemic, the hybrid model stuck at Mercadona Tech. And while our quality of life improved due to the flexibility gained, some of us didn’t fully realize at first the changes this would imply.
The water cooler problem
We’ve all seen it. While at the office, Alice goes to fill up her water bottle. She finds Bob, who fills her in about last week’s problem. They go back and forth and plan the following steps to prevent further occurrences. Then she goes back to her workspace, and in the way, she tells Charlie that last week’s issue is solved. Then she sits and continues working. All is normal until here except for Dan, who is working from home and is still thinking about last week’s issue and how to solve it. And he will keep trying to fix something that is already solved until he is updated in the next sync meeting. And I’m not pointing fingers. It happens to us, also.
At the SRE Mercadona Tech team, we like to huddle and help each other. There is a high alignment level and great context sharing, which avoids knowledge silos. You can see us discussing issues at our workspaces, the kitchen, or even while having a bite outside the office. But as we adopted a hybrid model more and more, we saw the flaws in our behavior.
Unknowingly, we isolated any remote coworkers by updating them after the discussion had already ended. This was happening so consistently that we tended to work from home only whenever we had tasks that we were going to tackle single-handedly, making even more significant the isolation issues.
Remote work is usually associated with an asynchronous model, while being in the office is traditionally related to synchronicity. However, it does not have to be that way. You can just as well be asynchronous while in the office, each person picking individual tasks and pair-program synchronously with a coworker, each one working from home. In the end, it is just a matter of choosing the suitable model for the right task.
As we are now expanding to Madrid (We are hiring!), we knew this was a critical issue if we wanted to be scalable. We had to find a way to work remotely or locally without distinction. There should not be changes in behavior whether we are remote or local. So the first thing we did was look at what other company teams were doing.
Paving the way
The first step towards being more remote-friendly was to move our conversations to a public channel in the company slack workspace. To avoid drowning the channel in disorganized information, we heavily use threads and slash commands that output templated messages whenever we need to transmit necessary details.
We also adopted mannerisms like specifying via slack message whether we were online or not to mark our availability.
The idea has been to have open discussions even with people outside our department. It had worked for other teams inside the company, and we find it fruitful for us.
Not just changing, but improving
As the adage says: “spoken words fly away, written words remain,” but if we had one thing clear was that we did not want to get bogged down by endlessly writing documentation. Here is where the often underrated fuzzy skills shine. It’s not easy to write excellent documentation, and that goes for every level, from meeting minutes to pull requests and API documentation. There is immense value in a concise, well-written document that gets to the point while giving all the context you need. We’ve all been in a company where the new hire asks about outdated documentation on some piece of tech, and the response is: “yeah, that was written a while ago, just ask X person.”
To improve and fast-track remote onboarding, we wanted our documentation to be:
- Consistent: with familiar structure and patterns
- Relevant: the most critical content that addresses the most common user needs is the easiest to find
- Findable: the content is easily accessed through search or hyperlinks/indices
And again, this is about all levels of documentation. For everything documented, it should be local whenever possible and as concise as it can be while providing the necessary context. You can find a trove of information about documentation writing, for example, in the book “Docs for developers” and the “Gitlab Documentation guidelines.”
Is there anyone out there?
In the end, being on a team is more than co-writing a vault of documentation and sharing context. It is about having empathy for your coworker. Ask yourself:
- Could it be beneficial to my coworkers if I communicated/documented what I’m doing right now?
This goes both ways:
- Do they need to know right now? Does it warrant their full focus?
Tech Gurus will tell you that you need a highly aligned and coordinated team to be successful. I’d say: care about your coworkers, foster your relationship with them, and the rest will come.
