Coverage Across Time Zones Without Turning Everyone Into On-Call

Coverage is what the team does about questions that arrive when their owner is off. On-call is what the team does about systems that break. Merging them is the most common structural mistake on distributed teams, because it applies an expensive, high-alert mechanism to a problem that is mostly ordinary, and it leaves the ordinary problem to be absorbed informally by whoever is most conscientious.

"Our 'coverage' is one senior engineer who never logs off."

Two problems that keep getting merged

On-call is well understood. It has a rota, an escalation path, an alerting system, and usually some form of compensation. It fires rarely and the response is defined.

Coverage has none of that on most teams, despite being enormously more frequent. Someone in another zone needs to know what was decided, where a piece of work stands, or whether an approach was already tried. Nothing is broken and nobody should be paged, but the person needs an answer in order to keep working. So they message whoever they think will reply, and the answer is nearly always the same person.

The rota of one

That person earns the role by being responsive, which is a trap. They answer once, get asked again, answer faster, and within a quarter they are the team's search engine. Their own work moves to the evening, because their day is spent on other people's unblocking.

This arrangement looks like strong culture from the outside. It reads as a helpful senior engineer and a team that communicates well. Three things are actually true: the team's continuity depends on one individual's habits, that individual is heading toward burnout on a schedule nobody is watching, and the moment they take real leave the team discovers how much of its coordination was undocumented. The cost profile is covered in bus factor of one.

What coverage actually is

Coverage is not a person. It is two things in order.

First, an answerable record. The large majority of coverage traffic is questions whose answers already exist: what was decided, where something stands, what is blocked, who owns it. Those answers do not need a human awake, they need to be reachable during the asker's working day.

Second, a named human for the remainder. Some questions genuinely require judgement that nobody has written down. For those you need one name per area, known in advance, with clear limits on what they can decide in the owner's absence.

This is what StandIn provides for the first part. Each person spends ninety seconds at the end of their day confirming a brief that is mostly drafted from the work they already did: current state, open questions, blockers, next actions. When they are off, their StandIn is on, answering from that brief in their words, with a source under every answer, clearly labelled as their StandIn. When the answer is not in the brief, it says so and names who to ask, which routes the genuinely human question to the genuinely human backup instead of to whoever happens to be online.

The senior engineer stops being the coverage model. The record covers the questions, the named backup covers the judgement calls, and the on-call rota covers the incidents. See working across time zones.

Building it in three steps

Step	What you do	Takes
1. Count the traffic	Label two weeks of out-of-hours messages: question, decision, or incident	Two weeks, passive
2. Make the questions answerable	Daily brief per person, four fields, ninety seconds	One sprint to become habit
3. Name the humans	One backup per area, with stated decision limits	An afternoon

Step one is not optional. Teams consistently overestimate the incident share and underestimate the question share, and the count is what convinces people that the fix is a record rather than a bigger rota. For a per-person version of step three, see a coverage plan for a twelve-person team.

Keep on-call small and paid

Once questions are handled elsewhere, on-call can shrink to what it should be: a small rota, for genuine incidents, with real compensation and a real escalation path. That is a healthier arrangement than a large informal expectation of availability, and it is also cheaper, because informal availability is paid for in attrition rather than in money.

Two rules keep it honest. Only alerting systems page people, never colleagues. And anything that pages someone outside their hours gets reviewed the next working day, with the question: could this have waited until morning, and if so, why did it not?

Common Questions

What is the difference between coverage and on-call?

On-call responds to systems that are broken and should be rare, compensated, and alert-driven. Coverage answers questions from colleagues when the owner is off, and is frequent and low-stakes. Treating coverage as informal on-call is how one helpful person ends up permanently available.

How do we stop people messaging the same helpful person?

Give them somewhere better to go first and make it faster than the person. Habits move when the alternative is quicker, not when a policy asks people to be considerate. Redirecting in public helps: answer with a link to the record rather than the fact.

Should coverage be compensated?

If it requires someone to be available outside their working hours, yes, and that is a good reason to make as little of it as possible require that. Coverage handled by an answerable record costs nothing and wakes nobody.

What if the answer really is not written down anywhere?

Then the honest response is to say so and name who to ask. That is far better than a guess, because a wrong answer delivered confidently costs more than a delay. Each of those moments is also a signal about what should be in tomorrow's brief.