What this question measures
Almost every company with distributed teams has this problem, whether the split is London and Singapore, Toronto and Bengaluru, or two teams in one country that never overlap. A team at the centre decides something in its afternoon, and your team discovers it in the morning as a fact. The work changes, the plan slips, and nobody asked.
The interviewer is checking three things. Can you separate a systemic problem from a personal one? Can you change how decisions get made without authority over the people making them? And can you do it without becoming the person who works until midnight to attend every meeting? That last one matters. Heroics hide the problem and make it depend on you.
This differs from the case where another team will not deliver what you need, which is covered in a time another team was blocking you. Here the other team is moving fast. They are just moving without you.
Diagnose the decision path before arguing with a decision
Start by learning how decisions actually happen on the other side. Usually it is one of a few patterns. A weekly meeting is held at a time your team cannot attend. A product manager decides in a chat thread and announces in a ticket. Or a lead assumes silence means agreement because your team never objected in time.
Each pattern needs a different fix. In distributed teams, the root cause is often that your team's constraints are invisible at the moment of choice. The headquarters engineers are not ignoring your release freeze or your downstream consumers. They do not know about them.
So the first concrete step is to write those constraints down where the deciders will see them: your dependencies, freeze dates, on-call commitments and the systems you own. That costs an afternoon and removes a surprising share of the friction.
Change the mechanism with decision records
The durable fix for distributed teams is to make decisions asynchronous by default. A lightweight decision record works well. It is a short document stating the problem, the options, the proposal and who is affected, shared before the decision rather than after.
The detail that makes decision records work across time zones is the comment window. A window of one full working day in each location means nobody has to stay up late to be heard. Agree it with the other team's lead as a shared rule, not a demand from your side. Also agree an exception path for genuinely urgent decisions, otherwise the first emergency breaks the process.
| Before | After |
|---|
| Decision made in a meeting at 17:00 headquarters time | Proposal posted, open for comment for one working day in each time zone |
| Your team learns of it from a changed ticket | Your team is a named reviewer on anything touching its services |
| Objections arrive after work has started | Objections arrive while changing course is still cheap |
Rotating the occasional live meeting so the inconvenient hour is shared also helps. It signals that both teams' time counts.
Escalate the decision, not the people
Sometimes a decision still lands badly. Then escalation is legitimate. Take one specific decision with a concrete cost, such as "the API change shipped on the 3rd broke our month-end batch, and we spent four engineer-days recovering". Go to the leader both teams report into, ideally with the other team's lead included. Ask for a process change, not a reversal or an apology.
Blaming headquarters is the fastest way to lose this question. If the story casts the other team as arrogant and your team as victims, the interviewer imagines you describing their team that way next year.
How the story can sound, told from your own facts
"Our product team was based in the US and we were in Europe, with about two hours of overlap. Three times in one quarter they changed an event schema we consumed, and we found out when our pipeline failed overnight.
I asked their lead how schema changes were decided. It turned out they were agreed in a meeting at the end of their day, and nobody there knew we consumed those events. So I wrote a one-page list of our dependencies on their services and asked to be a named reviewer on anything touching them.
We agreed a simple decision record template with a one-business-day comment window, plus a same-day path for urgent fixes. The next schema change came through as a proposal, we spotted a field we depended on, and they kept it for one more release. It cost us twenty minutes instead of a lost night.
I did escalate once, about a release-calendar change, and I did it with their lead in a joint note to our shared director. Looking back, I should have asked how decisions were made in the first month rather than the third."
Where strong answers separate from adequate ones
With distributed teams, an adequate answer resolves one incident. A strong answer changes the system so the next decision cannot land unseen, and then says how it held up. Mention what happened six months later: did the decision records keep being used, did they survive a change of lead on either side, and did you accept decisions that went against your team? Admitting you lost some of those arguments, and were fine with it, makes the rest of the story believable.
Across time zones, influence comes from being present when the decision is made. Written proposals with a fair comment window make that possible without anyone working at midnight.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).