Walk into the weekly planning meeting of an advanced development program today and count the countries. The program that prompted this article runs design in one country, assembly and test partners in two others, and advisors in a fourth, with several European languages, Japanese, Taiwanese and English behind a single shared thread of business English. None of that is unusual anymore. Ambitious technology development now means connected systems built by companies on three continents, coordinated mostly in writing, in a language most participants did not grow up speaking.
We find major communication problems on most of these teams, and not because anyone lacks skill; the engineers on these threads are excellent. The problems are structural. Basic language friction, politeness that hides non-understanding, and small misreadings that compound as the work builds on them. On a modern program, where hardware, firmware, software and connected cloud systems all have to integrate on a date, this is not a soft topic for a training deck. It is schedule risk of the first order.
The politeness trap
The expensive failure is not vocabulary. It is the question that never gets asked. People are reluctant to say they do not understand, because the admission feels like an insult in both directions: to the other party's English, or to their own competence. So both sides do the polite thing. They nod, they write "understood," and they proceed on their best guess. Erin Meyer's The Culture Map catalogs how differently cultures handle exactly this moment: in some business cultures "yes" commits, in others it only acknowledges, and disagreement with a counterpart is phrased so gently that an outsider hears agreement.
The trap tightens over time. When a guess turns out wrong and the discovery comes late, trust drops on both sides, and asking gets harder on the next exchange. We watched this dynamic operate on the program we wrote about in Break it down together, where a partner team's strongest available signal of disagreement was the word "confused," and the client had to learn to treat that word as a fire alarm.
Misunderstandings compound
A single misread exchange is cheap. The damage comes from what gets built on top of it. One side closes the email believing a decision was made; the other side starts work on a different decision; and every later exchange reads as confirmation to both, because each is interpreting new words inside its own version of the agreement. The gap grows quietly, over weeks, and surfaces loudly, at integration, as rework and a slip. The complexity of today's programs makes this worse, not better: more interfaces, more handoffs, more places where two readings of one sentence can set two teams building different things.
The industry data says this is the main event, not a side effect. PMI's research on project communications put US$135 million at risk in every US$1 billion of project spend, with US$75 million of it, 56 percent, attributable directly to ineffective communication. Those figures come from projects in general. Multi-language, multi-site programs sit at the hard end of that distribution.
One email chain, read three ways
On one of our client programs we decided to measure this instead of arguing about it. We took a single routine thread, one day of messages from a weekly planning loop whose writers work across several European languages, Japanese, Taiwanese and English, and had Claude read every message three ways: what the words say, what the writer most plausibly meant, and how the other side was most likely to read it. The result is below, with every identifying detail removed. The sentences are lightly reworded; their shapes are untouched.
One day of thread held all of this. A written recap of a morning phone call, declaring three samples equally good. A reply that disputed the recap while sounding like a passing doubt: "if I'm not wrong." A route recommendation dressed as deference, "of course, we rely on headquarters' decision," from the person closest to the problem. A silence-is-consent deadline that expired while half its recipients slept. And one American idiom asked to carry the program's new top priority across four countries.
The analysis is not an indictment of anyone's writing. Nobody wrote badly, and nobody acted in bad faith. What saved this thread deserves more attention than what threatened it: people wrote their understandings down. The recap email was a read-back, and the correction it drew out, politely hedged as it was, is exactly the disagreement the morning's phone call had failed to surface. The call ended with everyone in apparent agreement. The written recap proved they were not, in time to matter. The full analysis is downloadable below: a one-page case study of the thread, and the complete message-by-message translation table.
A reader with no accent
This experiment is also a case for what an AI reader adds to a multinational team, and it is not translation. Claude reads without tone and answers without face to lose. It can observe that a sentence is a correction disguised as a doubt, or a recommendation disguised as deference, because the observation lands on the words rather than on a colleague. Nobody on the thread could say those things without cost. A model can, in minutes, and the output is a table everyone can point at instead of an argument about what people intended.
We now run this reading as a standing system rather than a one-off. We built a Claude skill and agent that continually read the program's email and Slack traffic and run the translation continuously, so said-versus-meant gaps surface in days instead of at integration. The same neutral-reader method builds our fishbone analyses from the meeting record and finds the systemic patterns that programs cannot see from inside. A communication thread is simply another record to read, and the teams that benefit most are the ones whose human readers carry the strongest accents, in every sense of the word.
What survives translation
The durable fix is not better English. On a program drawing on this many language groups, prose loses meaning no matter how carefully anyone writes. The fix is to move the load-bearing communication out of prose and into structure, and the thread we analyzed contained its own antidote: a numbered plan, each row a task with an owner and a due date, and a second table showing which piece of work released which. Nobody on four sites needed an interpretation of those tables. A task, an owner, a duration, a dependency and a date read the same in any language.
Make the check a system
The way out of the politeness trap is structural. A read-back required on every handoff insults nobody, because everyone does it. "Tell me what you heard" stops being a challenge to a colleague's English the moment it is simply how the program runs.
This is why the network schedule, built with the development partner rather than handed to them, sits at the center of our method: it is the one document on the program that is structure all the way down. The weekly refresh re-verifies, week after week, that both sides still mean the same thing by the same dates, and the questions we ask of it get answered from the plan instead of from recollection. The plan is the shared language. Everything else is commentary on it.
Assume divergence
You cannot train the accents out of a global program, and you should not want to; the reach is the reason the partners are there. What you can change is the assumption that polite agreement means shared understanding. Assume divergence. Write the recap, require the read-back, keep decisions in the plan instead of the prose, and once in a while hand a thread to a reader with no accent and ask what each message meant. The words will keep diverging. The program does not have to.
Related on lateralworks: What causes delay? and The weekly schedule refresh.
Downloads
- The thread that read as agreement — the one-page case study, with the plan and thread as appendices (PDF)
- Every message, translated line by line — the full translation table (PDF)