5 exercises — response time expectations, @team diffusion of responsibility, UTC time zone arithmetic, async standup formats, and async decision-making across cultures.
0 / 5 completed
1 / 5
A US engineer sends a Slack message to a colleague in Poland at 18:00 their time and receives no reply. At 09:00 next morning the US engineer writes: "Pinging again — did you see my message?" The Polish engineer responds immediately. What is the likely cultural misunderstanding?
Response time expectations across cultures and time zones:
US tech culture response expectations: • Slack is often treated as near-synchronous — response expected within hours • After-hours messages are frequently sent without regard for the recipient's timezone • "Pinging again" is considered a normal follow-up, not pressure • Fast response signals engagement and reliability
European work culture response expectations (especially Germany, Poland, France, Netherlands): • Clear work/life boundaries — after-hours messages may not be seen until the next morning • Not responding outside work hours is normal and expected • Responding to late messages reinforces a culture of always-on expectations • "Right to disconnect" is a legally recognised principle in France
Why "pinging again" can feel aggressive: • The implied message is "Why haven't you responded?" — which, when the recipient was offline, reads as "You should have been online" • It creates pressure to justify absence from Slack during personal time
Async communication best practices: • Send messages anytime — don't expect replies outside the recipient's hours • Add explicit urgency signals when needed: "[URGENT - needs reply before 17:00 your time]" • Use scheduled send: draft your message now, send it at 09:00 recipient time • Agree on team SLAs: "Slack messages — reply within 24 business hours"
Vocabulary: • right to disconnect — the right of employees to not be reachable outside work hours • SLA (Service Level Agreement) — agreed response time standard; used for both customers and internal teams • scheduled send — a feature to send a message at a specified future time • ping — a short message to get someone's attention; "pinging" someone = sending them a Slack/Teams/DM
2 / 5
A team uses Notion for async documentation. An engineer from Germany updates a decision log and writes: "I updated the ADR to reflect the new database choice. @team please review by Thursday." An engineer from India reads this and thinks: "@team means someone else will handle it." The German engineer expected everyone to review. What is happening?
Diffusion of responsibility in async communication:
Social psychology research (Darley & Latané, 1968 — the bystander effect) shows: the more people who share a responsibility, the less likely any individual is to act. This is called diffusion of responsibility.
In async team communication, this effect is amplified because: • No one sees each other's inaction in real time • Group mentions feel like "someone will handle it" • There is no social pressure of a meeting where silence is visible
@team and @channel in Slack/Teams/Notion: • Feels like a broadcast — "this is for the whole group" • No individual accountability is created • Easy to assume "others will do this"
How to assign async actions effectively: • Specific names: "@Anna and @Dmytro — please review this ADR by Thursday 17:00 UTC" • Action verb + owner + deadline: "TO DO: Anna reviews database choice. DUE: Thursday" • Assign in the tool: use Notion's assigned property, GitHub review requests, Jira assignees — don't rely on text mentions • Confirmation protocol: "React with ✅ when you've reviewed"
Vocabulary for async task assignment: • action item — a specific task to be completed (action item: review ADR; owner: Anna; due: Thu) • owner — the person accountable for an action item • RACI — Responsible, Accountable, Consulted, Informed — a model for assigning roles • diffusion of responsibility — reduced individual action when responsibility is shared by many
3 / 5
A US tech lead writes in a PRD comment at 23:00: "This looks great, Yuki! I'd love your input on the API design before our Friday call." Yuki (in Tokyo, UTC+9) reads it at 07:00 Friday morning — 2 hours before the call. Is there enough time to respond?
Time zone arithmetic — a practical skill for distributed teams:
Calculating the scenario: US "tech lead" — assume Pacific time (UTC-8 in winter, UTC-7 in summer). Message sent at 23:00 PST = 23:00 + 9 + 8 = ... let's calculate step by step: • PST = UTC-8, so 23:00 PST = 07:00 UTC (next day) • Tokyo = UTC+9, so 07:00 UTC = 16:00 Tokyo (same day) Wait — 23:00 PST → add 8 hours → 07:00 UTC → add 9 hours → 16:00 Tokyo But UTC day: 23:00 PST Thursday = Friday 07:00 UTC = Friday 16:00 Tokyo ✓
Actually: Yuki reads the comment at 07:00 Friday Tokyo = Friday 22:00 PST (previous calendar day). The Friday call is at (say) 10:00 PST = 02:00 Saturday Tokyo.
In practice: a comment sent at 23:00 PST (= 16:00 Tokyo Thursday) gives Yuki a full Tokyo workday on Friday to respond before the PST Friday morning call.
The deeper skill — time zone communication: • Always specify timezone explicitly: "before our 10:00 PST Friday call" not "before Friday's call" • Prefer UTC for distributed team deadlines: "please comment by 18:00 UTC Friday" • Use timezone converters: worldtimeapi.org, everytimezone.com, or calendar tools
World clock reference for tech teams: UTC+0: London (winter), Dublin, Lisbon UTC+1: Warsaw, Paris, Berlin, Kyiv (winter) UTC+2: Kyiv (summer), Helsinki, Sofia UTC+3: Moscow, Istanbul, Riyadh UTC+5:30: Mumbai, Kolkata UTC+8: Singapore, Beijing, Manila UTC+9: Tokyo, Seoul UTC-5: New York (EST winter), Toronto UTC-8: San Francisco, Seattle (PST winter) UTC-3: São Paulo
Idiom:"What time is it for you?" — a standard opener when scheduling across time zones
4 / 5
A team's async update ritual: each engineer posts a daily written standup in Slack. A developer from Japan posts detailed, formal updates. A developer from Brazil posts brief, emoji-heavy updates: "🟢 done ✅ PR merged, pushing to staging later, maybe more updates if time 😅". What does this difference reveal?
Async communication formats across cultures:
When teams shift from synchronous standups to async written updates, they often assume "everyone will write the same kind of update." They won't — because good writing, appropriate formality, and useful information are all culturally shaped.
Japanese written professional communication: • Formal register is respectful; informal language in writing is inappropriate in many workplace contexts • Thoroughness signals diligence and respect for the reader • Structured format (what I did, what I will do, blockers) is common • Emoji in business writing may feel unprofessional
Brazilian written communication style: • Warmth and personality are valued even in professional writing • Emoji and informal language signal approachability, not disrespect • Brevity is practical — not cold • Context and tone ("maybe more updates if time 😅") convey relationship, not just data
Creating an effective async standup template: A template reduces cultural ambiguity and creates a consistent information baseline:
``` ✅ Done yesterday: [specific thing] 🔨 Doing today: [specific thing] ⛔ Blockers: [specific blocker / "none"] 📌 Anything the team should know: [optional] ```
Vocabulary: • async standup — a written daily update replacing or supplementing a live standup meeting • standup template — a standard format for daily updates to ensure consistent useful information • register — the level of formality in language use • signal-to-noise ratio — the proportion of useful information in a message vs. filler
5 / 5
A distributed team uses an async decision-making process: share a proposal, give 72 hours for async comments, then the decision is made. An engineer from France misses the 72-hour window and objects after the decision is closed. They say: "I did not know this was the final decision — I thought we would have a meeting to discuss." The team lead is frustrated. What should the team do?
Async decision-making processes and cultural expectations:
French workplace culture and decision-making: French business and professional culture often emphasises debate and discussion as an essential part of decision quality — not an optional add-on. The intellectual tradition values challenging assumptions and considering multiple positions before committing. A decision made "without a debate" may feel incomplete or illegitimate.
The async consent trap: "Silence = consent" is a common async process assumption. But it only works when: 1. Everyone knows the process exists and their role in it 2. Everyone knows the decision window is open and when it closes 3. Everyone understands that not responding is a meaningful signal (not just inaction)
For engineers unfamiliar with or culturally uncomfortable with async consent, "silence = consent" becomes "no one told me this was happening."
Making async decisions work cross-culturally: • Opening notification: "DECISION OPEN: [proposal]. Please respond by [specific date + specific time + timezone]. No response = consent." • Closing notification: "DECISION CLOSING: [proposal] will be final at [time] unless objections are raised." • Explicit documentation: write the process in the team handbook so everyone understands it • Opt-in for synchronous discussion: "If 3+ people request a call, we will schedule one before the decision closes"
Decision vocabulary: • consent-based decision — any objection stops the decision; silence is consent • consensus-based decision — everyone must actively agree • decision log — a written record of what was decided, why, and when • async consent window — a defined period for asynchronous review before a decision is finalised