I'm writing this at 11:30 PM IST. That's 1:00 PM Eastern Time. My team's active hours started about three hours ago from their side, and I've got about two hours left before I sign off. This is the rhythm I've been working in for the past few years.
I'm a Tech Lead at Pranshtech Solutions. I lead 10 developers some in Ahmedabad with me, some in other cities across India, and the product stakeholders largely in the US. IST is 10.5 hours ahead of Eastern Time. That's not a small gap. Every system I've built for this team has been designed around that gap, not in spite of it.
Here's what actually works.
The Async-First Mandate
Early on, I made a rule: if completing your work requires someone else to be online at the same time, that's a design problem, not a timezone problem.
This sounds obvious until you see how many "design problems" are actually just coordination habits that got normalized. A developer who can't merge their PR without a synchronous review hasn't hit a timezone wall they've hit a process wall. A developer who can't start a feature because the ticket description is missing acceptance criteria hasn't been blocked by timezones they've been blocked by incomplete requirements.
Async-first means investing more time upfront writing better tickets, making PRs self-explanatory, documenting decisions so that the work itself doesn't require synchronous coordination. It's more work at the beginning, less friction across the entire delivery cycle.
"Async-first" does not mean "async-only." Some conversations genuinely need to be synchronous. The discipline is distinguishing between "I prefer to talk about this live" (personal preference, often fine to convert to async) and "this decision has enough ambiguity that async will take three days of back-and-forth when a 20-minute call resolves it" (sync is correct).
The Daily Async Standup
We don't do a daily standup meeting. We do a daily standup message.
Every developer posts to a dedicated Slack channel before they start their first task. The format is fixed:
That's it. Takes 3 minutes to write. Takes 1 minute to read. I read all 10 of them at the start of my overlap window and I know exactly where every thread of the project is without scheduling a meeting.
The blocker field is the most important one. When I see a blocker, I triage it immediately either I unblock it myself within the hour, or I find who can unblock it and make that happen. The developer should never be blocked for more than a few hours without me knowing about it.
Make it a Slack channel, not a thread. Channels are searchable, archivable, and you can scroll back weeks to see patterns. If someone's been blocked on the same kind of issue three times, that's a signal either the system needs fixing or they need a different kind of support.
The Weekly Sync
We have one recurring meeting per week. Monday, one hour, every week without exception.
The agenda goes out 24 hours before, not 5 minutes before. If I don't have an agenda ready 24 hours out, the meeting gets cancelled or I send a draft agenda with a note that it's incomplete. People should be able to prepare, not show up and figure out what we're discussing in real time.
The Monday sync covers:
- Sprint review what shipped last week, what didn't, why
- Sprint planning what's being picked up this week, who owns what
- Cross-team dependencies anything where two developers are blocked on each other
- Process issues things that slowed us down that we can fix
- Open floor 10 minutes at the end, team can raise anything
Everything is recorded. The recording link goes into the standup channel. People who can't attend for legitimate reasons catch up from the recording not from asking a colleague to summarize it for them, which costs two people time instead of one.
1:1 Patterns
Every two weeks, 30 minutes, every developer on the team. Not monthly that's too infrequent to catch things early. Not weekly that's too frequent to have meaningful change to discuss.
The key shift: the agenda is theirs, not mine. I send a note before each 1:1: "The floor is yours what do you want to talk about?" I come with notes on anything I've observed that I want to address, but I don't lead with it. If they don't raise it, I do but I let them go first.
Three questions I ask in every 1:1, in some form:
- 1.What's one thing that's slowing you down that I could fix? Not "are you blocked?" That gets a yes/no. This gets specifics.
- 2.What's something you'd like to be working on that you're not? People have aspirations. If I don't ask, I don't know. If I know, I can route interesting work toward them.
- 3.How are you feeling about the team's direction right now? Vague, intentionally. The answer to this question tells me more about morale and trust than any status update does.
I keep private notes after every 1:1. Not a corporate record personal notes. Themes, things I noticed, commitments I made. I review them before the next 1:1. If I said I'd do something, I've done it or I explain why not.
The Jira Workflow That Actually Works
Most Jira boards I've inherited have 7-9 statuses. Todo, In Analysis, In Progress, In Review, In QA, Ready for Deploy, Blocked, Done, Duplicate. By the time a ticket moves through all of them, the work is ancient history.
We use three statuses: `To Do`, `In Progress`, `Done`. That's it.
The discipline isn't in the statuses it's in what a ticket must contain before anyone is allowed to pick it up. Our rule: no ticket gets picked up without acceptance criteria written in the description. Not a vague "implement the login page." Specific: what the user can do, what happens on error, what the success state looks like, any edge cases we've thought of.
If a ticket arrives without acceptance criteria, it doesn't get picked up. It goes back to the person who created it with a comment: "Can you add acceptance criteria? Using the template in the description." This feels bureaucratic the first two weeks. After that it becomes muscle memory, and we stop having endless PR comments about "this doesn't do what I expected."
Timezone Management: The Practical Reality
My core overlap window with US Eastern is roughly 7:30 PM – 11:30 PM IST (9:00 AM – 1:00 PM ET). Four hours of real-time overlap. That's enough for one weekly sync plus occasional async reviews and urgent unblocking.
The rest of my day the 12+ hours before overlap is deep work time. Feature planning, architecture, code review on Indian-timezone PRs, writing. The overlap window is reserved for anything requiring a US stakeholder in the loop.
The rule I protect hard: no shallow work in deep work time. No Slack-first mornings. No checking email as the first thing I do. I start with whatever the hardest/most important thing is, and I work on it until I've made real progress. The overlap window will deal with everything that came in overnight.
Async by default, sync by exception
When someone on the US side says "can we jump on a call?" my first response is always: "What do you want to cover? Let me see if I can address it async first." About 70% of the time, a well-written Loom video or a detailed Notion doc resolves what they thought needed a call.
The 30% that genuinely need a call, we schedule. I'm not precious about it. Some conversations are just faster live. The goal isn't zero calls it's intentional calls.
Code Review Across Timezones
The rule is simple: PRs opened by EOD should have a review within 24 hours. Not instant, not "when I get to it." Within 24 hours.
To make this work, PRs have to be self-explanatory. Our PR template requires:
- What changed not just what files, but what the intent was
- How to test it exact steps, not "run the app and check"
- Screenshots or recordings for anything UI-related
- The Jira ticket linked, so the reviewer can check acceptance criteria
The unblocking rule: if a PR has been reviewed and has changes requested, the author has 24 hours to respond. If they don't respond within 24 hours, they post in the standup channel why usually because they hit a question or disagreement they need to discuss. The review doesn't just sit.
For large PRs (more than 400 lines of meaningful change), I ask the author to record a short Loom walkthrough 5-10 minutes, explain the approach, walk through the key files. Reviewers watch it before reviewing. This has cut review time significantly because reviewers understand the intent before they look at the diff.
What Doesn't Work
I'll be direct about the things that failed before I stopped doing them.
- Daily video standups 10 people on a 15-minute call wastes 150 minutes of developer time for information that a 3-minute written message delivers more clearly. The only people who benefit are managers who feel better seeing faces.
- Expecting instant replies Slack's green dot is not a contract. If your workflow requires someone to respond in 5 minutes, your workflow is fragile. Design for 4-hour response times as the default.
- Micro-managing ticket states I used to check Jira status daily and ping people when tickets hadn't moved. This creates a low-trust environment and trains people to update Jira instead of shipping work. The standup message tells me everything Jira doesn't.
- Skipping documentation because 'everyone knows' everyone who's currently at the company knows. New hires don't. Future-you in 6 months doesn't. Write it down.
The Skill Nobody Talks About: Writing
You cannot lead a distributed team if you can't write clearly. This is not a soft skill. It's the core infrastructure of async work.
Writing clearly means: the person reading your message should not need to send a follow-up question to understand what you mean. Not because you wrote 500 words when 100 would do because you chose the right 100 words and structured them so the key information is immediately findable.
Things I've learned to write better:
- Lead with the conclusion don't make the reader get to the end to understand what you're asking for. State it first, then explain.
- One ask per message if you have three things to discuss, send three structured messages or a document with three clearly separated sections. One wall of text with three asks gets you one (wrong) response.
- Make the action item explicit "I think we should..." is a thought. "Can you review this by Thursday EOD?" is an action item. Every message that requires someone to do something should say exactly what, and by when.
- Separate questions from context context is the background someone needs to understand a question. Put the question first, context second. Most people never get to the context anyway.
“The quality of your writing is the quality of your team's thinking when you're not in the room. If your written communication is vague, your team will fill in the gaps with assumptions and assumptions in distributed teams always diverge.”
Something I tell every new lead I work with
After 3 Years: Distributed Teams Can Ship Faster
The common assumption is that distributed teams are a compromise you accept slower delivery and more miscommunication in exchange for access to talent that wouldn't relocate. I don't think that's true anymore, and I'm not just saying it.
The distributed team I've built ships faster than most co-located teams I've seen, for a specific reason: we've been forced to make our process explicit. Co-located teams can rely on hallway conversations, ambient context, shoulder-tap decisions. Those things feel efficient but they don't scale, they don't document, and they exclude anyone who wasn't in the room.
When you can't rely on being in the same room, you build systems. When you build systems, the systems work even when people are sick, or on vacation, or onboarding, or scattered across three cities and two time zones.
The timezone gap I work across every day 10.5 hours looked like a problem when I started this role. Now I think of it as a feature of how I work: it forced me to become a better leader, a better writer, and a better engineer than I was when I could tap someone on the shoulder.
If you're building a remote team and it feels chaotic: the chaos isn't because of remote work. It's because you haven't yet built the async infrastructure that remote work demands. Every co-located team that goes remote discovers this. Build the systems first, then the team can be anywhere.