Estimated reading time: 9 minutes
Last updated May 2026
If you're a non-native English speaker on an international engineering project, you've probably had this moment: someone says something, you nod, you understand the words — but you're not entirely sure what they actually *meant*.
Or the reverse: you said something perfectly correct, and the other person looked at you like you'd suggested building a bridge out of cheese.
Miscommunication on international teams isn't just awkward. In engineering, it can be genuinely costly — delayed projects, wrong assemblies, or safety incidents. The good news: most of it is preventable. And it's not about speaking perfect English.
In episode no. 8 of the English for Engineers podcast, I sat down with Becky Paroz, a 30-year veteran of the Australian construction industry, QA specialist, and someone who has decoded more poorly translated technical documents than she'd care to count. Here's what she shared, plus a few things I'd add from my own experience as an engineer, English teacher, expat, and polyglot who has navigated exactly this.
The One Thing That's Making You Harder to Understand: Jargon
Let's start with the problem almost no one admits to.
Jargon isn't just a language barrier. It's a membership card.
As Becky explains it, jargon is what industries use to signal belonging — a shorthand that tells people who's in the club. The problem? When you're working across languages, regions, and disciplines, the club gets very small very fast.
It's not only a native vs. non-native issue, either. The technical jargon used on a construction site in Bavaria is different from Hamburg. And neither maps cleanly onto what an Australian QA engineer calls the same thing.
The first move: cut the jargon where you can, and replace it with plain language. Where you genuinely can't cut it — define it.
Why Translated Technical Documents Are a Nightmare (And What to Do About It)
Becky spent years in international procurement, which meant working with technical documents translated from German, Italian, Dutch — the full set. And she noticed something quickly: you can always tell whether a document was translated by a *language person* or a *tech person*.
A language translator makes the text flow. But they'll write "screw it in until tight" instead of "turn the screw 10 times, tighten, then break back off half a turn" — because to them, it means the same thing. To an engineer, it absolutely does not.
A technical translator gives you the right information — tolerances, steps, part references — but the sentence structure is all over the place. You can tell they've never read a native document in their life. But you get the information you need.
Between the two? Becky prefers the technical translation. The information is what matters. You can work around choppy sentences. You cannot work around missing specs.
A Checklist for Documents Your International Team Will Actually Understand
Whether you're writing a document from scratch or reviewing a translation, here's what makes the difference.
✓ Add definitions — yes, even for obvious words
Don't assume a word means the same thing to everyone. "Tolerance" in everyday English means patience. In engineering, it means a specific value with a number attached — plus or minus 2%, or whatever the spec says. Becky puts a definitions section in every procedure she writes, including for native English speakers. It eliminates the most common source of misread documents before anyone even opens the file.
✓ Double-check what you think you understood
This one is for non-native speakers, especially. Australian English is a masterclass in why this matters. "No worries" can mean "it's sorted," "we'll figure it out," "I heard you, but I'm brushing you off," or simply "you're welcome." Three completely different situations. One phrase. If a response doesn't fully add up in context, ask again — specifically.
✓ Clarity over capability
Using complex technical language signals expertise within your own discipline. To everyone else, it signals noise. Choose the clearest word, not the most impressive one. Your reader is already an expert in their field — don't make them decode your vocabulary on top of doing their job.
✓ Add a picture
When in doubt, draw it. This is not a cop-out — it's engineering. A well-placed diagram removes entire paragraphs of ambiguous instructions. Use them.
How to Actually Get Along With an International Team Day-to-Day
Documents sorted. Now what about everything else — the meetings, the handovers, the site conversations, the moments when someone's gut is telling them something's wrong, but they don't have the words in English yet?
Here's what Becky recommends, and a few things I'd add.
1. Tell people you're still learning the language
This sounds obvious, but most engineers don't do it. When you acknowledge upfront that you're working in your second or third language, people extend significantly more patience. You're not there to give a flawless English performance. You're there because of your technical expertise. That's the qualification that matters. Make sure people know which one they're getting.
2. Cultural differences are harder than language differences
Language is the visible barrier. Culture is the invisible one — and it bites harder.
In some countries, young professionals are explicitly taught not to challenge their seniors, especially in public. In Australia, as Becky points out, everyone challenges everyone. Best mates insult each other and nobody blinks. Drop that dynamic into a team with different cultural norms and you'll have people who are either confused, offended, or completely shut down.
For non-native speakers: if you feel like speaking up is somehow disrespectful or risky, check whether that's the culture talking — not the engineering situation. In this industry, raising a concern when something feels wrong is not rude. It can be the most important thing you do on a project — especially when safety is involved.
If you want to hear what this looks like on a real infrastructure project, Johan Bel's story about a Belgian colleague is worth three minutes of your time.
3. Learn their stress word (yes, this one's about cursing)
This tip from Becky is the one that sounds strangest and works best.
Learn one curse word in each of your colleagues' native languages. Not to use it yourself — to recognise it. Because when an engineer switches into their native language under pressure, and that word comes out, something is usually wrong.
If you've learned that word, you'll notice it. You'll pause. You'll check in. That half-second of recognition has stopped more than one project from going in the wrong direction — and in engineering, "the wrong direction" can mean a safety incident.
This is not a soft skill. It's a practical one.
4. Learn one normal word from their language, too
I'd add this one from my own experience. Learn something small and positive — a food compliment, a greeting, something genuinely used in their daily life.
Becky's example was Dutch — and I'd go one better: learn the word gezellig. There's no clean English translation (cosy? convivial? the feeling of a good evening with good people?). That untranslatability is the whole point. When you attempt a word that doesn't even exist in your language, something immediate happens: trust. The other person feels genuinely met.
And here's the part that lands for my engineers: when Becky mispronounces a Dutch word, the Dutch person suddenly worries a lot less about mispronouncing an English word. You're giving them permission — by example — to be imperfect and still be understood.
That is, possibly, the most efficient confidence tool I've ever heard described.
5. Or — hear me out — eliminate the document problem at the source
If coordinating across languages in document-heavy projects makes your head hurt, you might find the argument for model-based systems engineering suddenly very compelling. I'm recording a podcast episode on exactly this soon — [link to MBSE episode — coming soon]. Consider this a spoiler.
6. Curiosity over frustration
Miscommunication will happen no matter what you do. The question is whether you treat it as a failure or a data point. Every miscommunication is a specific, fixable gap. That's an engineer's way of thinking about it — and it works here too.
FAQ: Working in an International Engineering Team
Start by removing jargon from written documents, adding explicit definitions for technical terms, and including visuals wherever instructions could be misread. For verbal communication, slow down, confirm understanding with specific questions rather than a general "did you understand?" — and take time to learn the cultural communication norms of your team, not just the language.
The most common: assuming shared jargon, skipping definitions, and using idiomatic phrases that don't translate. "Screw it in until tight" sounds like complete instruction. To a QA engineer, it's missing the tolerance, the turn count, and the break-back. Precision in writing is already part of your job — apply it to language, not just numbers.
More than most engineers expect. Some team members come from cultures where challenging a senior in a group setting is not acceptable. Others may be translating their thoughts in real time — which adds cognitive load and a short delay, not confusion. Giving space for that process is not a soft skill. It is project management.
Acknowledge early that you're working in your second language — most teams respond well when you name it directly. Focus on being understood, not on being perfect. And remember: every imperfectly-pronounced word you offer in someone else's language gives them permission to do the same in yours.
Fully. Most of the communication failures on international teams are caused by native speakers — not because of bad intent, but because jargon, idiom, and cultural assumptions are invisible when they're your default. Becky's advice applies at least as much to native speakers as anyone else.
Want to Work on This in Practice?
The tips above are a solid foundation. Applying them confidently — in real meetings, real documents, real high-pressure engineering moments — takes practice with the right kind of support.
That's what the Technical English Group Course for engineers at Marcode is built for: practical communication skills for engineers who work internationally, taught by someone who is both an engineer and an English teacher.
The next cohort starts in October 2026.
Not ready to wait? Book a free 15-minute discovery call – we'll look at your specific situation and figure out the best next step together.
Or join the newsletter for practical English and communication tips for engineers, no fluff, no grammar drills.
*This article is based on Episode #008 of the English for Engineers podcast, featuring Becky Paroz — engineer, QA specialist, and 30-year veteran of the Australian construction industry. Listen to the full episode on Spotify.
0 Comments