Response-Time Expectations: Put Them in Writing Before Someone Burns Out

Almost every team has an unwritten response-time expectation, and almost every team has set it by accident. It is whatever the quickest person does, because that is the only observable data anyone has about what good looks like.

"'ASAP' means different things in Lisbon and Singapore."

The default nobody chose

Without a published standard, people calibrate on peers. The fastest responder becomes the benchmark, and since that person is often the most senior or the most anxious, the benchmark is high. Everyone else then either matches it or accepts looking slower than their colleagues.

This is how a team ends up with an implicit ten-minute expectation nobody would have agreed to if it had been proposed out loud. Writing it down is not bureaucracy; it is the only way to replace an accidental standard with a chosen one.

Why ASAP is unusable

"As soon as possible" transfers the judgement to the recipient and gives them nothing to judge with. Across time zones it is worse than useless, because the sender's soon and the recipient's soon are separated by a night.

It also inflates. Once ASAP is the standard phrase for anything mildly time-sensitive, people needing genuine speed have to escalate the language, and within a quarter the team has several tiers of urgency wording and no shared meaning for any of them.

Replace it with hours, always in the recipient's own working time. "By end of your Thursday" is unambiguous in every country.

The expectations table

Channel	For	Answered within
Team channel	Anything the team benefits from seeing	One working day, recipient's zone
Direct message	Personal or one-to-one only	One working day, recipient's zone
Board comment	Anything about a specific piece of work	Next working day
Email	External, records, long-form	Two working days
Phone or page	Customers affected now, or tonight's deadline	Fifteen minutes, on-call only
Their StandIn	Status and context questions, any hour	Seconds, from what they wrote down

The row people never write

Every table above the last row makes a promise on someone's behalf. The last row makes a promise that costs nobody anything, and it is the one that makes the others sustainable.

Most of what arrives in the first two rows is a status or context question: where does this stand, what did we decide, has this been tried. Promising a one-working-day response to those is generous to the asker and expensive for the answerer, and it is the promise that gets broken first when things are busy.

With StandIn, those questions have their own row. Each person confirms a ninety-second brief at the end of their day, and while they are off, their StandIn answers from it in their words, with a source under every answer, and never guesses: when the answer is not there it says so and names who to ask. Expected response time for a status question becomes seconds, and the one-working-day promise on the human channels becomes a promise the team can actually keep, because the volume behind it has dropped.

See working across time zones.

Making it believed

Publishing the table changes nothing on its own. Two things make it real.

Senior people visibly using the full time. If a manager answers everything in four minutes, the table is aspirational decoration. Answering some things the next morning, deliberately, is the act that establishes the standard.

And holding the urgency definition the first time it is tested by someone important. The team is watching what happens when a senior person's non-urgent request gets a next-day reply, and whatever happens then is the real policy.

Common Questions

What response time should we expect on a distributed team?

One working day for channels and direct messages, in the recipient's own zone, with a separate fast route for genuine emergencies. Anything faster as a blanket standard means somebody is watching their phone continuously.

Should response times be in elapsed or working hours?

Working hours, in the recipient's own time zone, always. "Within 24 hours" quietly obliges somebody to answer at midnight, which is exactly the outcome the table exists to prevent.

How do we handle genuinely urgent requests?

Define urgent by consequence in one sentence, give it a single route that is unmistakably an alarm, and restrict that route to the on-call person. Urgency stops inflating once it has its own channel.

What if people ignore the published times?

Check whether senior people are using them first, because that is nearly always the cause. A standard nobody senior exercises is not believed, whatever the document says.