Who Decides What When Your Team Spans Three Asian Time Zones
A cross-border team in Asia rarely fails because people lack skill. It fails because nobody can say, with confidence, who is allowed to decide a given question, where that decision gets recorded, and what happens when the person who holds the answer is asleep. A product lead in one city, a finance counterpart two hours away, and a regional operations manager whose working day barely overlaps with either can each be competent and still produce a week of delays over a single pricing change. This article looks at decision rights as a practical design problem. It offers questions to ask, a sequence for settling them, and a checklist you can apply before your next hire or market launch.
Separate decisions from discussions
Most distributed teams treat every thread as a decision, which means no decision is ever clearly closed. Start by separating three things: discussion, recommendation, and decision. Discussion is open input. A recommendation is a proposal from a named person with a stated reason. A decision is a choice made by someone with the authority to make it, recorded in a place others can find.
When you review recent friction, sort the last twenty important questions into these three buckets. You will often find that many items labeled as decisions were actually discussions that stalled, or recommendations that were implemented without anyone holding authority over them. That count tells you more about your structure than any org chart does.
Map who holds which context
Authority and context are different things. The person who should approve a vendor contract may know nothing about the vendor's delivery history, while a support lead in another market knows exactly why the last integration failed. Good decision design routes context to the decision, even when the formal approver is elsewhere.
For each recurring decision type, ask three questions. Who has the relevant information today? Who is accountable for the outcome? Who must be consulted before anything becomes final? Write the answers in a simple table with rows for decision types such as pricing changes, hiring offers, customer escalations, release scheduling, and budget reallocations. Columns should be Decides, Informs, Consults, and Records. Keep the table short enough that a new team member can read it in five minutes.
Design handoffs around the time gap
When teams sit in Singapore, Bangalore, and Manila, a handoff at the end of one person's day becomes a waiting period for another person's morning. The fix is not to ask everyone to work longer hours. It is to make each handoff self-contained. A handoff note should state the current status, the decision needed, the options considered, the deadline, and the person who will act if no reply arrives.
Test your handoffs with a simple rule: could someone who was not in the conversation act on this note without asking a clarifying question? If not, the note is missing context. Build a default fallback as well. If the approver has not responded within a defined window, name who may proceed and under what conditions. A fallback is not a bypass; it is a way to prevent quiet stalls from becoming a cost nobody chose.
Ask these questions before your next hire or market entry
Before adding a person in a new location or market, pressure-test the structure with direct questions. Which decisions will this person own on day one, and which will they only recommend? Who in the existing team currently holds the context this person will need, and is that knowledge written down or stored in one person's memory? If the person in the other time zone is blocked, what is the first thing that stops? Which records, such as contracts, payroll details, and customer histories, live in systems that more than one person can access?
Also ask what would happen if a key person left next quarter. If the honest answer is that a decision would simply stop, you have a context ownership problem, not a hiring problem. Address it before adding headcount, because more people working around an unclear structure multiplies confusion rather than capacity.
A practical checklist for cross-border decision rights
Use this checklist as a working review rather than a one-time exercise. First, confirm that each recurring decision type has one named owner. Second, confirm that the owner can see the context needed, either through shared records or a short written brief. Third, confirm that every handoff note contains status, options, deadline, and fallback. Fourth, confirm that finalized decisions are recorded in one agreed location that the whole team can search. Fifth, schedule a monthly review in which you check whether any decision stalled for more than two business days and why.
Revisit the decision table every quarter, because team membership and market conditions change. Structures that worked with three people in one market often break when a fourth person joins in a second language or time zone. The goal is not a perfect model. It is a shared, visible agreement about who decides, what they know, and how the rest of the team learns the outcome.