My Team Switched to English-Only Meetings — Here's How I Survived the First Month

DevGlish Team

In January, our startup in Taipei hired two developers — one from Poland and one from the Philippines. The next Monday, our CTO announced in our group chat: "Starting this week, all meetings will be in English so everyone can participate."

There were twelve of us on the engineering team. Eight were Taiwanese, two were the new hires, and two were Taiwanese-Americans who spoke English fluently. For the eight of us, this announcement landed like a cold shower on a Monday morning.

We all spoke some English. We'd all studied it in school for at least ten years. We read English documentation daily. But speaking English in a meeting, in real time, with other people listening — that was a completely different thing.

Week one: the silent majority

The first English standup was painful for everyone. Our CTO led it in English and went first, modeling the format: what he did yesterday, what he's doing today, blockers. It took him about twenty seconds. He's fluent.

Then he passed it to the rest of us, and the energy in the room shifted. Most of us delivered updates that were technically in English but functionally minimal: "Yesterday I worked on the login page. Today I continue. No blockers." Some people spoke so quietly that the two remote team members couldn't hear them.

The sprint planning meeting was worse. In Chinese, our discussions were lively — people debated approaches, challenged estimates, suggested alternatives. In English, the same people sat quietly while the CTO and the two fluent speakers dominated the conversation. The rest of us nodded, said "sounds good," and saved our real opinions for the Chinese side conversations afterward.

This was the core problem of the first week: the switch to English didn't just change the language. It changed who spoke. The most experienced engineers on the team — people with strong opinions and deep knowledge — became the quietest people in the room because they weren't confident enough to express complex ideas in English.

Week two: the workarounds

By the second week, we'd developed coping strategies, some healthy and some not:

The Slack pre-write. Several of us started typing our standup updates in Slack before the meeting, then reading them aloud. This worked surprisingly well. The act of writing forced us to organize our thoughts, and having the text in front of us removed the blank-mind panic of live speaking. It wasn't spontaneous, but it was clear and complete.

The bilingual huddle. After each English meeting, the Taiwanese developers would regroup in Chinese to discuss what was actually said. "When he said 'we should punt that to next sprint,' what did he mean by 'punt'?" "I think 'scope creep' means the feature is getting bigger than planned." These post-meeting debriefs were where the real understanding happened.

The dictionary tab. I kept DevGlish open in a browser tab during every meeting. When someone used a phrase I didn't understand, I'd quickly look it up. "Technical debt," "bikeshedding," "time-box" — terms I'd seen in writing but never heard spoken at natural speed. Having a developer-focused lookup tool was faster than Google because I got the tech meaning immediately, not a generic definition.

The avoidance strategy. Some colleagues simply stopped participating in discussions and only spoke when directly asked a question. This is the unhealthy workaround. It solved the anxiety problem but created a new one: their ideas and expertise were invisible to the team, which affected project decisions.

Week three: the breakthrough

The turning point came during a code review meeting where I needed to explain a complex state management decision. In Chinese, I could have explained it in two minutes with precise technical detail. In English, I started struggling after the first sentence.

Our Polish colleague — who was also a non-native English speaker — interrupted gently and said: "It's okay to be slow. We'll wait. I'm not a native speaker either, and I'd rather hear your actual thinking than a simplified version."

That comment changed the atmosphere. It gave everyone permission to speak imperfectly. After that meeting, our conversations became slower but richer. People started saying things like "Let me think about how to say this..." or "My English is not great, but the technical problem is..." and then delivering thoughtful, substantive contributions.

I realized that the barrier wasn't really language — it was the fear of sounding stupid. Once that fear was addressed, people who'd been silent for two weeks started talking. Not fluently, not elegantly, but clearly enough. And clarity was all that mattered.

What specifically helped me improve

Over the first month, a few deliberate practices made the biggest difference in my English meeting skills:

I prepared key phrases before meetings. Before sprint planning, I'd think about what I might need to say and prepare the English phrasing. Not a script — just key phrases. "I estimate this at three points because..." or "I think we should split this ticket because the frontend and backend work are independent." Having these ready reduced the cognitive load during the meeting.

I learned to buy time. Native speakers use filler phrases constantly — "that's a great question," "let me think about that," "so basically what we're looking at is..." These phrases serve no informational purpose, but they're essential for live conversation because they give you time to think. I deliberately added a few to my repertoire: "That's a good point. I think..." and "So if I understand correctly..." These small buffers prevented the awkward silences that made me panic.

I practiced technical explanations out loud. In the shower, on my commute, during lunch — I'd explain technical concepts to myself in English. "The reason I chose React Query over SWR is that..." or "This component re-renders too often because the parent passes a new object reference each time." Speaking alone removed the social pressure and let me focus on finding the right words.

I asked for key terms in advance. Before meetings where I knew specific topics would come up, I'd look up the relevant English terminology. If we were going to discuss database indexing, I'd make sure I knew how to say "composite index," "query plan," "full table scan," and "covering index" in English. This preparation was quick — maybe five minutes — but it prevented the frustrating moment of knowing the concept but not the English word.

One month later

By the end of the first month, our meetings had found a new normal. They were slower than the Chinese ones had been — probably 30% longer for the same content. But everyone participated. The Polish and Filipino developers, who'd been excluded from Chinese conversations, were now fully integrated into technical discussions. And we Taiwanese developers had crossed a threshold that felt impossible four weeks earlier.

My English is still far from perfect. I still pause to search for words. I still occasionally describe something awkwardly and have to rephrase. But I can express complex technical opinions in real-time discussion, which is something I genuinely couldn't do on that first Monday.

If your team is considering a switch to English, or if you've just been through one, here's my advice: the first two weeks will be awful. Accept that. The meetings will be quieter, shorter, and less productive than before. But it gets better faster than you expect, especially if one person — a manager, a colleague, anyone — creates a culture where imperfect English is treated as normal rather than embarrassing.

The language barrier is real, but it's thinner than it looks. Most of us already have the vocabulary and grammar we need from years of reading English documentation and code. What we lack is practice speaking, and the only way to get that practice is to speak. Meetings, for all their awkwardness, are the practice.