Being a CTO from Dubai (UTC+4): timezone overlap strategy, async writing discipline, latency aware cloud architecture, the real tax economics, and remote team trust.
The LinkedIn version of my life is a laptop, a flat white, and a view of the Burj Khalifa. The real version is me at 6:40 PM negotiating with a browser tab that keeps buffering because our video call is being routed through three continents to reach a teammate two hours west of me. Being a CTO from Dubai is not an aesthetic. It's an operations problem you solve every single day, and most of the advice online is written by people selling the aesthetic.
I've been doing this for a while now — leading a small engineering team at Shpper while living in a city that sits in a genuinely awkward spot on the world map. Awkward is not bad. But it is specific, and nobody hands you the manual for running distributed engineering from the Gulf. So here's the manual, or at least the parts I had to write myself: timezone strategy, async communication, latency-aware architecture, the real economics of Dubai, and the isolation nobody warns you about.
The first thing that changes when you lead a remote engineering team from Dubai is that you stop thinking in "9 to 5" and start thinking in overlap windows. Dubai runs on Gulf Standard Time (GST), which is UTC+4. That number is the single most load-bearing fact of my professional life, and here's why: it puts me almost exactly halfway between the two talent pools most startups actually draw from.
Roughly, on a normal working day:
If you don't internalize this, you will schedule a "quick sync" that lands at 11 PM for someone, and you'll do it repeatedly, and you'll wonder why morale is quietly rotting. The clock on my wall is nearly useless for planning. What I actually keep in my head is a mental strip of where every person on the team is in their day. I optimize my calendar around that strip.
The practical version: I treat my morning (roughly 8 AM to 1 PM GST) as deep-work and South-Asia-facing time, and I guard my late afternoon and early evening (3 PM to 8 PM) as the collaboration window with Europe and the US East Coast. Mornings are for building. Evenings are for people. Flipping that order — trying to do deep work when three timezones want your attention — is how you end up doing neither well.
If you're evaluating a move, this is the calculation that matters more than the salary. Map your team's timezones against UTC+4 before you sign anything. A Dubai base is a superpower for Europe- and South-Asia-facing work and a slow grind for anything anchored to the US West Coast. The city doesn't change; the bridge you're standing on does.
With a distributed team, the resource you're actually rationing is shared awake time. For my setup, the meaningful overlap between me, our Europe-leaning folks, and anyone on the US East Coast is about four hours a day. Four. That's the budget, and it doesn't grow no matter how well I plan.
Once you accept it's four hours, you get ruthless about what deserves to happen inside it. My rule is simple: if it needs a human on the other end reacting in real time, it goes in the window. If it doesn't, it gets kicked out.
What earns synchronous time:
What gets kicked out of the window: status updates, design reviews I can read on my own time, most planning, and anything I can answer in a written comment. Here's the opinion I'll defend to anyone: a recurring status meeting inside a four-hour overlap is malpractice. You're spending the single scarcest resource the team has — synchronous human attention across half the planet — to hear things a paragraph could've told you asynchronously, on everyone's own schedule, searchable forever. If your standup could be a message, and it almost always can, make it a message.
A concrete way I audit this: at the end of a week, I look at every synchronous meeting that happened inside the overlap window and ask, "Could this have been a doc, a Loom, or a threaded comment?" If the honest answer is yes for more than one of them, I've mismanaged the scarcest thing I control. That single question has clawed back more effective collaboration time than any productivity tool I've ever installed.
The counterintuitive part is that guarding the window makes it feel like we have more overlap, not less. When the four hours are reserved for things that genuinely need a live human, they stop feeling like a slog and start feeling valuable.
Here's the part I didn't expect: being remote in an awkward timezone made me a dramatically better writer, because it had to. When you can't tap someone on the shoulder, the quality of your writing is the quality of your management. Async communication isn't a nice-to-have on a distributed team; it's the entire operating system.
Early on I learned this the expensive way. I dropped a one-line ticket at 7 PM my time — "clean up the auth flow, it feels janky" — and logged off. A teammate eight hours behind me picked it up, guessed at what "janky" meant, and rebuilt the wrong half of it. I woke up to a PR solving a problem I never had. Two days gone because I couldn't be bothered to spend ten minutes being specific.
That's the hidden cost of the timezone gap: round-trip latency measured in days, not milliseconds. If I write a vague task at the end of my day, the person picking it up eight hours later can't ask me a clarifying question until tomorrow. That single round-trip costs a full day. Do that three times on one piece of work and you've burned a week on something that was really two hours of confusion. On a co-located team a bad ticket costs a shoulder-tap. On a globally distributed one it costs a calendar day per ambiguity.
So I over-invest in the written artifact. A good async request from me looks like this:
## WhatMigrate the notifications collection to the new schema (v2).## WhyCurrent schema does a per-user fan-out read on every screen load.We're at ~40 reads per open on the home screen. Target is under 5.## Definition of done- [ ] New `notifications_v2` written on create (dual-write for now)- [ ] Home screen reads v2 only- [ ] Backfill script for existing docs, run + logged- [ ] Old collection left untouched until we verify a week clean## Notes / gotchas- The `readAt` field is nullable in v1. Don't assume it exists.- Don't touch the badge-count logic yet; separate ticket.
Notice the structure: What removes ambiguity about scope, Why gives the person enough context to make good local decisions when I'm asleep, Definition of done is a checklist they can self-verify against, and Notes / gotchas pre-empts the questions they'd otherwise have to wait a day to ask me. That template takes me ten minutes to write. It saves a day of back-and-forth. The timezone gap is what forced me to actually make that trade every time instead of only when I felt like it.
The deeper effect: writing this way forces me to think the problem through before I hand it off. Half the tickets I start writing turn out to be underspecified in ways I only notice because I'm forced to spell them out. Remote didn't just change how I communicate; it changed how much thinking I do up front. The same discipline applies to decisions — I write them down as short decision records so the reasoning survives past the conversation, because on a distributed team a decision that only lives in someone's memory effectively didn't happen.
Nobody warns you about the physics of building software from Dubai. The connectivity here is genuinely good — fast fiber, reliable enough. But we are far, in network terms, from a lot of the infrastructure the industry defaults to, and distance shows up as latency you can't optimize away in code.
The frictions are small individually and heavy in aggregate:
us-central1 out of habit. For a user base skewed toward the Gulf and South Asia, I reach for a region closer geographically, because a round-trip to Iowa from here is real milliseconds a user feels on every request. Picking the wrong region is a latency tax you pay forever.None of this is a dealbreaker. But if you move here imagining zero-friction global work, the friction will surprise you precisely because it's invisible until you hit it. I've learned to design around distance rather than pretend it isn't there — closer regions, heavier caching, and aggressively reducing round-trips in the app itself. On one project we cut a screen from around 40 Firestore reads down to 3, and the win felt bigger from Dubai than it would have from the middle of a US data-center corridor, because we were paying the latency tax on top of everything. Latency-aware architecture isn't a nice principle here; it's survival.
Let's talk money, because this is where the fantasy and the spreadsheet diverge hardest. If you're a developer or engineering leader weighing a move to the UAE, the tax headline is real but it is not the whole spreadsheet.
The headline number everyone knows: no personal income tax. That part is real and it matters. What you earn, you largely keep. For a builder, that's a meaningful lever on how fast you can save or reinvest.
But the honest ledger has a second column:
| Cheaper / better than people expect | More expensive than people expect |
| --- | --- |
| No personal income tax on salary | Rent, especially anywhere central |
| Excellent, cheap connectivity and hardware | Setting up as a freelancer/company (licenses, visas) |
| Fast logistics, everything arrives | Schooling and healthcare add-ons for a family |
| Safe, efficient, low daily friction | The "keeping up" tax — the city rewards spending |
Two things I wish someone had told me plainly:
The framing I use for anyone asking "is it worth it financially" is this: Dubai is not a place to be poor cheaply. It's a place where, if you're already earning well in a global-facing role, the tax structure and lifestyle compound in your favor. The delta is fantastic at the top and unforgiving at the bottom. Do the modeling on your real numbers — take-home, rent, setup, family costs — not the tax headline someone posted for engagement.
I've made real hires I've never stood in the same room with. That still feels slightly strange to say out loud, and it's the part that took me longest to get right. Trust on a distributed team isn't built in offsites twice a year. It's built in the tiny, boring consistency of showing up in writing, doing what you said, and being predictable.
A few things that actually changed how my team worked:
The uncomfortable truth: you can't fake this. Distributed work is a lie detector for management. If you're inconsistent, distance amplifies it, because people fill the silence with the worst plausible story. The only fix is to be boringly dependable until the silence stops scaring anyone.
This is the one that ambushes people, so I'll be blunt about it. You can be surrounded by a great team all day and still be professionally alone. My colleagues are online; my industry peers, the people I'd grab a coffee with to argue about architecture, are mostly not in my city or my timezone. The serendipity of a tech scene — hallway conversations, a friend who casually mentions the exact library you needed — is thinner when you're bridging timezones from a place that isn't your engineering culture's center of gravity.
It creeps up on you. For me it showed up as a slow drift toward talking to no one but my own team about the craft, which is a quiet way to stop growing.
What actually helps:
If you move here for the lifestyle and forget to solve for professional community, the lifestyle won't save you. That's the part the beach photos never mention.
Someone messages me about this every few months. Here's the compressed version of what I tell them:
Would I do it again? Yes, without much hesitation. But not because it's effortless. Because the constraints — the four-hour window, the writing discipline, the distance — turned out to make me a sharper operator than the frictionless version of this job ever would have. The awkward spot on the map forced habits I'm genuinely grateful for.