How I Went from Avoiding English Stand-ups to Leading Them
I'll start with an honest admission.
For two years, I minimized my speaking time in daily stand-ups. My team had international members, but every morning I did the same thing: prepare my update in advance → read it robotically in the meeting → say "I'll send details on Slack" if anyone asked a follow-up question → effectively disappear once my turn was done.
"I'll send details on Slack" was my safe exit. I couldn't answer live questions in English — more precisely, the vocabulary didn't come automatically, so I couldn't assemble sentences on the fly.
Six months later, I was leading the weekly sprint review in English. Here's what actually changed.
What Was Keeping Me Silent
There's a pattern common to developers who struggle with English in meetings. It applied to me.
The problem wasn't lacking vocabulary. It was lacking automated vocabulary.
Writing English for technical content wasn't the issue — given time, I could write reasonable Slack messages. The problem was real-time speaking: when someone asked "What are the trade-offs of this implementation?", I knew what I wanted to say but the words didn't come immediately and precisely enough.
The reason is the difference between vocabulary you "have" and vocabulary that's "automated." Being able to find a word in your mental dictionary is "having" it. Using it without thinking is "automating" it. Speaking requires automation — you can't search for words while simultaneously constructing sentences.
What I feared wasn't making mistakes — it was slowing down and appearing less capable.
Every time I spoke English in a meeting, what I feared wasn't being wrong. It was the visible slowdown of searching for words — the gap between how capable I knew I was and how capable I could express myself being obvious to everyone.
This particular fear is common among developers from Vietnam and East Asian countries: reading comprehension is high enough to process technical content almost perfectly, but speaking and writing output is significantly weaker. The gap between the you that understands and the you that can express.
What I Tried (And What Didn't Work)
Things I attempted:
Didn't work:
What worked:
The critical insight was that the English used in stand-ups is predictable. Every morning you say: what you did yesterday, what you're doing today, whether you have blockers. Making those patterns smooth in English isn't a large project.
The Exact English Phrases That Cover Most Stand-ups and Code Reviews
Here are the phrases that cover the actual language of English stand-ups and code reviews. Learning these as vocabulary produces fluency in 80% of meeting interactions.
In stand-ups:
In code reviews:
In technical discussions:
Each phrase above has predictable vocabulary. "Trade-off," "blocker," "sign-off," "LGTM," "edge case," "at scale" — these are 6–8 words that appear in half of all technical meeting interactions.
What the 6-Month Progress Actually Looked Like
Months 1–2: Focused SRS practice on technical vocabulary used in stand-ups and code reviews. 10 words per day, automatically practiced during daily CI builds and lunch. Vocabulary selection targeted to my actual tasks: "throughput," "bottleneck," "dependency," "breaking change," "regression..."
Month 3: Started being able to give stand-up updates without preparation. Answers to questions still needed thought, but the standup pattern became automatic.
Months 4–5: Code review comments became faster to write. Slack responses in English came quicker. "I'll send details on Slack" dropped to roughly half its previous frequency.
Month 6: Asked to facilitate the sprint review. Nervous that morning, but the actual facilitation was fine. The vocabulary I needed was already automated — I could focus on the content of what I was presenting rather than how to say it.
The Shift That Made the Difference
The change wasn't a dramatic breakthrough. It was cumulative.
As technical vocabulary became automatic — as "trade-off," "blocker," "regression," and "breaking change" moved from "I can find this word if I think for 2 seconds" to "it's already in my mouth before I decide to say it" — I stopped paying cognitive tax every time I needed to express a technical idea.
And when the cognitive tax dropped, two things happened:
The feedback loop from more exposure → vocabulary automation isn't luck. It's mechanics. The only question is which vocabulary to learn first.
Frequently Asked Questions
What if people speak too fast for me to follow in meetings?
Poor listening comprehension is about both familiarity with vocabulary and speaking speed. Improving vocabulary significantly reduces the cognitive overhead per sentence, freeing processing capacity for listening. In other words: vocabulary acquisition indirectly improves listening too.
I can't avoid English meetings. Where do I start?
Start by mastering the predictable parts: your stand-up update (same pattern daily) and Slack text (you have time to write). When these become fluid, you're better prepared for the harder real-time question sessions.
My accent is too strong. Will this approach help?
Accent is a separate issue from vocabulary. But there's a relevant insight: when vocabulary is automated, pronunciation tends to become clearer. When you're not using cognitive energy to recall words, you have attention available for pronunciation. Vocabulary speed and pronunciation clarity improve together.
The 6-month process wasn't linear. The first two months showed almost no visible change. Month three was when I started noticing. By month five I had stopped avoiding English communication — and not avoiding it gave me more practice, which accelerated the improvement further.
The most important shift wasn't a speaking skill. It was vocabulary automation. When you have the words waiting, the sentences come.