"I can’t follow what others are saying."
“I’m getting completely lost in these technical debates.”
"I walk away from client calls feeling like I missed the most critical requirements."
Almost every time I begin working with software engineers, system architects, QA leads and product owners across different countries, these are the things they tell me.
You think you are an expert in your field. You write clean, efficient code. You have perfect architecture diagrams. You can fix incidents in production with ease. Once you start attending cross-functional meetings such as sprint planning, architecture reviews and client steering committees, everything changes.
You’ll find they move super fast. English speakers and those learning English will be using different accents, slang and clarity. Two senior architects will be having a heated debate about whether to go with a synchronous or event-driven API. They’ll be interrupting each other and throwing out new acronyms you’ve never heard of. You’ll feel exhausted, overwhelmed and confused with your notes because you’re struggling to keep up.
This has nothing to do with your intelligence or ability. This is a problem caused by the high volume of information being processed. When you’re trying to understand complex architecture concepts, cultural differences and a second language, your brain becomes overwhelmed.
Communication in tech can be broken down into different parts. By looking at IT as a technical skill, we can identify steps in our process to help us overcome some of the challenges. We can break down the noise so we can hear the signals. This will make us invaluable to our strategic partners.
1. Understanding the issue
Before we can solve a problem, we need to understand why IT’s happening. Why do technical meetings cause issues?
Overloaded Cognition
Our working memory can only really cope with around 4-7 pieces of information. During a typical tech meeting, your brain is trying to process:
Understanding complex technical concepts (distributed cache invalidation, latency, compliance)
Understanding English words, sentence structure and quick speech.
Understanding hidden messages (tone, stakeholder politics, underlying concerns)
Your own thoughts.
Due to your brain becoming overloaded with translating and understanding information, you’ll struggle to retain information. This is not due to a lack of knowledge in the subject but simply due to your brain running out of RAM.
Audio Quality
During virtual meetings, we lose a lot of body language cues. The low-quality audio, room echo, delay and sudden loss of the mic can cause confusion with the phonemes. People often talk over each other during video calls, and this gets compressed by the audio codecs, meaning we can’t understand what anyone is saying.
Jargon and Slang
Within tech, we rarely speak in pure English. There is a lot of jargon within business English. There are many idioms (“move the needle”, “touch base off-line”, “open the kimono”), military terms (“in the trenches”, “bite the bullet”) and temporary slang ("bikeshedding", “yak shaving”). If you’re an engineer who learnt English from books and academia, these idioms will cause confusion.
2. Phase 1 - Pre-Meeting Preparation (Pre-flight)
Having confidence in a meeting is done before you even enter. Just like you wouldn’t release code to production without testing locally, you should never enter a mission-critical meeting without preparing.
PRE-MEETING WORKFLOW
+-------------------------------+
| 1. Audit Agenda & Deck |
+---------------+---------------+
|
v
+-------------------------------+
| 2. Build Domain Glossary |
+---------------+---------------+
|
v
+-------------------------------+
| 3. Pre-Draft 2-3 Contributions|
+-------------------------------+
Audit your artefacts.
Before your call, spend 20 mins doing some prep work.
Agenda: What is the goal of the meeting? Is it purely informational/consultative/decision-making? You’ll know what type of information to pull from.
Pre-reads / PRDs: Look through any product requirement documents, Jira epics or slides for frequent nouns and verbs.
Who will be attending? Engineering managers, C-suite or end users? Engineers will talk about technical implementation, whilst business people will talk about business goals, costs and timelines. Adjust your mindset.
Develop your ‘Context Buffer': create a digital sticky note (Obsidian, Notion or Apple Notes). This will help give context to any terminology you might come across. Break down the terminology into categories:
Business terms: (ROI, ARR, EBITDA, SLA, SLO, TCO).
Project terms: (project names, integration points, tools).
Idioms: (any unknown idioms that your team may say, along with their real meaning).
Script your answers: This can be difficult when joining a quick English conversation. To help with this, script up two-three talking points. Create a template:
Pre-Draft Your Contributions
The hardest part of participating in a fast-moving English discussion is jumping into an existing conversational rhythm. Remove this hurdle by scripting two or three high-value talking points in advance. Use structured templates:
"Regarding the database migration, our primary blocker is the schema discrepancy between legacy environments and the target cluster."
"If our target is to reduce API response times below 200 milliseconds, we should evaluate caching strategies before refactoring the core query."
Having these points written out frees your mental capacity to focus entirely on listening, knowing your own speaking points are already formulated.
3. Phase 2: Active Listening Architecture (Real-Time Signal Extraction)
The Signal vs. Noise Filter
| Noise (Contextual / Social) | Signal (Decisive / Actionable) |
| Personal anecdotes and opening banter | Explicit architectural/design decisions |
| Speculative, non-binding brainstorming | Constraints (budget, dead drops, compliance, security) |
| Tangential debates resolved without consensus | Ownership allocations (Who is doing what) |
| Reiterations of previously known facts | Deadlines, deliverables, and blockers |
The “Verbal Anchor” technique
Listen out for key words that indicate a takeaway is coming when a native speaker speaks fast. Look out for:
Causal Connectors: "The bottom line is..." "What this boils down to..." "The core constraint here is..."
Pivots: "Having said that..." "The catch is..." "Where this falls apart is..."
Priority Keywords: "Non-negotiable", "P0 requirement", "Showstopper" "Must-have for MVP"
When you hear any of these words, stop what you’re doing (typing, multitasking) and give 100% of your attention to what they say next.
Live note-taking – The 3-quadrant method.
Don’t use a standard linear note-taking format. Split your notepad/document into 3 sections:
+-------------------------------------------------------+
| QUADRANT 1: DECISIONS & TRADEOFFS |
| - Chose PostgreSQL over MongoDB due to ACID needs |
| - Deferred offline syncing to Phase 2 |
+---------------------------+---------------------------+
| QUADRANT 2: ACTION ITEMS | QUADRANT 3: AMBIGUITIES |
| - Sarah: Update API specs | - What is the auth token |
| by Thursday | expiry window? |
| - Me: Benchmark read perf | - Clarify GDPR retention |
| on staging environment | policy with Legal |
+---------------------------+---------------------------+
4. Phase 3: The Clarification Playbook
Many non-native English speakers will remain quiet when they are confused due to fear they will look inexperienced if they ask questions to clarify. This is an extremely risky issue in engineering, as it results in you having unclear requirements, which could result in wasting many weeks of your development cycles.
Senior professionals will always be open about their confusion and use clarifying questions to create clarity.
Echo & Anchor: Never take for granted that you have understood how to implement a complex requirement. Echo back using your own wording what the person has said.
"Just to make sure I’ve captured that correctly: we are decoupling the notification service but keeping the user authentication service tightly coupled for the initial release. Is that right?"
"To ensure we’re aligned on the technical debt implications, you're proposing we bypass automated integration tests for this hotfix and run manual smoke tests instead?"
Graceful Interruption: Interrupt others who are talking over each other (2-3 people). Use bridging phrases to help you do this in a calm way.
Use transitional vocal bridges:
"May I jump in for a moment to ensure we’re aligned on this constraint before we move forward?"
"Before we finalise that decision, let’s make sure we haven’t overlooked the upstream impact on the ingestion pipeline."
"Could we pause right there? I want to make sure I have the exact parameter requirements before we address the next topic."
When you are struggling to hear the speaker due to bad audio quality, muffled speech or a strong accent:
Never say "I don't understand your accent"; try saying:
"The audio broke up slightly on my end. Could you repeat the rationale behind the third milestone?"
"There were a lot of moving parts in that last point. Could you restate the core deliverable for the frontend team?" Could I ask you to clarify what the frontend team needs to deliver?
"Let’s ensure we’re all operating on the same page. Could you write that endpoint URL and payload structure in the chat window?"
5. Phase 4: Structuring Your Spoken Contributions
The PREP Framework (For Opinions and Proposals)
[POINT]
"We should implement Redis caching for the user profile endpoint."
[REASON]
"Because the database is encountering severe I/O bottlenecks during peak morning traffic."
[EXAMPLE]
"During yesterday's stress test, database utilization hit 94%, causing latency spikes up to 3.2 seconds for basic read queries."
[POINT]
"Implementing Redis will absorb roughly 80% of those read requests and stabilize our database latency under 150 milliseconds."
The STAR-L Framework (For Status Updates and Post-Mortems)
- Situation: "At 09:00 UTC, the payment gateway began returning HTTP 504 gateway timeouts."
- Task: "Our objective was to isolate whether the failure stemmed from our service or the third-party processor."
- Action: "We routed traffic to the secondary fallback gateway and audited our webhook retry queues."
- Result: "Transactions returned to normal baseline within eight minutes, with zero double-charge events."
- Learning: "We are reducing the timeout threshold from five seconds to 1.5 seconds to trigger automated failovers faster in the future."
The "Disagree and Commit" Formula (Professional Pushback)
- "I understand the motivation to ship this feature ahead of the conference. However, bypassing the load-testing phase introduces a critical reliability risk for checkout. I recommend we ship the core UI as a preview, but keep the underlying transactional flow behind a feature flag until performance metrics pass our safety criteria."
6. The Non-Native Speaker’s Advantage
There is a stereotype in this industry that native English speakers communicate well. However, they can cause problems:
- Use of local colloquial terms/ sport related analogies/ references which confuse international colleagues.
- Speak at faster speed and include unnecessary filler.
- Often place emphasis on fluent communication, rather than clarity.
As a non-native English speaker or someone who is conscious with their language use, you can utilise what Linguists refer to as International English or Global Business English (BEE).
International English Best Practice
Avoid complex sentences – Using compound / complex sentences can cause confusion and lose your audience. Break complex thoughts down into short impactful points.
Use simple vocabulary – Instead of using phrasal verbs, which can be vague, use straightforward verbs. For example ‘investigate’, ‘cancel’ and ‘accelerate’.
Pause – Being fluent doesn’t mean speaking fast. By pausing between key points you will allow your audience to understand what you are saying. It will also show confidence and poise.
7. Daily Deliberate Practice: The 4-Week Communication Sprint
THE 4-WEEK SPRINT
+-----------------------------------------------+
| WEEK 1: Technical Podcasting & Shadowing |
+-----------------------+-----------------------+
|
v
+-----------------------------------------------+
| WEEK 2: Silent Synthesis & Meeting Audits |
+-----------------------+-----------------------+
|
v
+-----------------------------------------------+
| WEEK 3: The Clarification & Echo Challenge |
+-----------------------+-----------------------+
|
v
+-----------------------------------------------+
| WEEK 4: Structural Speaking (PREP Execution) |
+-----------------------------------------------+
Week 1: Technical Podcast Shadowing
Pick a podcast with 2+ people having a chat (Software Engineering Daily, The Changelog, Arrested DevOps etc.)
Listen to 10 mins of a podcast at 1.0x speed. After every 30 seconds stop playing the audio and repeat back exactly what the person said in the same time frame with the appropriate tone, pitch and emphasis.
Shadowing helps build muscle memory for pronunciation of complex technical terms so you can speak them easily and without thinking during calls.
Week 2: Passive Listening and Note Taking
During every meeting with your team and low speaking involvement, focus on note taking.
Use the Split Page Technique to note down the meeting. Write a 3 bullet summary of what was decided in the meeting within 5 mins of the call finishing. Compare your notes to the official meeting notes or slack threads.
This trains your brain to filter out unnecessary information.
Week 3: The Clarifier Commitment
Commit to getting involved in at least 1 discussion each day to clarify, rephrase or ask for clarification.
Use the Echo & Anchor method. "Can I just clarify something before we move ahead?"
This makes saying something uncomfortable become second nature.
Week 4: PREP Framework
Every time you’re asked a question in a meeting, use the PREP framework. Point, Reason, Example, Point.
This creates concise answers and removes any waffling. You’ll also sound more authoritative with your technical opinions.
8. Communication cheat sheets
Add these to your daily routine so you stay clear in your communications.
Clarify / Rephrase Cheat Sheet
"If I’m hearing you correctly, our primary blocker is..."
"Let me replay that back to you to ensure our design specifications align..."
"To make sure we don't have any conflicting assumptions: are we prioritizing delivery speed or complete feature parity for this sprint?"
Challenge / Rephrase Cheat Sheet
"That is a solid approach for the happy path. What happens when our upstream dependency drops connection?"
"I see the value in that feature, but I'm concerned about the operational overhead it introduces for the on-call engineer."
"Let’s look at this through the lens of our latency budget before we sign off on this design."
Wrap Up / Ownership Cheat Sheet
"To ensure we maintain momentum, I will take ownership of profiling this query and report back on Slack by tomorrow afternoon."
"Who is running point on provisioning the new IAM roles for this service?"
"Let's document these three decisions in the architectural decision log (ADR) before we sign off."
Meetings shouldn’t be a test of your endurance and you shouldn’t feel left behind. They’re there to help you connect with your peers, build context and solve challenging problems. Using the same curiosity, structure and improvement mindset to Business English and active listening as you do in software design means your technical knowledge will be heard, recognised and scaled.
What challenges do you face regularly in your meetings? What methods will you try first?
