Coordinating a Product Launch Across Timezones

The feature went live at 8:15am. The problem was whose 8:15am.

A team I worked with was shipping a redesigned billing flow. The plan, as everyone understood it, was to "launch Thursday morning." The backend engineer in Berlin had the final piece merged and tested by his Thursday morning, saw green checks, and flipped the flag. Reasonable. It was also 8:15am in Berlin, which is 11:15pm Wednesday in San Francisco, where the support lead who was supposed to be watching for billing errors was asleep, the help-doc update was still in draft, and the "we've changed how billing works" email hadn't gone out. For about seven hours the new flow was live to every customer with nobody minding it. The first person to notice was a user who opened a ticket at 2am Pacific asking why their invoice looked different. Support read it when California woke up. By then the thing had been out, unannounced and unwatched, for most of a night.

Nobody made a mistake, exactly. The launch just didn't have a moment. It had a weekday, and a weekday on a distributed team is not a moment. It's a rolling twenty-four-hour smear where every person's "Thursday morning" is a different point on the clock, and if you don't pick one, the earliest riser picks it for you.

A launch is one instant. "Launch day" is two days.

This is the part that trips up teams who've otherwise gotten good at async. A deadline can be soft. You can anchor "by Friday" to a real date and one named clock and let people hit it whenever their day allows. A launch is the opposite kind of thing. It's a single instant when something becomes true for the whole world at once, and everything else has to be arranged around that instant rather than scattered across the day.

So the first decision isn't when in your day to launch. It's what single moment, in one timezone, the go-live actually happens, written down where nobody can misread it. Not "Thursday morning." Something like "9am ET Thursday, October 9." That one line settles a dozen silent questions. It tells Berlin not to flip the flag at his 8am. It tells the support lead exactly when to be at her desk. It tells marketing when the embargo lifts. A launch without a named instant isn't a launch. It's a race to see whose morning comes first.

Pick that instant for the people it has to serve, not for the person whose finger is on the button. If the launch needs support awake and the biggest support presence is in the US, put the go-live in the US morning even if that means your European engineer is triggering it after lunch. The launch exists to land well for customers and for the people who'll catch the fallout, not to be convenient for whoever ships the last commit.

Everything true before the button, done before anyone's morning

The reason that billing launch went sideways wasn't the flag flip. It was that half the launch wasn't ready when the flag flipped, and it wasn't ready because "we'll finish it Thursday morning" quietly meant four different Thursday mornings.

A coordinated launch has a pile of things that must all be true at the go-live instant. The docs are published. The announcement is queued. The support team has been briefed on what's changing and what'll break. The rollback plan is written down and someone knows how to run it. On a co-located team these get finished in the nervous hour before launch, everyone in the same room. Across timezones that hour doesn't exist, because your launch instant falls in the middle of somebody's night.

So the pre-flight work can't live in the launch window. It has to be done and verified before the earliest-affected timezone goes to bed the day before. Treat the go-live instant as a hard gate and walk backwards from it: anything a sleeping person was going to do "the morning of" either gets done the day before or gets explicitly handed to someone who's awake at the instant. This is the same discipline as writing things down so nobody has to be awake to answer a question, aimed at the riskiest hour a distributed team has. The launch checklist isn't a formality. It's the list of promises that all have to be kept at once, by people who are mostly not online together.

Name the person who presses the button, and the people awake behind them

Two roles decide whether a distributed launch goes smoothly, and both get skipped because they feel obvious until they aren't.

The first is who actually triggers the go-live. One named person, at the named instant. Not "engineering will ship it." That's how you get Berlin flipping the flag at his 8am because he assumed he was engineering and nobody told him otherwise. Name the human, in writing, and give them a single explicit condition: launch at 9am ET, not before, not when the last check turns green. The green check is not the launch. The named instant is.

The second role is who's awake for the hours after. A launch isn't over when the button's pressed. That's when it starts, and the first few hours are when billing errors and broken flows and confused-customer tickets surface. If your whole team is asleep for that window, you've recreated exactly the situation from the billing story. This is where a distributed team actually has an edge, the same one that makes on-call work better when you map the rotation to daylight: somebody, somewhere, is already awake. Use it. Assign the post-launch watch to whoever's in daylight at the go-live instant, brief them properly, and treat the moment their day ends as a real handoff of understanding to the next person coming online, not just a shrug and a Slack scroll. Launch coverage is a follow-the-sun problem. Solve it like one.

The announcement lands at one instant too

External comms have their own version of the same trap. An embargo, a launch email, a blog post, a social thread. These are all supposed to hit at the go-live instant, and if they're set to "send in the morning" they'll fire on whoever's morning comes first, sometimes hours before the product they're announcing is actually live.

Schedule them to the exact instant, in the exact timezone, tied to the same named moment as the go-live. And write out the order plainly: flag flips, then support confirms the flow works in production, then the email sends, then the public post. When those steps are spread across people in different timezones, the sequence only holds if it's written down as a sequence with owners, because the person sending the email at their 9am has no way to see that the flag hasn't flipped yet in someone else's night unless you've made that dependency explicit.

Don't gather everyone live to watch it

The instinct on launch day is to pull the whole team into a call and watch the graphs together. On a distributed team that call lands in the middle of someone's night, and it mostly exists to soothe nerves rather than do work. Skip it. Run the launch in one channel, in writing, with a clear running status anyone can read when their day starts, the same reason a written update beats a status meeting for a team that isn't all awake at once. The person coming online in Manila four hours after go-live should be able to scroll one channel and know exactly what happened, what broke, what got fixed, and what still needs eyes, without waking anyone to ask.

There's a real exception, and it's worth naming so you don't over-correct. A genuinely high-risk launch, the kind where a bad rollout could take down payments or lose data, sometimes earns a live window where the key people are online together on purpose, watching in real time, ready to roll back in seconds. That's a deliberate call, not a default. When you make it, pick the instant so the people who'd run the rollback are awake and sharp for it, and hold the same clear expectation of who responds and how fast during that window that you'd hold for an incident. Reserve the synchronous launch for the launches that would actually hurt. Everything else ships fine in writing.

The pattern underneath all of it is the same one that shows up everywhere on a distributed team. A moment that feels obvious when you're in a room together, the shared "okay, we're live," has to be manufactured on purpose when the room is spread across sixteen hours of clock. Name the instant. Finish the work before anyone's night. Put one person on the button and awake people behind them. Then the launch happens once, cleanly, instead of leaking out across a day while half the team sleeps through the moment it was supposed to be watching.

Ship Your Launch at One Instant Everyone Reads Correctly

The fastest way to blow a coordinated launch is a go-live time that reads as a different moment to each person on the team. Timely converts every time mentioned in Slack to each person's own clock automatically, so "we go live at 9am ET Thursday" lands as the same instant whether it's read in Berlin, San Francisco, or Manila, and nobody flips the flag on the wrong morning.

Add Timely to Slack — Free · See how it works