Who Owns the Answer? Decision Logs for Cross-Border Asian Teams
Cross-border teams in Asia rarely fail because people lack skill. They fail because the answer to a common question depends on who happens to be awake, who was in the last call, and which chat thread someone remembers reading. A decision that was settled in a Singapore meeting can be quietly reopened by a colleague in Jakarta who never saw the notes, and a product tradeoff agreed in Tokyo can resurface three weeks later in Bangalore as if it were new. The problem is not a lack of communication. It is that decisions do not travel well unless someone deliberately makes them portable. This article describes a decision log approach: a simple, shared record that captures what was decided, who had authority to decide it, what evidence supported it, and under what conditions it should be revisited. It is a method you can design yourself, without assuming any particular software, and it works whether your team uses a spreadsheet, a wiki, or a plain document.
Why decisions drift across borders
Decisions drift for predictable reasons. Teams spread across several markets often operate with different working hours, different languages for internal discussion, and different levels of access to the same conversations. A product manager may run a weekly review in English, while an operations lead handles most coordination in a local language and only summarizes outcomes afterward. Neither approach is wrong, but the summary is usually lossy. The reasoning that justified a choice disappears first, then the constraints, and finally the owner.
Drift also comes from ambiguous authority. When a regional lead, a founder in a home office, and a local country manager all believe they can approve a pricing exception or a hiring change, the team will eventually act on whichever approval it saw last. Decision logs help because they force the question of authority into the open at the moment of decision rather than after a conflict has begun.
What a useful decision log records
A decision log should be short enough that people will actually update it. Each entry needs a date, a plain statement of the decision, the name or role of the person who had final authority, and the people consulted. Avoid recording only the conclusion. Add one or two sentences on the context: what problem prompted the decision, what alternatives were considered, and what information was missing at the time. Those details are what allow a later reader to judge whether the decision still holds.
Include a review condition. Instead of leaving a decision open-ended, note what would make it worth revisiting, such as a change in regulation in one market, a shift in customer volume, or the arrival of a new hire with relevant expertise. Review conditions turn a static record into a working tool, and they prevent the common pattern where a decision is either endlessly reopened or never questioned at all.
Questions to ask before you approve anything
Before a cross-border decision is logged as final, a few questions help clarify it. Who is the single accountable owner, and is that person in a position to act on the decision? Does this decision affect more than one market, and if so, have the affected leads seen the proposal in writing rather than hearing about it secondhand? What information would change this decision, and is that information currently available to everyone who needs it?
You should also ask whether the decision depends on a tool, vendor, or platform that the team does not control. If a choice relies on a particular developer platform, mobile ecosystem, or regional service, record that dependency explicitly. A decision that looks sound today may become costly if the underlying dependency changes terms or availability, and noting the dependency makes that risk visible to the people who will inherit the decision later.
Comparing informal and logged decision-making
Informal decision-making, where choices live in chat messages and memory, is fast in the short term. A quick message can resolve a question within minutes. The cost appears later, when a new team member joins the Manila office and cannot find out why a vendor was chosen, or when a dispute arises between two markets and no one can reconstruct the original agreement. Informal methods scale poorly because the cost of reconstruction grows with every person and every time zone added.
A logged approach adds a small upfront cost. Someone must write the entry, and the team must agree on where entries live. In return, the team gains continuity. The trade is usually worth it for decisions that affect budgets, hiring, pricing, customer commitments, or cross-market priorities. It is less necessary for routine operational choices that are easy to reverse. A reasonable rule is to log anything that would be expensive or awkward to explain to someone who was not there.
A practical checklist to start this week
Begin by choosing one shared location that every team member can access, and agree that it is the only official record. Next, list the four or five decision types that most often cause confusion on your team, such as hiring, pricing, market sequencing, and tool adoption. Assign an accountable owner for each type, and write that assignment down so that authority is not inferred from seniority or habit.
Then run a two-week trial. Each time a notable decision is made, create an entry with the date, the decision, the owner, the people consulted, the context, and the review condition. At the end of the trial, check how many decisions were reopened without cause, and how many were reopened because new information appeared. That ratio tells you whether the log is doing its job. Adjust the template, keep what helps, and drop fields that nobody reads. The aim is not perfect documentation but a shared memory that all time zones can trust.