Setting Response Time Expectations for Remote Teams

A designer I worked with in Berlin sent a question to her engineer in San Francisco at 5pm on a Friday. Something like "when you get a sec, does the export button need a loading state?" In her head it was the lowest-stakes message she'd sent all week. No rush, genuinely. Look at it Monday.

He saw it at 8am Saturday his time, read the @-mention and the question mark, and spent forty minutes of his weekend digging through the export flow to write a careful answer she wouldn't open until Monday anyway. He wasn't being a hero. He just had no way to know it could wait, because nobody had ever told him what could.

Neither of them did anything wrong. The problem was that the two of them had never agreed on how fast a reply is supposed to come, so each one filled that silence with a private guess. Her guess was "sometime next week." His was "right now, or I look like I'm ignoring her." The guesses didn't match, and a two-minute question cost somebody a chunk of their Saturday.

Every team already has a response-time norm. Most never said it out loud.

In an office, you learn the norm by watching. You see that Dave answers Slack in a minute but takes two hours on email, that nobody expects a reply after 6pm because the desks are empty. You absorb it without anyone writing it down, and within a couple of weeks you know exactly how urgent "urgent" really is here.

Remote deletes that entire signal. You can't see that your teammate stepped away for lunch, or that she's heads-down and has Slack closed on purpose, or that it's 9pm where she is and she's putting her kid to bed. All you see is a message you sent and a reply that hasn't come. So people build a norm out of the only material they have, which is their own anxiety, and anxiety writes a harsh rule: answer fast, always, or someone will think you're slacking.

That rule produces two people, and every remote team has both. There's the anxious waiter, who sends a message and then can't concentrate on anything until it's answered, refreshing the thread and quietly deciding they've been snubbed. And there's the compulsive answerer, who keeps a Slack tab open through dinner because someone three timezones away might need something, and can never fully log off because "what if." Both are miserable for the same reason: nobody ever told them what the actual expectation was, so they defaulted to the most punishing version of it.

Timezones turn a small gap into a guessing game

Everything above is true for a team sharing a city. Spread that team across timezones and the guessing gets much worse, because now you genuinely cannot tell the difference between "she's ignoring me" and "she is asleep."

Send a message to someone nine hours ahead and the silence that follows is total. In a shared timezone, an hour of quiet reads as "busy, will get to it." Across a wide gap, six hours of quiet reads as nothing at all, because you can't tell whether they're at their desk, at dinner, or unconscious. The anxious waiter's spiral feeds on exactly this ambiguity. It's the same missing-context problem that makes a bare "3pm" so expensive: the reader is left filling gaps the sender could have closed up front. A response-time norm closes the gap for silence the way a timezone label closes it for time.

Put the expectation in hours, not vibes

The fix is unglamorous. Write the norm down, in numbers, and make it about the receiver's clock rather than the sender's.

Something as plain as this works: a normal Slack message gets a reply within one business day, counted in the timezone of the person receiving it, not the one who sent it. That last clause is the whole game on a distributed team. "By end of day" is meaningless when your two ends of day are ten hours apart. Anchoring the window to the receiver's working hours means a message fired off at your 5pm is due by their next afternoon, not overdue because it aged overnight while they slept.

Then tier it, because not everything deserves the same clock. A direct question in a project channel gets one business day. A "no rush" message gets whenever, and everyone actually honors the "no rush." Anything genuinely time-sensitive doesn't go through normal Slack at all, which I'll come back to. The exact numbers matter less than the fact that they exist and everyone knows them. A stated norm, even an imperfect one, beats twelve people each inventing their own.

This is really just async-first communication applied to the clock. Async-first says put things in writing so people can respond on their own schedule. A response-time norm is the promise that makes that safe: I can wait for my working hours to reply, and you can trust a reply is coming, because we agreed on when.

Separate "I saw it" from "I solved it"

Here's the move that does the most to kill the anxious-waiter spiral, and it costs nothing.

Decouple acknowledgment from resolution. If someone asks you something that'll take real work to answer, you don't owe them the answer inside the response window. You owe them a signal that you got it and roughly when the real reply is coming. A thumbs-up. A one-line "seen this, I'll dig in after my morning meetings and get you a proper answer by end of my day." Ten seconds of typing, and the person on the other end stops staring at a void wondering if they've been ignored.

Most response-time anxiety isn't about waiting for the answer. It's about not knowing whether the message landed at all. The compulsive answerer feels they have to resolve everything the instant it arrives precisely because they've never learned that a quick acknowledgment can stand in for a full response. Once a team internalizes that "I saw it" and "I fixed it" are two different messages, the whole thing relaxes. You can protect a long focus block and still fire off a two-word acknowledgment when you surface, and nobody spends the morning feeling snubbed.

Give real emergencies their own door

None of this works if everything travels through Slack with the same weight. The production outage and the "what do you think of this copy" cannot arrive in the same channel with the same ping, or people will either treat everything as urgent, which is exhausting, or nothing as urgent, which is dangerous.

So build a separate door for the rare thing that genuinely can't wait. A phone call, a page to whoever's on call, or a specific @here in one channel that the whole team agrees means "drop what you're doing." The emergency path should be loud, unambiguous, and used almost never, which is exactly what lets everything else be quiet. When there's a real escape hatch for the true fire, people can let a normal message sit for a day with a clear conscience, because the one thing that can't wait has its own way of reaching them. It's the same notification discipline good Slack etiquette is mostly about: matching the loudness of the alert to the real urgency of the thing.

The manager writes the real policy

You can put a beautiful response-time norm in the team handbook and have it mean nothing, because the norm people actually follow is the one the manager demonstrates.

If you're a lead and you answer every message within four minutes at all hours, including 11pm your time and straight through the weekend, you've written the real policy, and it says "we are always on." Your report in another timezone sees you replying at what is midnight for you and quietly concludes that constant availability is what gets rewarded here. It doesn't matter what the doc says. They'll match the behavior, not the text. So if you want people to respect the window and log off without guilt, you have to visibly do it yourself, and if you must send something off-hours because that's when your brain worked, schedule it to land in their morning instead of pinging them at midnight. The norms a distributed team lives by get set from the top, by example far more than by policy.

The goal was never speed. A team where everyone replies in thirty seconds isn't healthy, it's just anxious together. The goal is predictability. When everyone knows how fast a reply is supposed to come, the waiter stops refreshing, the answerer closes the tab, and a question sent at 5pm on a Friday can be exactly as low-priority as the person who sent it meant it to be.

Stop Guessing Across Timezones

A response-time norm only works if "reply by end of your day" means the same thing to the person who wrote it and the person reading it half a world away. Timely converts every time mention in Slack to each reader's own timezone automatically, so your windows, deadlines, and "back by 2pm" all read correctly wherever your teammates happen to be, and one more source of guessing disappears.

Add Timely to Slack — Free · See how it works