How to Keep a Project Moving When the Decision Maker Is Offline
The Manila team hits a fork at 4pm their time. The client who can unstick it is asleep in Chicago. Here is what to leave behind so the work does not just sit there until morning.
It is 4:40pm in Manila. The build is done except for one question: does the pricing page show the discount before or after tax. The client who owns that answer is in Chicago, where it is 3:40am. Nobody is rude enough to call. Nobody is foolish enough to guess and ship it. So the task sits, untouched, until someone in Chicago wakes up, checks their messages, and replies around 9am their time — which is 10pm in Manila. Eighteen hours lost over a sentence.
I have run that handoff more times than I can count, on both ends of it. The instinct everyone has is to try to eliminate the dependency — write better specs, hire more decisive clients, give the offshore team more authority. All three help a little. None of them remove the actual fact: someone far away has to decide something, and they are asleep. The teams that handle this well do not pretend the gap doesn't exist. They make the dependency explicit, they bound it, and they leave behind exactly enough for the decision to get made without them in the room.
Not every question deserves the same wait
The first mistake is treating every open question as equally blocking. It isn't. Before you let a task sit, ask what happens if you're wrong.
- Reversible and cheap to undo — pick the sane default and keep moving. Nobody needs to approve whether the empty state says "No tasks yet" or "Nothing here yet."
- Reversible but annoying to undo — make the call, write down why, and flag it for review next time the decision maker is online. A button color. A placeholder copy line. A sort order.
- Irreversible or expensive to undo — this is the one that actually blocks. Pricing shown to real customers. Data deleted. A contract term. A public-facing claim about the product.
Most tasks people let sit overnight belong in the first two buckets. The discount-before-or-after-tax question from Manila belonged in the third — it touches money and customer trust, and reversing it after launch means apologizing to people who were charged the wrong amount. That one was right to wait. Most of what gets stuck isn't.
Write the decision down before you hand it off, not after
The eighteen hours in the Manila example weren't lost to time zones. They were lost because the question arrived as a single line — "pricing page: discount before or after tax?" — with none of the context the Chicago client needed to answer it in thirty seconds instead of a ten-minute re-read of a spec from three weeks ago. A decision-ready handoff does four things in one message:
- States the decision in one sentence, not a question that requires archaeology to understand.
- Names the default you'll ship if you hear nothing by a stated time.
- Shows the two or three options, with the tradeoff of each in a half-sentence.
- Gives a deadline tied to something real — your next deploy window, not "whenever you get a chance."
Here's what that looked like the second time I ran into the same kind of question, on a different project:
Decision needed: show the loyalty discount before or after tax on the cart page.
Option A — before tax: customer sees the bigger discount number, tax is calculated after. Matches how most of our competitors show it.
Option B — after tax: smaller number shown, but matches the receipt exactly, fewer support tickets about mismatched totals.
Default if no reply by 9am your time: Option B, because it matches past support complaints we've already seen on this account.
This blocks the Thursday deploy. If we don't hear back, we ship the default and can flip it in five minutes once you're up.
Notice what this message isn't: it isn't a ticket that just says "waiting on client." It names a default, it names a reason for that default, and it names what happens if silence is the answer. The client wakes up, reads it in under a minute, and either confirms the default or overrides it. Either way, nothing sat idle waiting for a conversation that could have been a decision.
Escalation rules you set on a calm Tuesday, not a tense Friday
The worst time to figure out who can approve a decision is the moment you need the decision approved. On a project I ran with a client split across three time zones, we agreed on a simple rule up front: any decision under a dollar amount we'd already agreed on could be made by the account lead without waiting for the client at all. Anything above it, or anything touching a contractual term, waited — but waited with a named backup. If the primary contact was unreachable for more than one full business day, the request went to their deputy automatically, no apology needed, no one had to ask permission to escalate.
Write that rule down somewhere everyone can see it before the first time zone gap actually costs you a day. It should answer three things: who can decide what without asking, who the backup is when the first person is unreachable, and how long is too long to wait before escalating. If the answer to the third one is "use your judgment," people will wait too long, because asking for help feels like admitting the plan has failed. A stated threshold — say, more than one working day with no reply on anything that blocks a deploy — takes the judgment call off the person who's already anxious about bothering the client.
Assumptions are not the enemy of good decisions, bad bookkeeping is
Every team that works across time zones ends up making assumptions on someone else's behalf. That's not a failure state — it's the only way work moves faster than a single person's waking hours. The failure is making the assumption silently. If you ship the default and don't write down that it was a default, three weeks later nobody remembers it was ever a choice, and now it's load-bearing in four other decisions. Write the assumption where the work lives — in the task, not in a chat message that will scroll away — and name it as an assumption, not a fact. "Assumed after-tax display per the template above, pending client confirmation" is one sentence. It costs nothing to write and saves a very bad afternoon later when someone builds on top of a guess they thought was a decision.
None of this requires new tooling, just the discipline to leave a decision-ready message instead of an open question. Where a tool like Team and Tricks actually helps is making the bookkeeping part cheap: a task can carry a due date that reflects the real deploy window, a progress report can hold the "here's what we assumed and why" note where the next person will actually see it, and the thread stays attached to the task instead of drifting off into a chat app someone has to go searching. The hard part — deciding what's reversible, naming a default, setting a real deadline — is still yours to do on the Tuesday it matters.
