Going travelling was something I have always wanted to do. I grew up in the UK and when I was younger I often went to France and Spain on holidays because they were close, but I’ve always had the itch to go farther afield. I said to Josep that before getting married I wanted to travel and see more of the world, and through gritted teeth, he obliged. (Although I have to say he’s now enjoying it)!
There was one worry in the back of our heads though: would we be able to keep operating effectively from the other side of the world? And to be honest, the answer is yes. We always talk about the BEAMOps principles and how they will make you work better as a team, and travelling has been the ultimate proof of that.
Communication, Communication, Communication
It may seem obvious, but communication is key. But there’s a difference between talking for the sake of it, and actual communication that makes a difference.
For us async communication beats constant meetings. We’ve all seen this graph about developer productivity, and in our experience nothing could be more true:
Aside from the productivity slump and the toll that goes into preparing constant meetings, meetings across timezones are expensive. The average timezone gap between SE Asia and NYC is 12 hours, which means that a 10am meeting for them is at 10pm our time. As a standard practice (which was in place even before we went travelling), we have one meeting per week where we update our clients on progress and share any blockers or next steps. Now of course, we are reachable other than that meeting, but we try to maximise our development time and reduce things that could easily be a slack message.
Now that meeting was working well both us and our clients, but what travelling and having a smaller window of overlapping working hours has done is push us to refine the format of that meeting. We moved away from a one-way presentation of updates to something more collaborative: a written list of goals agreed at the start of each week, what we’re delivering, where we need the internal team’s input, and what they might need from us. Having it written down and not just discussed means there’s no ambiguity about what success looks like. Clear ownership and a clear list means we can each put our heads down and get things done without constant check-ins, wherever we happen to be.
Alongside oral communication, comes written documentation. In general, we always say that if you’ve completed a piece of work but only you know how it works, then you haven’t really finished it…you’ve just created an unscalable bus factor. So to really finish a piece of work, you need to write documentation. And especially now with AI, writing documentation is so easy that you don’t have an excuse not to. (Not that there ever was one.)
A few months into the trip we saw a clear example of where having documentation pays off. A new team member on a client’s team needed to know how to deploy to staging and get their local dev environment running. We were the ones that had implemented this. We had defined the CD pipeline and set up the Mise configuration. We were asleep at the time that this new person was being onboarded, but there was no issue at all because they were able to figure it out themselves by looking at the documentation in the repository. So by the time we had woken up in the morning, this person had set up their dev environment and been able to test the app in staging. So what could have been a frustrating situation for the new developer was easily avoided and they didn’t need us to help them.
Anyone on a team should be able to pick up a piece of work and understand it. Most engineering teams deprioritise writing documentation because the cost isn’t felt until something goes wrong at the wrong time. Luckily for our beauty sleep though, we had already written the docs and so didn’t need to be woken up in the middle of the night.
The Systems That Travel With Us
Something that we always knew, but has been gratifying to see pay off, is that a good CI/CD pipeline reduces operational anxiety. Although in many places, we have been the dev-ops team (as well as helping with development), having a reliable and easy-to-use deployment pipeline means that developers can freely deploy tens of times a day without the fear that something will break. They can essentially do what they want (obviously within reason..no force pushes to master 😅), and don’t need to be relying on us to help them ship changes. Having a reliable system creates personal freedom and means developers are free to develop and not have to fight fires anytime something goes out.
For the most part, problems are caught before they ever reach production. But of course there are always things that you can’t foresee.
The thing we’ve invested most heavily in (and that has paid off the most) is alerting and observability.
We had a client hit OOM issues while we were travelling. Whilst you never want to see OOM issues in production, an alert fired, and because we were in the loop we were able to respond. At this point though, we had not had enough time to properly invest in creating dashboards, so debugging was quite slow. We were having to piece things together manually rather than being able to see immediately what was happening and why. It wasn’t a disaster, and we did eventually get to the bottom of the issue, but the debugging process was a lot slower than it needed to be.
Because of that experience, we’re now investing in Grafana across our client work, especially in Tempo and tracing. The goal isn’t to have people glued to dashboards, but to have the right instrumentation in place so that the right people have the right information at the right time. We want to be in a situation where when we find out that something needs our attention, we already know what and where before we’ve even opened a terminal. This will help turn a slow, stressful debug session into a quick fix.
As Per Usual - It’s Not As Dramatic As It Seems
Looking back, we’re not sure why we worried. We’re a UK-based company that has always worked with US and European clients so we were already working remotely. The timezone gap just got bigger. And if anything, it’s been gratifying to see that the processes we have put in place, both before and while we’ve been travelling, have given our clients a calmness and confidence in how their systems are run.
From speaking with our clients, they all say the same thing: they don’t care which hours you’re online; as long as the deadlines are met, their systems run smoothly, and any production issues can be resolved quickly.
So the moving around isn’t important, but the intentional systems we put in place are. So I guess, moral of the story is that everyone should go travelling? I mean who can say no to views like this:
If you have any questions about what we do or how we do it, or even just want to chat about travelling, then feel free to get in touch!
📬 Email us at info@beamops.co.uk 📅 Or book a free 30-minute call, we’d love to hear what you’re working on.