How to Set Deadlines Across Timezones

The release was due "Monday." The engineer in Auckland read that, finished the last of it on her Monday morning, and pushed it live. Perfectly reasonable. Except it was still Sunday afternoon in San Francisco, where the marketing lead had a launch thread scheduled for 9am Pacific and a customer email queued up behind it. By the time California woke up, the feature had been live and unannounced for the better part of a day, a confused support ticket was already open about it, and the "coordinated launch" turned into a scramble to catch up with something that had already shipped. Nobody missed the deadline. Everybody hit a different one.

That's the deadline problem on a distributed team, and it's sneakier than the meeting problem. Everyone has learned by now that a bare "3pm" needs a timezone stapled to it. Almost nobody thinks a "Monday" does. So the ambiguity that gets caught in a meeting invite sails straight through in a deadline, where it does far more damage, because a deadline is a promise about the future that two people are quietly interpreting differently until the moment it comes due.

"By Friday" is not a deadline

Here is the uncomfortable part. The words we reach for most when we set deadlines are the vaguest ones we have. "By Friday." "End of day." "Tomorrow." "By end of week." "COB." These feel precise because they name a specific day, and a day sounds concrete in a way that "sometime soon" doesn't. But every one of them hides two separate ambiguities, and across a timezone gap both fire at once.

The first is the obvious one: whose day. "End of day Thursday" ends in Bangalore about thirteen hours before it ends in California. If a manager in San Jose asks for something "by end of day Thursday" and the engineer is in Bangalore, the engineer's honest read is their own Thursday evening, which is already Thursday morning for the manager who was picturing their own Thursday night. The manager has quietly handed over a full working day less than either of them realizes. Neither person is wrong. They anchored the same word to two different clocks.

The second ambiguity is quieter and worse: what "end" even means. "End of day" for a person who starts at 7am is not the same instant as "end of day" for a night owl three seats over, even in the same city. Stretch that across a nine-hour gap and "by Friday" spans a window nearly two calendar days wide, from the earliest riser's Friday morning to the latest worker's Friday midnight, on the far side of the planet. A "deadline" that wide isn't a deadline. It's a suggestion with a date attached.

The date line makes the days themselves disagree

If your team spans far enough, you hit a problem that no amount of "add the timezone" quite fixes, because the ambiguity isn't the hour anymore. It's the day itself.

When it's Tuesday morning in Los Angeles, it's already Wednesday morning in Sydney. The two of you are living in different calendar days at the same physical moment, and every relative word you exchange has to cross that seam. "Let's aim for Wednesday" from the LA person lands on a Sydney colleague who is already halfway through their Wednesday. "This weekend" doesn't even name the same forty-eight hours for the two of you. The word points at a different slot on each person's calendar, and both feel completely certain they know what it means.

This is a different beast from the hour-level confusion of a bare "3pm". You can defuse a 3pm by writing "3pm ET." You cannot defuse "Wednesday" by writing "Wednesday ET," because the reader in Sydney still has to figure out which of their days your Wednesday overlaps with, and they will usually just assume it's theirs. The fix has to attack the day, not only the clock.

Anchor the deadline to one clock, in writing

The habit that kills this is simple to state and weirdly hard to build: pin every deadline to a specific date, a specific time, and one named timezone, and write it down where the work lives. Not "by Friday." Not "end of day." Something a person in another hemisphere cannot misread: "by 5pm ET on Friday, August 22." That version survives the date line, survives daylight saving, survives the reader who starts at dawn and the one who works past midnight. It costs a few extra words and it removes an entire category of silent slippage.

Two details make it bulletproof. Attach the calendar date, not just the weekday, so "Friday" can't drift a day when it crosses the seam. And anchor to the clock of the person who actually needs the thing, because the deadline exists to serve them. If marketing in California needs the release before their Monday morning, say "ready by 9am PT Monday, October 6," and let the engineer in Auckland convert it once, deliberately, instead of guessing. The person setting the deadline owns the ambiguity. If you're the one asking, you're the one who spells it out precisely enough that the other side has nothing left to assume.

This is really just writing things down so nobody has to be awake to ask you what you meant, applied to the one sentence people are laziest about. A deadline buried in a Slack message as "let's wrap this up tomorrow" is a landmine for whoever reads it eight hours later on the wrong side of midnight. The same deadline written as a real date and time in the ticket is just information.

Deadlines have a shape, not just a moment

There's a subtler thing that experienced distributed teams do, which is stop treating a deadline as a single point and start treating it as a window with a buffer built in for the gap.

Say a design needs sign-off before engineering can start, the designer is in Lisbon, and the engineers are in Denver. If the deadline is "sign-off by end of day," the designer finishes at 6pm Lisbon time, which is 10am in Denver, and the engineers get most of a day to run with it. But if a single question comes back, that question crosses a night and the whole thing slides. So the useful move is to set the internal deadline earlier than the real one, on purpose, sized to the round-trips the work might need. One likely back-and-forth means one sleep cycle of buffer. This is the same arithmetic behind why a pull request that needs three review rounds costs three days: across timezones, the delay isn't the work, it's how many times the ball has to cross an ocean before it's done.

Framing deadlines this way also forces a healthier conversation up front. Instead of "can you get this done by Wednesday," you end up asking "how many times will we probably need to pass this back and forth, and does the calendar actually have room for that." Often it doesn't, and it's far better to learn that on Monday than to discover it Wednesday night when the person who could unblock you has already gone to bed.

Weekends and holidays don't line up either

One last trap, because it catches people who have otherwise gotten good at this. "By the weekend" and "early next week" assume a shared calendar that distributed teams don't have. Your Friday afternoon push-to-finish is already someone's Saturday. And national holidays scatter across a global team in a way that makes "let's hit this by end of month" quietly impossible when half the deadline window falls inside a public holiday you didn't know existed.

The fix isn't more precision on the individual deadline. It's keeping absence visible in the first place, so you're not setting a Thursday deadline for a person whose Thursday is a national holiday. That's exactly what a shared, always-visible view of who's off and when buys you: the ability to set a deadline that a real human, in their real calendar, can actually meet. A deadline set into someone's day off isn't ambitious. It's just going to be late, and now it's late and resented.

None of this means turning every "let's aim for Friday" into a legal document. Plenty of soft targets between teammates are fine loose, and over-specifying a low-stakes nudge just makes you exhausting to work with. The rule is proportional: the more a deadline matters, the more people depend on it, and the wider the timezone gap it has to cross, the more it earns a real date, a real time, and one clock everyone reads the same way. Save the precision for the deadlines that would actually hurt if they slipped. Those are the ones the gap is waiting to eat.

Make Every Deadline Read the Same in Every Timezone

A deadline is the worst place to leave a time ambiguous, because nobody notices the mismatch until the thing is already late. Timely converts every time mention in Slack to each person's own clock automatically, so "ready by 9am PT Monday" lands correctly whether it's read in Auckland or Denver, and the deadline you set is the deadline they see.

Add Timely to Slack — Free · See how it works