It’s no secret that since 2020 the workplace has become very different to what we’ve become accustomed to over the years. The majority of the tech industry, including the team here at FX Digital, are fortunate enough to have a hybrid working arrangement that allows us to split our time between working in the office and working from home, while some businesses have opted to switch to remote working full time.
In this new landscape where remote working has become the ‘new normal’, so-called ‘digital nomads’ have appeared in greater numbers than ever before, and it appears that they are here to stay. Countries like Spain and Brazil are introducing visas to encourage digital nomads to work there, and there is even a village built for this demographic in Madeira. Even as I write this, I am sitting in the comfort of my family home in Mexico City and plan on working by the beach in Acapulco tomorrow – not too shabby!
With remote working now more widely commonplace, it presents lots of new and exciting opportunities for developers who now have the world at their feet as they can work from anywhere. This does however present a new series of challenges for team managers and tech leads, as many of us are traditionally used to operating face-to-face in an office setting. Last year, I was fortunate enough to become the designated lead of an international team of developers to deliver OTT and CTV development projects. While it wasn’t without its challenges, I learned to navigate through these new ways of working with my team. It was an exciting experience and I have many learnings to share that I hope will help other managers in my position.
1) Meetings
Whilst the majority of us were based in our London HQ, there were team members in Mexico, Canada, Spain, Uruguay, China, Italy, and the UAE, and learning to deal with different time zones was a real challenge. Having a meeting at a time when everyone could attend was near impossible. For the team’s day-to-day, we opted to have two separate stand-ups, one at the start of the day in London (10:00 GMT), and one after lunch (13:00 GMT). Of course, not everyone had to be on both stand-ups, but the developers had to attend their corresponding stand-up meeting. It did however become crucial for the Project Manager and myself to take notes during these stand-ups that could then be shared on our team’s Slack channel to ensure everyone was informed about the plans and goals for the day (more on this later).
For other bigger ceremonies, (retro’s, planning poker, etc.), we did ask all of the team to be present, and we always had to choose the most convenient time (early morning in Mexico, late in the day in China) – a compromise that has to be reached with digital nomadism.
2) Communication
Every team has to communicate in order to be functional, regardless of whether they are remote or in an office. We became so used to walking from our desk to a colleague’s before the pandemic for a quick chat, but when working remotely this is not possible. We’ve turned to tools like Zoom and Slack to keep our information flowing, but it’s no secret that nothing can replace face to face communication. This is a massive challenge since many of us now also experience “Zoom fatigue”, yet we have to keep the team informed of what we are doing and the progress of the project. To achieve this, I learned the following:
Your Kanban board can either be your best friend or your worst enemy
It goes without saying, having a place where you can see the status of the project at a simple glance is marvellous. A Kanban board should always display what projects are being worked on by which developers, what is currently being tested, and what the status of the sprint is. However, this is only effective if it is done correctly by everyone in the team. If the team is not keeping the board up to date, forgetting to label tickets correctly, not assigning themselves, etc. then this board can quickly become a nightmare to follow. This becomes particularly true when you cannot communicate with all of your developers at once because of different locations around the world, meaning you end up guessing what’s been done or going through all the open Merge Requests and manually linking them to their ticket. If the board has been neglected, then it is easy to try to overcompensate by creating new labels to describe the pertinence of the work or creating different views that reflect different time zones and different goals. Whilst these solutions can be effective in the short term, you are simply patching a bigger problem, so it is paramount to ensure your board is always nice and tidy.
Handover documents are very effective if they are precise and concise
Teamwork is always a major part of the success of a project, and it is an inevitable part of our day to day life as developers. It is important to ensure that developers can work with their peers in a healthy environment and that communication is flowing correctly through the right channels whilst reaching the right people. Yet, information is very easily lost in the sea of communication apps that we use daily, and sometimes Slack messages just won’t do. This is especially true when developers are working at different times of the day and they open their computers to 20+ Slack messages.
One thing I have learned is that an effective way to tackle this is through handover documents. When a developer finishes working, they detail the progress they’ve made in this handover document that addresses the blockers they’ve encountered, so that the developer just starting their day can refer to this to understand where they need to begin.
It is key to ensure that these documents are always short and concise so that they can be read in less than 5 minutes by whoever is starting their day. The developer leaving the handover notes also includes a summary of how the day has gone so far. I have found that these documents are much more effective compared to trawling through multiple messages on Slack and emails, as the handover notes provide a very quick and effective overview of what has happened, what is happening, and what is expected during the day.
3) Have processes in place
Ensuring that your team knows what they can and can’t do, and how they do it, becomes vital. Having processes in place that allow your team members to work remotely goes a long way to ensuring things run smoothly, so I always consider and document the following:
- How long can a team member work abroad (in a different time zone) for?
- What working hours should they do?
- Who do they need to communicate with when they face a blocker? What should they do if the blocker happens when the rest of the team isn’t working?
- What equipment do they need to take with them to ensure they can work effectively?
Obviously, the answers to these questions will vary from team to team and you will have to iterate many times in order to find something that works for your team. The last question, for example, has been a huge challenge for us at FX since we work with TVs, as taking a 75” TV on a flight across the world is not really feasible. So, we have come up with a list of what our developers should really be taking with them and taking into consideration, for example:
4) Trust your team and allow them to be tech nomads
For many of us, it is hard not to micromanage our teams. Managers naturally like to be in the know about everything that is happening, whilst also knowing who is doing what. With remote working, this is simply not always possible (unless you fancy having 24 hour shifts).
If you are lucky enough to have selected your own team of developers to work with you on your project, and you have fostered, mentored and coached them to be where they currently are, even if your team is completely new to you, with time you will have learned their skills, their capabilities, what they like, and how to best work with them. We also ask everyone to do an exercise of “working with me” whenever a project starts, to guide on their preferred ways of working.
Ultimately, however, you need to trust your team. When a developer asks me if they can work remotely from a different location to normal, I have no problems allowing it as I know that all the developers at FX are trustworthy people that will work well no matter where they are, as I know they are all capable of following all of the steps I have mentioned above in this article.
5) Celebrate this change in the tech landscape
These are pretty unusual times we live in, constantly full of change. The ways we work keep changing, and as developers, we keep finding ways to work effectively and efficiently. As the lead of the FX development team, it has not always been easy to manage my team in this new landscape, especially considering we need instant access to a wide range of devices. However, it has been an incredible experience and I know that my team appreciates the opportunity to be part of the tech nomad movement.
I encourage people to take full advantage of this opportunity, learn about new cultures and try doing some of their coding by the beach (it is pretty nice). I do, however, still ask some remote developers to visit our London office if possible, whilst always encouraging the developers that are local to the office to come in a few days a week because it still has many advantages from a team-building perspective.
Tech nomadism doesn’t have to be at war with having a nice office space and HQ. Personally, I believe the opposite. I believe the two complement each other and all of my nomads will always have a place to come home to when they feel like doing so!
Note: I ended up working on this article in 5 different cities: Cuernavaca, Acapulco, Mexico City, London, and Bristol…Hooray Tech Nomadism!
