Lived Operations

How We Work When the Client Is Awake After Our Team Goes Offline

Our build team in Lahore signs off nine hours before the client in Austin sits down to check on things. The gap only costs us money when the client's question has to wait for a person to wake up.

Miles AinsleyMiles Ainsley7 min read
One lit window glowing among a row of dark windows at night.

Our development team works out of Lahore. Most of our clients are in North America. By the time our engineers log off at the end of their day, it's still mid-morning in Austin or New York. The client wakes up, opens the project, and has questions. Nobody on our side is awake to answer them for another eight or nine hours.

People assume this is the hard part of offshore work — the gap itself. It isn't. The gap is fixed and predictable; you can plan around a fixed thing. What actually costs money is when a client's question has to wait for a specific person to log back on, because the answer only exists in that person's head.

The gap is not the problem

Nine hours of non-overlap sounds like a structural weakness. In practice it behaves more like a shift handoff at a hospital — which works fine, because nurses don't rely on catching the outgoing doctor in the hallway. They read the chart. The chart is the interface, not the person.

We treat the end of our day the same way. The question we ask before anyone signs off is never "did I tell someone," it's "did I write it down somewhere the client will actually look." Those are different questions, and teams that only answer the first one are the ones paying an offshore tax nobody bills them for directly — it shows up as slower decisions, more escalations, and clients who start emailing a person's name instead of the project.

4:45 PM Lahore — the last twenty minutes

The final block of our day isn't spent finishing code. It's spent finishing sentences. Any task that's mid-flight gets a progress report before the laptop closes — not "working on it," but what's done, what's next, and what's blocking. If a task is genuinely stuck on something the client controls — a missing API key, an unclear requirement, a design decision — that becomes a request addressed to them directly, not a comment buried three replies deep in a thread they may never reopen.

A handwritten notepad lit by a desk lamp at dusk.
The last twenty minutes before sign-off aren't spent typing code. They're spent writing down what the next person needs to know.

This is where a Request earns its keep over a Slack message or a task comment. A request sits in the client's inbox with a sender, a thread, and nowhere to hide. It doesn't scroll away under the next ten messages the way a chat mention does. When our engineer is asleep and the client opens the project at 9 AM Austin time, the thing they need a decision on is waiting for them as a discrete, answerable item — not a paragraph they have to hunt for.

9:00 AM Austin — the client's morning, our night

This is the part that used to be expensive. The client reads the update, has a follow-up question, and — in the old way of working — sends it to a person. That person is asleep. The question sits for nine hours doing nothing, and everyone quietly agrees this is just what offshore work costs.

A person reading notes at a kitchen table in early morning light.
Nine hours later, someone else picks up where the notes left off — before anyone on the build team is awake to explain them.

The fix isn't a faster person. It's making sure the answer to most morning questions is already sitting in the project before the question gets asked. A due date that's close or already passed gets a follow-up whether or not a human remembered to chase it — TAI handles that specific case without anyone staying up. A task that's still sitting as a Draft doesn't quietly rot either; it gets flagged the same way. None of this replaces a person making a judgment call. It just means the client isn't the one discovering, nine hours late, that something they were waiting on never actually moved.

What has to be written down before sign-off, and what doesn't

Not everything needs a durable note. If a task is finished and verified, closing it is enough — nobody needs a paragraph explaining that it's done. The discipline is reserved for the handful of items where the next reader is a different person in a different timezone with no way to ask a clarifying question in real time.

  • Anything blocked on the client: a decision, an asset, an approval — goes out as a request, addressed, not left in a comment thread
  • Anything deployed: what shipped, to where, and what to check — written once, not explained twice over two timezones
  • Anything half-finished: a progress report on the task itself, not a private note to self
  • Anything that will become urgent while we're asleep: a due date close enough that it should already have a reminder attached, so nobody is relying on memory across the gap

Escalation rules that don't depend on someone being awake

We learned this the slow way: an escalation path that says "message the lead" is not a path, it's a hope. Our actual rule is boring on purpose. If something is blocking the client and it can't wait nine hours, it goes to whoever holds the client relationship on our side as a request, flagged for a decision, and it goes there whether or not the engineer who caused the block is reachable. The point of writing it as a request instead of a private message is that a request has a clear owner and a visible thread — the next person to open the project doesn't have to reconstruct who said what to whom.

We also stopped assigning people to half-formed tasks before they're ready to be worked. A task that's still a draft — still being shaped, not yet real — doesn't page anyone. It becomes live, and notifies whoever's on it, only once it has a due date or a place in the schedule. That single distinction removes a surprising number of 2 AM notifications that used to wake someone up for something that wasn't actually ready to be acted on yet.

The actual saving isn't speed, it's fewer round trips

The nine-hour gap will never close. What closes is the number of times a question has to travel back and forth across it before it's answered. Every round trip costs a full day, because a question asked at 9 AM Austin doesn't get read until 6 PM Lahore, and the answer to that doesn't get read until 9 AM Austin again. Two round trips and you've lost most of a week over something that could have been a single well-placed note.

The teams that handle this well aren't the ones with the most overlap hours. They're the ones where context doesn't need a person to carry it across the gap — where the update, the blocker, and the decision needed are sitting in the project, addressed and specific, before anyone has to ask.

Continue Reading