Every Tuesday I have a team sync. Six engineers, thirty minutes, everyone shares status. The content is easy — I know exactly what I shipped, what’s blocked, what’s next. I could write it all down in two minutes.
The hard part is saying it out loud, in English, in real time, while six people watch.
The actual bottleneck
I’m a Chinese-native engineer with ADHD and autism, working on Microsoft’s AI platform team. My English is fine — you’re reading it. I write PR descriptions, Slack messages, blog posts. Given ten minutes and a keyboard, I can express any technical idea clearly.
Meetings don’t give you ten minutes and a keyboard.
Meetings give you three seconds of silence after someone asks “what’s the timeline on that?” and your brain has to simultaneously: retrieve the technical answer, construct an English sentence around it, manage the social awareness that six people are waiting, suppress the ADHD impulse to go on a tangent about a related problem, and deliver it all before the conversation moves on.
That’s not a language problem. That’s a systems problem.
Real-time English generation under social pressure is the single most expensive cognitive operation in my workday. Not because my English is bad — because the generation step has a cost that native speakers don’t pay. They construct sentences from cached patterns. I’m compiling from source every time.
So I started treating it like any other performance problem: profile the bottleneck, then optimize.
The optimization: precompute and serve from cache
The insight is embarrassingly simple once you see it. Native speakers also prepare for meetings. They think through what they’ll say, anticipate questions, plan responses. They just do it in their head, because generating English is free for them.
I do the same thing. I just externalize it, because the generation step is expensive.
Before every sync, I generate three artifacts:
Status bullets. The factual content — what shipped, the numbers, next steps. This is the easy part. Claude pulls from git, Linear, and Slack, synthesizes a narrative. Two minutes, done.
Phrase bank. Exact sentences to say out loud, organized by function:
| Function | Phrase |
|---|---|
| Opening | “On my side — three things.” |
| Transition | “Next one —” / “The other piece is —” |
| Don’t understand | “Can you say more about what you mean?” |
| Need time | “Let me think about that and follow up on Slack.” |
| Closing | “That’s it on my side.” |
These cover the monologue. The part where everyone politely listens while you give your update. Useful, but not where the real difficulty lives.
Conversation scripts. This is the thing that actually changed my meetings.
Screenplay-format mock conversations
The hard part of meetings isn’t the status update. It’s the back-and-forth. Someone asks a follow-up question. Your phrase sheet doesn’t cover it. Now you’re composing English in real time while also thinking about the technical answer while also managing the social pressure of people watching you think.
So I generate movie scripts:
RYAN: So what's the status on the torch migration?
YOU: Path A is done — mai_config no longer requires torch at import time.
So the fifty packages that were blocked can now migrate.
Path B is in progress — I'm working on the Linux CI override.
RYAN: Nice. What's the timeline on Path B?
YOU: Probably this week, if the uv.override_requirement approach is clean.
I need to test it against the Docker images first.
(if unsure about timeline, pivot:)
YOU: Still scoping it — I'll have a better estimate after I test
the override mechanism.
SQUAD LEAD: Any blockers?
YOU: Nothing hard. The main open question is how system-installed torch
gets mapped in Bazel on Linux. I have a design, just need to validate.
(if you didn't understand the question:)
YOU: Sorry, could you repeat that? / Can you say more about what you mean?
Three things make this work instead of being a pointless exercise.
Real names, real patterns
The scripts use actual teammate names — not “Teammate A” or “the tech lead.” When Ryan asks a question in the real meeting, my brain recognizes the pattern instead of parsing it from scratch. It’s priming.
But it goes deeper. I ran meeting transcripts through analysis and built voice profiles for each coworker:
-
Squad Lead — “The Cushioned Director.” Hedges everything with “like,” “I guess,” “kind of.” Uses “cool” as punctuation between topics. Softens every directive with “it’d be nice” and “maybe we could.” Never confronts directly — redirects with “I want to table this for now.”
-
Ryan — “The Direct Systems Thinker.” Complete, well-formed sentences. Explains in problem-then-mechanism-then-implication pattern. Almost no filler words. Pushes back directly: “I just suspect that’s going to be problematic.” Dry humor.
-
Jay — “The Collaborative Builder.” Always extends, never contradicts. Opens with “I think it might be useful to…” and builds on whatever the lead just said. Data-oriented. Signature phrase: “along the same lines.”
-
Masatoshi — “The Concise Operator.” Short fragments. Direct answers. Minimal elaboration.
With these profiles, the scripts stop being generic dialogue and start being realistic simulations. When I rehearse a line from “Ryan,” it sounds like Ryan. The cadence matches. The vocabulary matches. So when the real Ryan asks the real question, my brain pattern-matches instead of parsing from zero.
This is the same trick that language immersion gives you — internalizing someone’s speech patterns so you can predict the scaffolding and focus on the content. Except instead of six months of exposure, I get it from one analyzed transcript.
Branching responses: covering the state space
You can’t predict exact questions. But you can predict categories — timeline, blockers, dependencies, scope — and pre-load a response for each. The (if X, say Y) format in the scripts is the highest-value part:
(if unsure about timeline, pivot:)
YOU: Still scoping it — I'll have a better estimate after I test
the override mechanism.
(if someone asks what "Path A" means:)
YOU: So we had about fifty packages that imported mai_config,
which pulled in torch transitively. They don't actually need
torch — they just need config values. I made that import optional.
(if you didn't understand the question:)
YOU: Sorry, can you rephrase that? I want to make sure
I'm answering the right thing.
The branching responses are where real-time generation gets converted to retrieval. Every branch I pre-load is one fewer sentence I have to construct on the spot. It’s the same optimization pattern as caching: precompute the expensive work, serve from memory at runtime.
And the recovery phrases — “can you rephrase that?”, “just to clarify, are you asking about X or Y?” — these are the emergency exits. Having them pre-loaded means I never freeze. I reach for the recovery phrase while my brain catches up. Removes the shame of not understanding, because the response is already there.
The practice protocol
The scripts are useless if you just read them silently. The whole point is building motor pathways — mouth moves, words come out, brain connects the intent to the sound.
- Read the script through once silently.
- Say your lines out loud. Not reading — performing. Mouth moves, voice projects, you hear yourself say it.
- If a line feels unnatural, flag it and rewrite. If you wouldn’t say it at a whiteboard, it doesn’t belong in the script.
- Focus on the branching responses. Those are the high-value rehearsals — the ones that cover the unpredictable parts.
Five minutes. That’s it. Those five minutes convert a meeting from “anxiety-inducing social performance in a second language” to “running lines I’ve already rehearsed.”
Why this is engineering
I think most people would file this under “language help” or “soft skills.” And sure, on the surface it’s about speaking English in meetings.
But look at what’s actually happening:
Profiling. I identified the bottleneck — not vocabulary, not grammar, not technical knowledge, but real-time generation under social-cognitive load. That’s a performance profile.
Data collection. I analyzed meeting transcripts to build voice profiles — extracting speech patterns, signature phrases, disagreement styles. That’s characterizing the production environment.
State space modeling. The branching responses map the possible conversation flows. Timeline questions, blocker questions, clarification requests, unexpected tangents. That’s enumerating the input space.
Caching. Pre-loading phrases and scripts converts generation (expensive) to retrieval (cheap). That’s the textbook caching optimization.
Testing. The practice protocol is a dry run — executing the code path before it hits production. If a line feels wrong during rehearsal, I rewrite it. That’s catching bugs before deployment.
Monitoring. After the meeting, I note which phrases I actually used, which questions came up that I didn’t anticipate, where I froze. That’s the feedback loop. Without it, the system doesn’t improve.
None of this is clever. It’s bog-standard performance engineering applied to a domain that most people don’t think of as engineering. But the problem has all the same structure: an expensive operation on the critical path, a predictable input distribution, and a cache that can absorb most of the cost.
The thing nobody tells you
Here’s what I wish someone had told me earlier: the gap between ESL engineers and native speakers in meetings is not primarily a language gap. It’s a latency gap.
I know what to say. I know the technical answer. I even know the right English words. The problem is assembling all of that into a spoken sentence fast enough to land before the conversation moves on. By the time I’ve constructed the perfect response, the topic changed two minutes ago.
Native speakers don’t have better answers. They have lower latency. Their English generation is a cache hit. Mine is a cache miss — every time, on every sentence.
The scripts don’t make my English better. They make it faster. They move the most common conversation patterns from cold generation to warm retrieval. And it turns out that’s the only optimization that actually matters in a meeting.
The content was never the problem. The delivery pipeline was.