Spare the Details—But Not the Clarity: How Technical English Improves Global Collaboration in Engineering

Not every project problem is a technical one.

Sometimes it’s a missing detail. Other times? Too many details. Misunderstood emails. A nod you thought meant “yes,” but really meant “not quite.” When you're working on an international engineering team, those moments happen more often than we’d like to admit.

And here’s the thing: the fix isn’t another process flowchart or tighter project plan.

It’s language.
Specifically, Technical English—and not just the textbook kind.

Let’s unpack that. Slowly. Casually. With a few real-world stories that might feel all too familiar.

Wait—What Is Technical English Again?

Quick version?

Technical English is a focused subset of Business English. It’s designed to help people, mostly non-native speakers, communicate in technical and engineering environments without confusion or fluff.

Think:

• Simpler sentence structures

• Purposeful vocabulary

• Clear, structured communication that works across teams and borders

I’ve actually written a full breakdown on that already, so if you're here for the definitions, you can read that article here. But let’s be honest: most people feel the need for Technical English before they can define it.

This blog isn’t about the “what.” It’s about the why.

Why Clarity Isn’t Just Nice to Have

Let me introduce you to Johan Bel, one of my latest guests on the English for Engineers podcast.

He’s a technical consultant based in Rotterdam. Systems engineering is his thing—complex infrastructure projects, industrial automation, the works. He’s been in the trenches with teams from all over Europe: the Netherlands, Germany, Belgium, the UK.

You might think they’d all “get” each other. But it’s not that simple.

Johan shared a moment from one of his earlier projects that still sticks with him.
He made a decision during a meeting—a small one, really. Something about a green door. But his Belgian counterpart didn’t take it well. Not because of the color… but because Johan made the decision alone. In Belgium, you don’t do that. You go up the chain first.

Johan had the mandate. It was technically his call. But culturally, it wasn’t received that way.

And that’s the real issue: it wasn’t the message—it was how the message landed.

It’s a reminder that Technical English isn’t just about language skills. It’s about alignment, culturally and cognitively. You can’t afford to assume that “clear to me” means “clear to everyone.”

Let’s Be Real: Grammar Isn’t the Whole Story

Yes, good grammar helps. But in practice? It’s not usually the grammar that is the problem.

Here’s what really causes problems in technical communication:

• Assuming too much shared knowledge

• Explaining too little—or too much

• Using specialist terms like everyone’s in the same niche

• Talking in circles when a direct sentence would do

Johan put it perfectly:

“If I can explain it to my kids, I know it’s clear enough.”

That idea—“Yip and Janneke taal” in Dutch—means explaining technical concepts like you’re talking to a bright 8-year-old. Not because people are unintelligent, but because clarity is respectful. Simplicity is inclusive.

And in international teams? It's essential.

Format Still Matters—Even When You Don’t Choose the Channel

In engineering projects, communication channels are often fixed.

You don’t get to choose whether you send an update via Teams, email, or project management software. That’s decided by company policy, client expectations, or industry standards.

But even when the channel is out of your hands, the format within that channel is still up to you.

A dense, technical block of text in an email? It gets skipped.
Five bullet points with clear next steps? Much better.

A slide full of jargon at a stakeholder meeting? Confusing.
A diagram with a short explanation? More likely to land.

“The format inside the channel shapes how people receive your message—even if you don’t control the platform.”

So no, you can’t always change where or how information is sent.
But you can absolutely change how understandable it is once it arrives.

When Jargon Backfires

Now, this part might feel familiar—especially if you’ve ever sat in a meeting thinking, “Wait… are we all talking about the same thing?”

That’s the risk of jargon. It feels precise, but it often excludes people.

Here’s a typical example:

“The system uses PID control logic interfaced via Modbus TCP/IP across a redundant ring topology.”

Now, for someone deep in automation or control systems, that’s clear. But if your audience includes civil engineers, external stakeholders, or—heaven forbid—finance?

You’ve lost them.

What they need might sound more like:

“It’s a smart control system that stays stable and keeps everything running, even if one connection fails.”

Same message. Way more accessible.

Technical English isn’t about “dumbing things down.” It’s about removing unnecessary friction so the right people can act on what you're saying.

Culture Shows Up in Every Word (Even the Unspoken Ones)

Here’s something Johan touched on that I think we often overlook: even within the Netherlands, culture shifts from region to region.

People in Rotterdam? Direct. Decisive. Sometimes blunt.
People in Brabant or Limburg? More layered, more polite, sometimes less confrontational.
Amsterdam? Somewhere in between, with its own flavor.

Now stretch that out internationally.

Germany: hierarchy matters.
Belgium: consensus is important.
The Netherlands: flat structure, speak up.
And in Japan? People might not even say “no” directly.

This isn’t just cultural trivia. It affects how we write emails, how we give feedback, how we participate in meetings. If someone seems passive or evasive, maybe they’re just playing by different rules.

Technical English helps create a neutral playing field. One where expectations are more aligned, and intent is easier to read.

So How Do You Actually Improve?

Glad you asked. And no, I won’t say “take my course” (at least not yet 😉).

Here are a few things that actually work—whether you're new to engineering or leading major projects:

1. Break It Down

If your explanation runs longer than three sentences, ask yourself: “Could I say this more simply?”

Don’t over-edit. Just… rethink.

2. Use Visuals

Engineers are visual thinkers. If you can sketch it, graph it, or map it—do it. It’s universal.

3. Ask People to Paraphrase

This is subtle but powerful. After explaining something, ask, “Can you tell me how you understand it?” You’ll instantly know if your message landed.

4. Talk About How You Communicate

Early in a project, check in. Ask things like:

• “Do you prefer quick calls or detailed emails?”

• “Are there any communication styles that frustrate you?”
  That one question can prevent weeks of tension later.

5. Don’t Skip Informal Spaces

Johan mentioned something small but important:
Coffee breaks. Office snacks. Friday drinks.

You might not talk about specs or Gantt charts there, but people do clarify misunderstandings. They build trust. They vent, ask, and laugh—and that builds the foundation for real communication later.

Real Projects, Real Impact

Let’s zoom out.

And look at an example discussed in above mentioned podcast episode: the A15 highway project in the Netherlands. It involved:

• 40 kilometers of highway

• New tunnels, bridges, and control systems

• Teams from at least 4 different countries

• A completely new contract model where the builder also had to maintain the system for 25 years

There was no room for vague communication. Every misunderstanding could ripple through contracts, safety systems, deadlines.

The same was true for another project Johan was involved: the Maasvlakte coal power plant project—a high-stakes, cross-border, multilingual endeavor involving electrical and software systems working in perfect sync.

In both cases, communication wasn’t a soft skill. It was the backbone.

What’s Next for Engineers?

Here’s what I see happening more and more:

• Teams are more interdisciplinary

• Projects are more international

• Workflows are more digital and asynchronous

All of that increases the risk of miscommunication. But it also increases the need—and opportunity—for engineers to stand out not just for what they know, but for how well they explain it.

And that’s where Technical English isn’t just helpful. It’s career-changing.

Want to Learn This the Right Way?

Okay, here’s the CTA. But I mean it.

If you want to build better relationships at work, lead stronger projects, and just feel more confident when explaining what you do, there’s no shortcut.

That’s why I created my English for Engineers course.
It’s not about memorizing grammar rules. It’s about helping technical professionals:

• Communicate across cultures and roles

• Understand what their words really mean to others

• Say what they mean—clearly, concisely, and confidently

👉 Check it out here. No pressure. Just take a peek.

Final Thought (Or Maybe It’s Just a Reminder)

Engineering is about solving problems. But solving problems always starts with people. And people? They need to understand each other.

You don’t need to sound perfect. Just clear. Honest. Human.

So yes—spare the details.

But never, ever spare the clarity.