My First English Standup Lasted 3 Minutes of Awkward Silence

When I joined a distributed team with developers in Seoul, Berlin, and Austin, I knew standups would be in English. What I didn't know was how completely different a Korean standup and an English standup would feel.

On my first day, the standup started on Zoom. The engineer from Austin went first: "Yesterday I wrapped up the migration script, today I'm picking up the caching ticket, no blockers." Fifteen seconds. Clean. Done.

Then Berlin: "Still working on the auth flow. I'm blocked on the API spec — Sarah, can we sync after this?" Another ten seconds.

Then it was my turn.

I had prepared notes in Korean. I knew exactly what I'd worked on. But when I unmuted, everything I wanted to say evaporated. I said "Yesterday I... worked on... the, um..." and then trailed off for what felt like an eternity. I could hear my own breathing through the mic. After about three seconds of silence — which felt like three minutes — I managed to say "I worked on the database" and stopped.

"Any blockers?" the scrum master asked.

"No," I said. The meeting moved on.

What went wrong (it wasn't my English level)

Here's what frustrated me: my English wasn't bad. I could read documentation, write code comments, and even draft technical emails in English. I'd passed an English proficiency test with a decent score. But speaking in a live meeting, with other people waiting, was a completely different skill.

The problem wasn't vocabulary — it was the specific vocabulary of standups. In Korean team meetings at my previous company, we used a different structure. We'd give longer updates with more context. We'd explain our reasoning, mention who we'd talked to, describe what we'd tried. A standup update in Korean might take a full minute per person.

The English standup format is compressed. You're expected to deliver information in a specific pattern — what you did, what you'll do, what's blocking you — using specific verbs and phrases that I simply hadn't encountered before.

The phrases I didn't know I needed

After that first standup, I started paying close attention to how my teammates spoke. I wrote down the exact phrases they used, not just the meaning but the specific words. A pattern emerged:

For yesterday's work:

• "I wrapped up [ticket/feature]" — meaning finished completely
• "I shipped [feature]" — meaning deployed to production
• "I spiked on [topic]" — meaning did exploratory research
• "I paired with [person] on [thing]" — pair programming
• "I got pulled into [thing]" — meaning unplanned work interrupted you

For today's plan:

• "I'm picking up [ticket]" — starting a new task
• "I'll continue on [thing]" — ongoing work
• "I'm going to spike on [topic]" — research phase
• "I need to circle back on [thing]" — return to something postponed

For blockers:

• "I'm blocked on [thing]" — can't proceed
• "I'm waiting on [person/team] for [thing]" — dependency on others
• "No blockers, but I could use a second pair of eyes on [thing]" — soft request for help

These phrases aren't in any textbook. They're developer jargon — the informal, spoken language of software teams. "Spiked on" doesn't appear in a dictionary. "Picked up a ticket" makes no sense if you don't know that "ticket" means a Jira card and "pick up" means to start working on it.

How I practiced

I started rehearsing my standup updates before each meeting. Not memorizing a script — just deciding which phrases to use and practicing saying them once or twice. "Yesterday I wrapped up the pagination PR. Today I'm picking up the search filter ticket. No blockers."

I also used DevGlish to look up phrases I heard but didn't fully understand. When someone said "I'll punt that to next sprint," I had no idea what "punt" meant in this context. It turns out it means to postpone or defer — borrowed from American football, where punting the ball sends it away from you. A regular dictionary would tell me "punt" means to kick a ball, which isn't helpful.

Within about two weeks, my standups went from painful to functional. Within a month, they felt almost natural. The key was learning the specific register of standup meetings — not improving my general English, but acquiring the narrow set of phrases and patterns that this particular context demands.

The unexpected vocabulary of daily work

Standups were just the beginning. As I settled into the team, I kept running into phrases that were obvious to native speakers but opaque to me:

• "Rubber duck it" — explain the problem out loud to find the solution (from rubber duck debugging)
• "Bike-shedding" — spending too much time debating trivial details
• "Yak shaving" — doing a seemingly endless series of prerequisite tasks
• "Greenfield" — a new project with no existing code
• "Tech debt" — shortcuts that need to be fixed later (this one I knew, but many don't)

Each of these has a specific origin story and connotation that you can't derive from the individual words. "Bike-shedding" comes from a nuclear power plant planning analogy. "Yak shaving" comes from a Ren & Stimpy episode. These are cultural references embedded in technical jargon.

What I wish someone had told me

If you're about to join an English-speaking team, here's what I'd tell you:

First, standups follow a pattern. Learn the pattern, not just the language. Listen to two or three standups before you participate, if possible. Write down the exact phrases people use.

Second, short is better. Native English speakers in standups aim for 15-30 seconds. If your update is longer than a minute, you're probably including too much detail. Save the details for Slack or a follow-up conversation.

Third, it's okay to say "no blockers" and stop talking. You don't need to fill silence. You don't need to justify why you have no blockers. Just say it and move on.

And finally: the awkwardness fades faster than you think. My first standup was painful. My tenth was fine. My fiftieth was autopilot. The gap between "I can't do this" and "this is easy" is much smaller than it feels in the moment.