Imagine you’re a morning person. The type that, for better or worse, is unconsciously in sync with sunrise. Your mornings offer ample time for personal pursuits, such as a workout, a side hustle, or undisturbed personal time. When your devices are powered on, your inbox loosely resembles the same notification count that it did the night before.
Now, flip it upsidedown. Literally. Every morning meeting is now an evening meeting. Or, more accurately, a middle of the night meeting. Your inbox is laughably far away from inbox zero and your working hours hardly overlap with those of your team members.
That’s basically been my experience as I transition from North American to Asia Pacific working hours - it’s nothing short of drastic. Fortunately, the things that challenge my perceived norms generally present the best opportunities for learning.
Here are three things I learned while managing a 14- to 17-hour time difference for the greater part of two months.
Lesson #1: Be true to yourself
If GitLab didn’t live and breathe asynchronous communication, managing such timezone differences would have been tricky. Instead, the differences provided a tangible experience from which to grow and practice the principle.
When comparing a typical "9 to 5" workday, here’s how many hours my home timezone (Mountain Time) overlapped with each location:
- Bali (+14 hours): 0 hours
- Australia (+17 hours): 2 hours
After making the timezone switch, I decided to keep attending regularly scheduled meetings. To balance things out, I took time off in the middle of the day and stayed online as late as 1 am. Such a scenario might work for some people, but not me. I felt weird, innate guilt for not working during the day when it wasn’t a planned day off, but more so for going against a well-known personal trait: I’m not a night owl.
That’s when I learned my first lesson: Be true to yourself.
I know when I’m most productive and when I need to unplug and rest. Going against these knowns wasn’t going to benefit GitLab or me. If anything, going against what I know about my productive work patterns had the potential for the opposite effect: burnout. Therefore, rather than accept and attend every meeting, as I generally would stateside, I started declining most everything.
Instead, I reviewed and commented on meeting agendas, issues, and Slack threads where my participation was necessary. This was my first step toward understanding asynchronous work firsthand and actually doing it.
Admittedly, I had an irrational fear that team members would think that I wasn’t doing my job or slacking off. Fortunately, my fears were just that – irrational.
Lesson #2: Productivity is not linear
Outside of the confined "9 to 5" workday, there’s a waning window of productivity across timezones – one region is getting up to speed while the other is winding down. While I could enjoy the fruits of completely asynchronous work, the truth is, if I wanted to push things forward more quickly, then I needed to stop working in well-defined windows. Namely, the "9 to 5" window.
In the states, I would intentionally avoid looking at my phone or opening my laptop when I first woke up. Only when I felt ready to settle-in, after my morning routine, would I engage with technology. At home, my productivity is linear, and I would tread the well-worn path of traditional business hours. As I zoom out and think about that structured approach, I can't help but think of that as "corporate conditioning".
That connotation is neither positive or negative – just calling it as I see it.
Anyway, given the timezone shift and the awareness of when I’m most – and least – productive, I let go of the marathon workday notion and chunked my work. For example, shortly after I woke up, I’d go straight to Slack and email. From there, I’d categorize every item as either, 1) Do it now or 2) Do it later.
Some mornings required about an hour’s worth of work and prioritization, while other mornings occupied three times that. After a productive morning, I intentionally stepped away to workout, connect with loved ones, and discover the local brunch scene. Later, I returned to my laptop and carried on with work.
Overall, I started to really love and embrace this alternative workday. In retrospect, plus full transparency, it wasn’t uncommon that I’d fall into a productivity black hole and struggle to stay awake during marathon workdays. You know, the times where you become acutely aware of how heavy your head actually is when you snap it back to the upright position.
Well, that thankfully disappeared from my late mornings and early afternoons as soon as marathon workdays ended. Also notable, coffee (or caffeine) was not involved in any way, shape, or form. I’ve actually never had a cup in my life (Weird, I know).
Realizing this, I learned my second lesson: Productivity is not linear.
I can’t maintain a high level of output throughout the course of a linear workday. It would be like expecting to run a 50-mile ultra-marathon at my half-marathon pace – it's just not realistic in endurance athletics. However, if I split up my day by balancing focused efforts with adequate personal time, I can produce a higher level of output.
That analogy isn't perfect, but hopefully you get my point.
Though, if I really want to put this running analogy to the test, I should see how many quality half-marathons I could run in a day.
Lesson #3: Work/life balance is subjective
While having dinner one evening in Brisbane, Australia, a friend asked in a tone that warranted introspection: “What are you hoping to learn from this experience?” If the question had been asked in a different tone or context, I imagine I would have spewed out some naive, vague garbage about "seeing the world". Instead, my first thought was about the concept of work/life balance.
While I was thinking about my response, I reflected on how confusing company reviews can be. For example, on Glassdoor, "work/life balance" is often mentioned in both glowing – and slandering reviews.
As the conversation progressed, I realized that I didn’t have a personal definition of work/life balance. I started thinking: "What is it about downtime that I value?", "What are my expectations of how an employer lets me manage my time?", and "What innately motivates me in the professional world?"
I thought about where I’d been and the people I met on the WiFi Tribe, the culture of GitLab, and started to piece together a principle.
While I was analyzing my tendencies, I realized that my pursuit of perfectionism often impedes my ability to let good enough be enough. I take pride in what I produce, but at what cost? There are people who "live to work" and then there are those that "work to live". Neither approach is right and neither is wrong – it’s all subjective.
That’s when I learned my third lesson: Work/life balance is just as subjective.
It was a lightbulb moment for me. I work in talent operations for GitLab, and I started thinking about the typical interview processes – interviews are as much about the candidate selling themselves as they are about the company selling itself. At least, that’s how it should be in theory.
Without introspection, how can someone really know whether they're making a "good career move" by joining a new company. Sure, money is a metric, and so is job-leveling – but those are extrinsic motivators. I’d like to think that burnout is blind to compensation and leveling. From my perspective, work/life balance is made up of many intangibles.
In a sense, I happily stumbled into a great work culture at GitLab! I’d known about the GitLab handbook and the company principles prior to applying, but I hadn’t given my motivators enough thought. Now that I've defined my personal principles around work and life, I’m all the more appreciative of everything that GitLab has to offer.
All things considered, it's quite impressive that something as simple as shifting timezones could offer such new perspectives. I will remember these takeaways, without a doubt. How I’ll apply my work/life principles back on Mountain Time is still unknown, in the spirit of GitLab, one thing is for certain – I'll be iterating on them.
Cover image by Erich Wegscheider
Guide to the Cloud
Harness the power of the cloud with microservices, cloud-agnostic DevOps, and workflow portability.Learn more