Classify overlap as green, yellow, or red
The clock on your wall is local. The team needs hours in UTC when every required person can work without giving up the night. Unnamed hours turn every invite into a negotiation.
List who must be in the decision. Use IANA zones: Europe/Berlin, America/New_York, Asia/Manila. "The US" and "Europe" are not clocks. Two people in the United States can be three hours apart, and one may stop at 15:00 for school pickup.
Count shared time inside a daytime span you wrote down, often 08:00 to 18:00 local, for each pair and for the whole required set. If the span is never written, "reasonable" slides until it includes 21:30. Call the three results overlap bands.
Green is four or more shared daytime hours on most days. Decisions, pairing, reviews, and a client call that fits go here. Status can travel while someone sleeps.
Yellow is one to three hours. A short agenda with a pre-read, or a two-minute voice handoff. Not a workshop. The person on the edge will miss the decision or leave early, and next time they will decline the series.
Red means no shared daytime unless someone works at night. Red is writing. Move the decision, or shrink who is required. Do not call midnight culture.
Track overlap debt: every required attendance outside 08:00 to 18:00 local. If the same names carry it every week, change the roster or the meeting. Recompute when headcount changes and on the week the clocks change. A March offset can be wrong for one city in November. Those misses are in DST mistakes remote teams make.
What a written ask must contain, once you are outside the band, is in async communication for distributed teams. How to state the reply promise is in response expectations that respect time zones.
Decide how much live time this roster can afford
Match the plan to the band you measured. A green plan on a yellow roster becomes a standing apology.
Two zones with green overlap: protect that window before other series take it. Decisions, pairing, and reviews only. Publish it in week one, in UTC, with each local clock on the same row.
Yellow only: write first. One short decision slot in the week, pre-read already linked. If the pre-read is missing the day before, cancel. Do not convert the slot into updates.
Three regions and no shared hour: relay. Live time is pairwise. The third person gets a written result and a next action, not a 22:00 seat for status. No named conflict that needs all three voices means you do not have a three-way meeting.
One region always takes the late slot: rotate it in public, or staff it as paid coverage with an end date. Praise the note that let the other region start on time. Praise for the midnight reply is the failure in available all day is a bad system.
Inside the overlap, chat is fair and a same-day reply is the aim. Outside it, nobody owes an instant reply, and a complete written request is still answered on the next overlap. "Be responsive" collapses those into one vibe, and new hires will stay up to satisfy it.
Relay the day when three regions cannot share an hour
Example. Assumptions: Berlin engineering works 09:00 to 17:30 local, New York product works 09:00 to 17:30 local, Manila QA works 09:00 to 18:00 local. The UTC figures assume summer time: Berlin on Central European Summer Time (UTC+2), New York on Eastern Daylight Time (UTC-4). Manila is UTC+8 all year. In northern winter both Berlin and New York shift. Recompute before a January invite. Do not paste summer hours into a winter series.
Under those summer assumptions the daytime spans are Berlin 07:00 to 15:30 UTC, New York 13:00 to 21:30 UTC, and Manila 01:00 to 10:00 UTC.
Berlin and New York share about 13:00 to 15:30 UTC. Guard it. Lunch in the middle can knock it from a short green down to yellow. Berlin and Manila share about 07:00 to 10:00 UTC, which is yellow. New York and Manila share nothing comfortable. That pair is red. A weekly hunt for a time will find someone's night.
Three hops, each with an owner. Manila to Berlin around 08:00 UTC: speak only if a voice prevents a wrong turn. Otherwise the handoff is already on the ticket. Berlin to New York, 13:00 to 15:00 UTC: the decision or the review. Status is on the ticket before this window, or the decision slips into red. New York to Manila is writing. Finish it before New York logs off. New York's afternoon is Manila's next morning.
A decision that needs all three takes a day to travel. Anything Manila must do tomorrow is written before New York's afternoon ends. A three-way call that truly will not relay is rotated, recorded, and preceded by a written artifact. It is not weekly status.
Example, same offsets, one weekday. Manila posts results before logout, with the verify step and what not to redo. Berlin writes the brief before 12:00 UTC, with a recommendation and a default if New York is silent. New York uses 13:00 to 14:00 UTC to choose, writes it on the ticket before the slot ends, and leaves Manila what changed, how to verify, what not to redo, and the next action with an owner and a UTC time. If the brief is late, do not drag New York. Move the decision, or execute the default. One extra half hour is how yellow becomes red for Berlin.
Run five steps before you send the invite
Open the roster before the calendar. Otherwise one city absorbs every late slot.
- List required voices only. If nothing breaks when a person is absent, they are optional and they get the summary. "They might have context" is not a break. Context can be read.
- Map working hours from the roster, in IANA zones. Do not ask for proposed times first. They cluster on the organizer's morning.
- Intersect in UTC for that date. Daylight saving belongs to the date, not to a city nickname. Put each local start and end on the same row as the UTC span.
- Paste every required local clock into the invite. A lone UTC time gets misread.
- Name the exit and the written path together. "We leave with A or B chosen, on PAY-200." If no green or yellow window exists for the required people that day, send the brief instead, with a UTC deadline and a default if silent.
| Invite | What it does |
|---|---|
| 14:00 UTC, 30 minutes, Berlin and New York, brief already sent | Fair under the summer assumptions above |
| 16:00 UTC weekly standup, Berlin and New York | After a normal Berlin day. Unfair as a series |
| "Whenever works," no zones in the body | Thrash. The cost is invisible |
| 21:00 Manila weekly, so three regions hear status | Unfair. Write the status. Relay it |
A decline because the local time is outside 08:00 to 18:00 is the rule working. Move the slot or mark them optional. Once the slot is fair, length still has to fit a budget: fewer and better remote meetings.
Fill the five-line invite worksheet
Decision: [the choice, in one line]
Pre-read: [link, sent at least one workday ahead]
Exit: [what is written before hang-up, and where]
Required: [roles plus IANA zones; everyone else is optional]
Local clocks: [each required start and end, plus the UTC span]An empty line means you are not ready to send. Figuring out the agenda live spends the overlap on yesterday's writing.
Example. Assumptions: summer offsets from the relay, the pre-read is already on the ticket, only Berlin and New York are required, Manila reads the result in the morning handoff.
Decision: checkout provider A vs B
Pre-read: PAY-200 decision brief
Exit: choice recorded on PAY-200 before hang-up
Required: Berlin engineer (Europe/Berlin), New York owner (America/New_York)
Local clocks: Berlin 15:00 to 15:30 CEST, New York 09:00 to 09:30 EDT, 13:00 to 13:30 UTC
Thin overlap gets a tighter brief, not a longer meeting. Red cannot hold a recurring ceremony. If the pre-read link fails for a required person, fix access before the slot.
Write the request so the other morning can answer it
The overnight reader cannot tap you. Include the link, what done looks like, whether you need a decision or an action, and a UTC deadline. Miss one and they guess or wait, and the relay loses a day.
This fails:
Can you look at the checkout?
Example. Assumptions: preview is what fails, the webhook secret is missing, and the next overlap starts at 14:00 UTC. This can be done without you in the room.
PR 482 fails on the payment webhook in preview. Set the preview webhook secret in the env. Needed before 14:00 UTC. Done means one success path and one failure path clicked, with pass or fail commented on the PR.
"End of day" is three clocks. Write your UTC hour. If you mean their evening, say so on purpose. Answer in full. Ten lines now beat five exchanges across three mornings. If the work will wait, say when you are next online, in your zone and in UTC.
Do not log out on an open question. That becomes their blocker. If you still own the work, use a status note: end-of-day status update. If ownership moves overnight, use the handoff fields below. A status note omits the verify step a real handoff needs.
Copy the overnight handoff template
Changed: [what is true now that was not true when you started]
Verify: [the check the next owner runs without you]
Do not redo: [the restart or experiment that would waste the next shift]
Next: [the first action, concrete enough to begin]
Owner: [role, IANA zone, and the UTC time the next move is due]Those are the handoff fields. If Verify or Next is empty, you described your day. Keep the ticket, and say so, or the other region will pick it up by mistake.
Example. Assumptions: the staging rate limit is raised, the old worker pool was already restarted, the next likely fault is a Redis setting in preview, and the Berlin engineer owns the next move before 10:00 UTC.
Changed: rate limit raised on the staging API
Verify: hit /health and one authenticated route
Do not redo: do not restart the old worker pool
Next: if 5xx persists, check the Redis connection string in preview
Owner: Berlin engineer, before 10:00 UTC
Use a voice handoff inside yellow or green when two minutes will prevent a wrong restart. Stamp UTC even if you write the note at your own 17:00. "This afternoon" is ambiguous the moment you sign off. The longer method, including when blockers need their own lines, is in leave work someone else can continue.
"Almost done" with no verify step is a diary line. Rewrite it, or keep ownership and name the first move on your next morning.
Publish the roster, the reply band, and the late slot
One roster. People edit it when hours change. A second copy in chat will be the one someone trusts on the week it is stale.
| Person | IANA zone | Typical local hours | UTC this season | Notes |
|---|---|---|---|---|
| Berlin engineer | Europe/Berlin | 09:00 to 17:30 | Recompute for the date | School pickup on Wednesday |
| New York owner | America/New_York | 09:00 to 17:30 | Recompute for the date | Early start on decision days |
| Manila QA | Asia/Manila | 09:00 to 18:00 | 01:00 to 10:00 | No comfortable New York overlap |
Pair each overlap band with a reply band, or "urgent" will mean both "live now" and "when you can." The later zone pays for the ambiguity.
| Overlap band | Reply you can expect | Live time |
|---|---|---|
| Green, shared daytime | Decisions and ordinary requests, same day | Short, with an exit line |
| Yellow, thin overlap | Written request with a UTC need-by | A true blocker only, pre-read already sent |
| Red, no shared daytime | Written request, answer on the next overlap | No, except the production page path |
Put both tables where week one will find them. Fuller reply wording is in response expectations that respect time zones.
Paste this, then refuse quiet exceptions:
Decision hours: 13:00 to 15:00 UTC on weekdays
Outside those hours: a complete written request, reply on the next overlap
Urgent production: the incidents channel only
Handoff fields: Changed, Verify, Do not redo, Next, Owner
Late slot: rotated, never the same region three weeks in a row
Example. Assumptions: you are in Prague, the team is in Chicago, shared daytime is your afternoon and their morning, and that window is yellow rather than a full day of green. Protect it for decisions. Write the rest. Do not join every Chicago 09:00 as if you shared their day. Put Wednesday's early stop on the roster. On a daylight-saving week, reconfirm the offset before you accept a repeating invite: DST mistakes remote teams make.
When two people you need share no daytime, use a brief, a deadline, and a default if they stay silent. A rare live exception can rotate. The week it is weekly, it is policy. Public holidays shrink green. Update the roster before the week and cancel the slot that would only guilt the people who showed up. Name the hop. "Manila to Berlin owns the next move" is usable. "The team overnight" is not an owner.
After two quiet overlaps, one bump, same fields, new UTC cutoff. If the choice is still tied, a short slot in the next green or yellow window, decision written before you leave. A third quiet overlap means the default. Do not add a status series about the silence.
Put the clocks in the vendor or client contract. Name the overlap, the response window, and who absorbs a rare red-band call. If they can only meet in your red band, put that in the price or in a rotation with an end date.
A new hire adds real hours, sends one complete request, and leaves one handoff. For two weeks, count unfair invites, requests with no UTC deadline, and handoffs that needed a call. Fix one series. If you cannot name who took the late slot, export the calendar before you talk about culture.
Live hours still have to leave maker time: fewer and better remote meetings. Field-by-field continuity: leave work someone else can continue. Protect green for decisions and blockers. Spend yellow only with the pre-read already sent and a UTC need-by. Keep red in writing. Run the five steps before any new series.