Shipping to nine countries from Bangladesh: how a 25-engineer team works fully async
I lead engineering at DevTechGuru, a Bangladesh-based product team that ships software to clients in the US, UK, Canada, Germany, UAE, Saudi Arabia, Australia, Malaysia, and South Africa. The clock is the first problem. We sit at GMT+6. With most of those clients, we get four hours of overlap on a good day, none on a bad one. With the rest, the overlap is zero - their working day starts as ours ends.
You can solve this the wrong way: bend everyone's calendar, take 11 PM calls, send "any updates?" Slack pings. Burn out the team and call it discipline.
Or you can solve it the way that scales: stop relying on synchrony at all.
Here's how a 25-engineer team across web, backend, and mobile actually works when no two stakeholders can be in the same hour.
Async is not a vibe; it's a stack of forcing functions
When people say "we're async-friendly," they usually mean "we have Slack and we're cool with delayed responses." That's not async. That's slow sync.
Real async is a series of constraints you put on yourself, on purpose, that turn time-zone math from a problem into an irrelevance.
The four we lean on:
- Decisions live in writing, before code. Anything non-trivial gets a one-page RFC: the problem, two or three options, the trade-offs, the choice, the open questions. The RFC sits in a public doc with comments. By the time anyone joins a call about it - if a call happens at all - the disagreement is already on the page.
- Code reviews are the collaboration medium, not the gate.Pull requests are where engineers think together. Reviewers don't just approve; they ask questions, suggest alternatives, point at the RFC if a decision drifts. Three thoughtful PR comments are worth a one-hour meeting we couldn't have scheduled anyway.
- One owner per surface.Every service, screen, or pipeline has exactly one engineer accountable for it. Not "the team" - one name. Async kills committee ownership; somebody has to be the person you can ask in writing and trust to answer authoritatively.
- Status lives in the tracker, not in your head.If it's not written down, it doesn't exist. Updates land in Linear or the equivalent at end of each contributor's day, not in a 9 AM standup that two timezones can't attend.
None of this is novel. What's novel is treating it as the default rather than the fallback.
The thing async exposes that sync hides
Synchronous communication is forgiving of vague specs. You can have a one-hour call where no one says exactly what the success criteria are, and you'll still walk away feeling productive because the room had energy. Then engineering builds the wrong thing for two weeks and everyone is surprised.
Async is unforgiving in exactly the right way. If a spec is ambiguous, the very first PR exposes the ambiguity, because the engineer has nobody to ask in real time and has to make a choice and document it. The choice gets reviewed. The reviewer disagrees. Now the disagreement is in writing, in a PR thread, attached to a specific line of code. The product owner reads it the next morning, in their timezone, with coffee. They make a call. The thread closes. The work continues.
The same conversation, sync, would have taken three meetings spanning a week and produced no artifact.
What this means for hiring
If you're a Bangladeshi engineer applying for remote roles at first-world companies, the question every hiring manager asks themselves is some version of: Can this person operate without me looking over their shoulder?
Async-first work is where you build the answer. You can't fake it on a resume. But you can demonstrate it concretely:
- Your GitHub history shows pull requests with substantive descriptions, not "fix bug" one-liners.
- Your blog (if you have one) shows you can think through a problem in long-form prose.
- Your interview answers reach for written examples - "here's the RFC where I argued for X" - rather than "I told the team in a meeting that..."
That kind of evidence is independent of what timezone you sit in.
What doesn't work
Two things I've seen kill async teams, including ours when we let them slip:
- Treating async as a budget for slowness. Async lets you defer responses by hours, not days. If a PR sits unreviewed for 36 hours, the project is dead in the water - the engineer who opened it is now blocked across two of their working days. Response-time SLAs matter more in async, not less.
- Hiring for skills without hiring for written-communication taste.An engineer who is great at code but writes one-line PR descriptions is a liability in this model. They'll be productive when their manager is awake and useless the rest of the time. You can teach a lot of things; you can't teach someone who doesn't want to write.
What I'd tell a younger me
If you're thinking about whether a fully-distributed, fully-async setup can work across nine countries with a Bangladesh-based team in the middle: yes, it can, and it's been the most productive arrangement of any I've worked under. The constraint forces clarity. The clarity compounds.
But it requires you to stop reaching for the synchronous tools when things get hard, even when you really, really want to. The temptation to just "hop on a call" is constant. Resist it. Write the doc instead.
Md. Tausif Hossain leads engineering at DevTechGuru, a Bangladesh-based agency shipping HealthTech, PropTech, and enterprise SaaS products to clients in nine countries. He also runs TechnicalBind, an independent software studio, and teaches advanced full-stack engineering at Ostad. Reach him at tausif.bd or @tausif1337.