Async Communication & Time Zones
How to work effectively across time zones in English (用英文做异步、跨时区高效协作)
The Async Mindset (异步心态)
In a global team, synchronous time is scarce and expensive. The engineers who thrive are those whose written messages don't require a follow-up. Asia-based engineers working with US/EU teams have a particular incentive: getting async right means you don't have to take 11pm calls.
在全球团队里,同步时间稀缺且昂贵。最成功的工程师,他们的书面消息不需要追问。亚洲工程师跟美/欧团队工作时尤其需要:写好异步意味着不用接 11 点的电话。
The principle 原则: Write so that someone in a different time zone, with no context, can act on it without asking you anything.
写到不同时区、没有背景的人不问你就能行动。
Self-Contained Messages (自包含消息)
A self-contained message includes the why, the what, the ask, and the deadline. Without these, the receiver has to wait 12 hours for you to wake up.
自包含消息包括为什么、是什么、要求什么、何时之前。少了这些,接收者得等你 12 小时后醒来。
Bad async (差的异步消息)
"Hey can you take a look at this PR?" — 缺背景、缺紧迫度、缺特定问题。接收者要么 ping 你回来要么猜。
Good async (好的异步消息)
"Hey @alice — could you review #1234 by your EOD Friday? It's the rate limiter; main thing to check is the Redis fallback path. ~30 min review. Blocking the launch on Monday — flag if you can't."
你好 @alice — 周五下班前能审一下 #1234 吗?是限流器;主要看 Redis fallback 路径。约 30 分钟。下周一发布有依赖——做不到请告知。
What it has:
- Who it's for
- What's needed (review, not just look)
- Specific scope (Redis fallback path)
- Time estimate
- Deadline
- Why (blocking launch)
- Escape valve (flag if you can't)
Writing for Async Review (为异步审阅写作)
Give context first (先给背景)
Even if you and the reviewer talked yesterday, write as if they hadn't been part of any previous conversation. Their future self might not remember.
即使你和审阅人昨天才聊过,也假设他们没参与过任何之前的对话。他们未来的自己可能不记得。
Pre-empt obvious questions (预先回答显然的问题)
If you know they'll ask "why not approach X?", answer it in the doc. Saves a 12-hour round trip.
如果你知道他们会问"为什么不用 X?",在文档里就回答。省一次 12 小时往返。
Q: Why not use the existing rate limiter?
A: It's per-instance, not global. We need cross-instance limits for this use case.
Q: Why Redis vs. Postgres?
A: We considered both. Redis is 10x faster for this access pattern; Postgres would add ~5ms per request.Mark the urgency clearly (清楚标记紧急度)
| Urgency | Meaning |
|---|---|
| 🔴 [URGENT] or [P0] | Reply within hours; wake me if needed |
| [Action needed by Friday] | Specific deadline |
| [Async OK] | Reply when convenient, no hurry |
| [FYI] | No action needed, just informing |
| [Not blocking] | Take your time, I'm not waiting on this |
Time-Zone-Aware Phrases (时区感知用语)
Sending across time zones (跨时区发消息)
- "Sending this for your morning." — 你早上看。
- "No rush — happy with a reply tomorrow your time." — 不急——你那边明天回都行。
- "Catching this when you're back online — no urgency." — 你上线时再看——不急。
- "Sorry for the off-hours ping — wanted to flag before EOD my time." — 抱歉非工作时间打扰——想在我下班前提一下。
Asking about availability (问对方时间)
- "What's a good time across our zones?" — 我们俩时区都合适的时间是什么?
- "I can do early my time / late your time. Which works?" — 我能做我这早 / 你那晚。哪个行?
- "Happy to take a late call — you've taken enough." — 我可以接晚的——你已经接很多了。
- "Let's split the inconvenience — I'll take this one if you take next time." — 不便分摊——这次我来,下次你来。
When the meeting is at a bad time for you (会议时间对你不好时)
- "Heads up — that's 11pm my time. Can we shift, or I can join the recording?" — 提前告知——那是我的 11 点。能调整吗,或者我看录像?
- "I'll stretch for this one, but generally try to keep mine before 9pm." — 这次我配合,但一般尽量在我 9 点前。
Slack / Chat Conventions (Slack/聊天规范)
Threading (用 thread)
- Reply in thread for follow-ups. Don't reply in the main channel for every message.
- 跟进用 thread。不要每条都在主频道回。
- Use "Also send to channel" only when the answer matters to everyone.
- 只有答案对所有人重要时才"同时发到频道"。
Reactions instead of replies (用 reaction 代替回复)
- 👀 = "I see this, looking."
- ✅ = "Done." or "Got it."
- 🙏 = "Thanks."
- 👍 = "Acknowledged." / "Sounds good."
- 🚀 = "Shipping." / "Looks good."
This cuts noise and gives clear signal across time zones.
减少噪声,跨时区也能给清晰信号。
"Working hours" presence (工作时间状态)
- Set Slack status to your working hours.
- Slack 状态设你的工作时间。
- Use "Pause notifications" for nights/weekends — it sets a clear boundary.
- 晚上/周末用"暂停通知"——清楚边界。
- DND respected: don't ping during others' off-hours unless real emergency.
- 尊重 DND:除非真紧急,不要在别人下班时间 ping。
Direct message vs. channel (私信 vs. 频道)
- Channel by default. Searchable, others learn from it.
- 频道默认。可搜索,别人也能学。
- DM for: sensitive (HR, comp, conflict), 1:1 coordination, social.
- 私信:敏感(HR、待遇、冲突)、1:1 协调、社交。
Email Across Time Zones (跨时区邮件)
Subject line clarity (主题清晰)
- "[Decision needed by Fri] Auth migration approach" — 知道紧迫度。
- "[FYI] Postmortem for Tuesday's incident" — 知道不需要行动。
- "[Action needed] Review attached design doc" — 知道要做什么。
Time stamps (时间戳)
Always include time zone for any time you mention. "Friday 5pm" is meaningless across zones.
提到任何时间都带时区。"周五 5 点" 跨时区无意义。
✅ "Friday 5pm PT (Saturday 8am CST)" ✅ "EOD Friday Pacific time" ✅ "by 2026-05-10 17:00 UTC"
Handing Off Work Across Time Zones (跨时区交接工作)
Daily handoff message (每日交接消息)
Common in 24-hour ops or follow-the-sun teams.
24 小时运维或日不落团队常见。
Handoff @ EOD Asia (08:00 UTC)
Status:
- Issue X: identified root cause, fix in PR #234. Needs review from EU team.
- Issue Y: still investigating. Logs at [link].
For EU team to pick up:
- [ ] Review PR #234 (urgent — blocks customer)
- [ ] Continue Y investigation; latest hypothesis is [Z]
Nothing on fire. Sleeping well.
— [Name]Phrases (短语)
- "Handing off — here's where things stand..." — 交接——目前情况如下……
- "Picked up where you left off." — 接着你上次的进度。
- "Picking this up — last update from you was [link]." — 接手——你最后的更新是 [链接]。
Recording and Sharing Meetings (会议录像和分享)
If your team spans zones, default to recording important meetings.
如果团队跨时区,默认录像重要会议。
Phrases (短语)
- "I'll record and share — feel free to skip if your timezone is bad." — 我会录像分享——时区不好的可以不来。
- "Recording is at [link] — TLDR in the comments." — 录像在 [链接]——TLDR 在评论。
- "Watch on 2x — that meeting wasn't tight." — 2 倍速看——那次会议不紧凑。
Writing meeting notes for absent attendees (为缺席者写会议纪要)
Meeting: Auth migration sync, 2026-05-06
Attendees: Alice, Bob, Carol
Absent (FYI): Dave (overnight)
Decisions:
- Will use approach B
- Target launch: 2026-06-01
Discussions:
- ...
Action items:
- @bob: spike on rate limiter by Friday
- @dave: review the design doc when you're back online
Open questions:
- ...Calendar Etiquette (日历礼仪)
Setting up meetings (约会议)
- Use scheduling tools that show others' time zones (Calendly, etc.).
- 用显示对方时区的工具。
- For recurring meetings: rotate inconvenience. If it's always 11pm for you, say so and ask to rotate.
- 周期会议:轮流不便。如果总是你的 11 点,说出来要求轮换。
Phrases (短语)
- "Could we rotate this meeting? It's been at 10pm my time for 6 months." — 能轮换这个会议吗?我已经凌晨 10 点 6 个月了。
- "Let's set up two slots so different time zones get the early one." — 我们设两个时段,不同时区轮流坐早的。
Making Async Decisions (异步做决策)
Setting comment deadlines (设评论截止)
Without a deadline, async decisions never close. State one explicitly.
没有截止日期,异步决策永不收口。明确写出来。
- "Comments by Friday EOD UTC. If no objections, I'll proceed Monday." — 周五 UTC 下班前评论。无异议则周一开始。
- "Lazy consensus: silent for 48 hours = approval." — 懒人共识:48 小时不出声 = 批准。
- "If nobody objects, I'll go with option B." — 没人反对就选 B。
Decision documents (决策文档)
For anything significant, write a decision doc instead of relying on Slack threads.
重要事情写决策文档,不要靠 Slack 线程。
Decision: Use Redis for rate limiting (not Postgres)
Owner: Alice
Status: Decided
Date: 2026-05-06
Context:
We need cross-instance rate limiting for the public API.
Decision:
Use Redis.
Rationale:
- 10x faster for this access pattern
- Already deployed for sessions, no new infra
- Cost: ~$X/year, fits in current Redis budget
Alternatives considered:
- Postgres: would add ~5ms per request
- In-memory + gossip: too complex for ROI
Comments by: 2026-05-10 EOD UTCWorking With Team in Other Time Zones (跟其他时区团队工作)
When you have 2-4 overlapping hours (有 2-4 小时重叠时)
Save sync time for high-bandwidth tasks: design discussions, conflict, brainstorming. Async everything else.
把同步时间留给高带宽任务:设计讨论、冲突、头脑风暴。其他全异步。
When you have 0-1 overlapping hours (重叠 0-1 小时时)
You're effectively async-only. Quality of writing becomes critical. Use:
实际上只能异步。写作质量至关重要。用:
- Loom/video recordings for complex explanations
- 复杂解释用 Loom/视频录像
- Detailed PR descriptions
- 详尽的 PR 描述
- Decision docs over Slack threads
- 用决策文档而非 Slack 线程
Phrases (短语)
- "Recording a 5-min Loom to explain — link incoming." — 录一个 5 分钟 Loom 解释——链接马上到。
- "Wrote it up rather than scheduling — see [link]." — 写下来了,没约会议——见 [链接]。
- "If a call is faster, I can do early my time / late yours." — 如果电话更快,我可以做我这早 / 你那晚。
Daylight Saving Time Hazards (夏令时陷阱)
DST shifts can break recurring meetings — especially when only one of the two regions observes it.
DST 切换会破坏周期会议——尤其当只有一方有夏令时。
- US: 2nd Sunday of March → 1st Sunday of November (DST observed).
- Europe: last Sunday of March → last Sunday of October (DST observed).
- Most of Asia: no DST.
When DST flips, double-check your recurring meetings — they may shift by 1 hour for 2-3 weeks until both sides flip.
DST 切换时,仔细检查周期会议——可能错位 1 小时持续 2-3 周。
Phrases (短语)
- "DST starts in the US this Sunday — heads up our standup will shift by 1 hour for those of you in Europe." — 美国本周日开始 DST——欧洲同事注意 standup 会错位 1 小时。
- "Worth re-checking your calendar — DST might have shifted things." — 值得重新检查日历——DST 可能错位了。
Phrases to Avoid (要避免的表达)
| ❌ Avoid (避免) | Why (原因) | ✅ Better (更好) |
|---|---|---|
| "Can you hop on a call quickly?" at 11pm their time | 没考虑时区 | "Could we sync — what's a time that works in your zone?" |
| "ASAP" with no real deadline | 让对方猜紧迫度 | "By [date/time TZ]." |
| "Tomorrow morning." | 谁的早晨? | "Tomorrow 9am PT." |
| DM-only conversations | 失去搜索性 | Use channels by default. |
| Starting threads with "Hi" then waiting | 12 小时空往返 | Lead with the actual ask. |
| Vague "let me know" | 没行动 | "Reply by Wednesday with X." |
Cultural Notes (文化提示)
Async-first ≠ slow (异步优先 ≠ 慢)
The fastest async teams write so well that decisions happen in 24 hours without a meeting. Slow teams confuse async with "no urgency."
最快的异步团队写得好到 24 小时无会议做完决策。慢的团队混淆异步和"不紧迫"。
Don't optimize for your time zone (不要只优化自己时区)
Asia-based engineers sometimes default to scheduling everything in their daytime, then wonder why US/EU don't engage. Compromise actively by taking some inconvenient slots.
亚洲工程师有时默认排自己白天的会,然后奇怪为什么美/欧不参与。主动妥协,承担一些不便时段。
Saying "I'm not on" is fine (说"我不在线"没问题)
Western tech respects working hours. Setting boundaries on weekends and evenings is normal — and expected. Working at 11pm regularly will be flagged as a burnout risk.
西方科技公司尊重工作时间。周末晚上设界限是正常的、被期待的。经常 11 点工作会被标为 burnout 风险。
Default to writing (默认写下来)
The senior+ habit: when in doubt, write. Writing scales across time zones, scales across people, and scales across time. Sync conversations evaporate.
资深以上的习惯:拿不准就写。写作在时区、人、时间上都 scale。同步对话蒸发。
Don't over-apologize for time zones (不要为时区过度道歉)
Working from Asia is not a defect. Don't preface every email with "sorry I'm in a hard time zone." It is what it is — make the most of it.
在亚洲工作不是缺陷。不要每封邮件开头都说"抱歉我在难处理的时区"。就是这样——好好利用。
Tips (小贴士)
- Write self-contained messages — Why, what, ask, deadline. 写自包含消息。
- Always include time zones — Always. 永远带时区。
- Use thread + reactions — Cuts noise, scales across zones. 用 thread + reaction。
- Set DND boundaries — And respect others'. 设 DND 边界。
- Default to written decisions — Slack threads disappear; docs persist. 决策默认写文档。
- Rotate inconvenience — If meetings are always at your 10pm, ask to rotate. 轮换不便时段。
- Loom for complex explanations — Saves a meeting and keeps async. 复杂解释用 Loom。