3 Lessons Remote Work Taught Me
With the covid-19 pandemic over (or under control), we start seeing a lot of companies returning to the office or adopting a hybrid work schema in its wild variations: one week at home followed by one at the office, 3 days at home followed by 2 at the office, at most 2 months outside the office per year, and so on. My preferred one: “we have an office, you’re free to use it if you want to, but we’re cool if you prefer to stay working from home”.
On that, I went to the office one of these days and I got to say it felt good! It was great going out of my second-room-converted-to-office for a couple of hours and working from a fresh and new environment. But, the icing on the cake was to meet part of my team irl and to speak to other folks I otherwise wouldn’t engage at all, due to them being from different areas of the company.
However, having to move part of my work gear from one place to the other and then commuting to and back from the office is still a downside. As I intend to give the office life a try at least a couple of times a week, I’ll have to work on a better solution, but that’s not today’s topic.
This week, when coming back home, I stopped to think about how I started working remotely, and some of the things I learned from it, and here we are.
Some backstory
Back in 2018, I was working as a Data Analyst in a remote-friendly technology company. Being remote-friendly meant pretty much that my primary workspace was from the office, but they were open to me working remotely without too much bureaucracy involved.
Back then, I worked from home a couple of times, but mostly when I had something keeping me from going to the office such as having to stay home due to some maintenance scheduled during the day, an important delivery coming, and so on.
The “working from home” was in essence, temporary, and not too many changes in the work routine happened apart from myself being in a different setting.
Fast forward to 2019. I switched jobs and was now working as a developer at yet another remote-friendly company. I had colleagues working remotely, and most of our clients were from abroad, so I was in closer touch with the remote life, even though I was still, mostly, working from an office.
By the end of 2019, I was migrating to a more product/project/managerial-focused position, and, in the middle of this process, the pandemic hit. March 2020 was a turbulent period everywhere, and it was no different in Brazil. Overnight, even hard fans of office life had to go home and start working remotely.
At that time, I was finalizing a project, and soon after that I switched teams, and the real challenge began.
The new project, already in a PM role, was on a video conference product, let’s call it Warrior. I was to work on a diverse team, located across the globe in different time zones:
- We had three technology leads, one responsible for each of the different areas of the platform (web/mobile, DevOps, and the backbone calling services), one based in San Francisco, another in Hong Kong, and the third one in Poland.
- The development teams were scattered around Sweden, Bulgaria, and India
- We had execs from finance located in South Korea, and Marketing on the east coast of the US
- Finally, in Brazil, the QA, Android, and PM teams
But, with all those challenges came great learnings! The hard-earned lessons I took out of this opportunity were later on applied to the different teams and products that I managed. Although the number of time zones and people working together was never quite that big, the knowledge was there, and I knew how to work around some of the problems I faced!
Hoping that this will help out other people, I compiled some of these lessons below :)
Time zones are a b****
Recently, I worked for around 6 months in Italy. My team was mostly based in Brazil, with some points of contact in the UK, and the east and west coast of the US. I adjusted 90% of my schedule around Brazil’s time. This was a 4/5 hours difference, but it was for a limited time, and it worked out fine.
Back on Warrior, this was not a possibility. You cannot wrap your head around the challenge that was to have everyone agree on a schedule for calls. Dailies with the development team? Midnight for some, lunchtime for others, 5 AM for others, and straight “Invitation declined” for the rest.
There was no good “middle ground” in terms of scheduling calls. Always someone would be prioritized, and the calls would be held at weird times for some.
We did the management calls right before the daily with the development teams. 7 AM for the Pacific folks, and 7h30 PM for the Indian teams. Sometimes, when external partners were involved, we had to do it the other way around, 9 PM for us in Brazil, 5 PM for everyone on the Pacific Coast, and right about the start of the day for the manager in Hong Kong.
This was lesson number #1. Time zones are a b****. With someone working on the opposite side of the globe from you, there will be unavoidable times when you’ll be having calls at 10 PM.
Looking to ease this pain, I went to research, and speaking with my mentor at the time, he suggested I took a look at GitLab’s documentation. GitLab has a lot of resources on the matter, as they are working 100% remotely since always, not only since Covid. Their culture is built around it, and they provide great insight on how to make remote work, well, work.
Applying all of their insight takes time, effort, and shared understanding across the company and teams, something that is not always possible for squads shifting to remote work from day to night.
If you see yourself in a similar situation, talk to people and discuss if there is something you can do to adjust to the crazy schedules. However, the hard truth is that, sometimes, calls at 10 PM may still happen.
Document decisions and make them public
One of the lessons from GitLab is being asynchronous-first, not only remote-first, meaning preferring to not have calls if an email thread can solve it. When a call is absolutely needed, we should strive to have a meeting agenda, notes, and documents to support the discussion and decisions.
Note that it’s not about having the whole team on the same Slack channels. The reason is that these platforms are instant message platforms and are meant for, you guessed it, instant messaging, not decision documenting.
If you paste the decisions from a call on Slack for a colleague to see once they start working seven hours from now, once he logs in there will be also other hundreds of messages on top of this one, and it’s easy to lose information then.
Searching for decisions on these platforms, although possible, is not ideal. And part of being asynchronous-first is exactly about making information easily accessible to everyone. Instead, do prefer some sort of documentation repository, like a shared Google Drive folder. If your team organizes their tasks on GitHub issues or ClickUp tasks, the individual issues/tasks are the place to document the decisions relevant to them, not random Slack threads.
If none of these are available, an email thread is still better than Slack.
Related to meetings and documentation, if someone is not central to the discussion, normalize skipping calls. Especially if you have the asynchronous structure to support this. Assuming everyone would be available 24h only leads to burnout and lack of engagement from the teams.
Build context
Now, either if you’re having these 10 PM calls or documenting decisions for someone that is starting their workday, you shouldn’t do it carelessly.
How you do these matters. In fact, if you’re taking anything out of this piece, take this: assume others don’t have the context you do. And if you want to convey a message, it’s your job to build this context.
This means starting the calls by explaining how you got there, the goals of the meeting, and so on. When documenting decisions, this translates to not being superficial about the document: put yourself in your reader’s shoes, and add all the information that is needed for them to understand the key takeaways and be on the same page as you at the end of the reading.
Picture yourself, starting your workday after a restful night of sleep, versus yourself at the end of an 8h journey working on the same problem, having all the context you built through these hours. It’s unfair to treat both the same, so why would you do so with a colleague?
One thing that helped me on Warrior, and I do to this day, is to have an explicit Context section in all tasks definition on whatever task tracker system the teams I lead have in place. This section’s goal is self-explanatory, and it’s alive. As things progress, it gets updated by the team, adding more and more relevant information for task completion.
Wrapping up
I learned a lot back on Warrior. These lessons helped me with the challenges I had then as much as it helps me nowadays. Specifically about working remote or with colleagues not “two desks to your left”, there are some things I learned and apply to this day:
- Time zones are a b****: If you find yourself working with people of a diverse range of time zones, sometimes having 10 PM work calls is unavoidable. You can ease the pain from part of it by building a structure around the remote and async work.
- Document decisions and make them public: One of the main things you should strive to do in this setting is to be biased towards documentation, and define which structure your team will follow to keep them easily accessible to everyone involved.
- Build context: Finally, don’t document things carelessly. Keep in mind that not everyone has the same context as you, and if the responsibility of conveying a message is yours, it’s also your responsibility of building the necessary context to make this possible.
