I once had a teacher who only gave out the highest mark or the lowest. Nothing in between.
No middle ground. No room for "fine." His reasoning was blunt: if your bridge collapses, you cannot say your calculation was average.
That kind of thinking builds excellent engineers. It also builds engineers who think every piece of communication needs to be perfect before it leaves their head, the same way a calculation does.
Which is why so many engineers freeze up* when someone tells them they need to work on their "soft skills." It sounds like being asked to become a different person. Warmer. Chattier. Less precise.
You do not need to become a different person. You need to translate the person you already are into a form other people can understand. That is a completely different task, and a much easier one.
The Perfectionism Trap
Engineers are trained to avoid being wrong. A calculation is either correct or it is not. There is no partial credit for a load-bearing wall.
That training is exactly why "soft skills" feel so uncomfortable. There is no predefined factor of safety (FoS) in human interaction. No formula to check your answer against. You can run a simulation on a conversation before you have it, in your head, rehearsing what you will say. What you do not get is a guarantee that the simulation resembles reality. You never know what the other person is going to say and how they are going to react.
So a lot of my clients told me they did the only thing that felt safe: they said less. They let the work speak for itself. They waited until they were certain before they said anything at all.
The problem is that certainty does not exist in communication the way it does in engineering. Waiting for it just means waiting forever.
If you want to go deeper on that, I wrote a separate piece on why engineers already have more emotional intelligence than they think.
When Your Work Used to Speak for Itself
Early in your career, your work does the talking. The design holds up, or it does not. The calculation checks out, or it does not. Nobody needs you to explain yourself, because the result is the proof.
The further you move into international projects, and up the career ladder, the less true that becomes. Suddenly you are not just designing the bridge, you are also the one who has to walk a client across it. Explain a delay to a stakeholder. Push back on* a deadline that does not make sense.
This is where a lot of engineers get stuck. They were never trained to sell themselves, and the idea of doing it feels almost dishonest. The work should speak for itself.
But a finished bridge cannot explain why it was several months late and €102,000,000 over budget.** You can.
You Are Not Becoming Someone Else, You Are Translating
Here is a small example that says a lot. A Polish engineer once wrote to a US customer: "Hi John, I can't do that, I don't have time."
It landed as rude. Short, blunt, almost dismissive.
But in Dutch, the same message could even be shorter:
"John,
I can't."
(Jan, ik kan niet.)
That is not rudeness either. It is directness, the kind that gets the job done without wasting anyone's time. In Dutch.
In a conversation with Saskia Slotboom, she put it simply: your "Hi John" translates to "Dear John, how are you doing?" Like we have all seen the jokes on social media, that the British "that's interesting" actually means "that's so stupid, are you even serious about this?" It is just a different code. You are not a different person.
What sounds slimy to a German is just basic decency for a US American. Engineers from more "direct communication cultures" are not failing at soft skills when their English sounds blunt. They are using the wrong code for the audience. Once you see it that way, the fix stops feeling like a personality transplant and starts feeling like swapping a connector to fit a different socket.
There is also a Dutch saying that fits here: you cannot expect a sheep to have five legs (een schaap met vijf poten verlangen). In other words, nobody can be excellent at everything. You do not need to master every soft skill at once. You need to translate the ones that matter most for the room you are in.
This article is based on episode 22 of the English for Engineers podcast.
What "Showing Your Cards"* Actually Looks Like in Practice
Translating yourself does not mean performing. It means giving people enough information to work with you effectively.
In engineering, you would never hand over a drawing with no legend. No units, no scale, no material specifications. The drawing might be technically perfect, but without context it is useless to the person reading it.
And remember that annoying maths teacher or structural engineering professor. Every time you only answered with a number, they said: "42 what? Apples? Girlfriends?" And then roasted* you for the rest of the lesson just to make a point about how important it is to always reference a unit.
Communication works the same way. When you say nothing about your reasoning, your timeline, or your concerns, you are handing someone a drawing with no legend. They cannot read it. They fill in the gaps* themselves, and they are usually wrong.
"Showing your cards" is just adding the legend. It sounds like:
"I need until Friday to deliver the report, because I want to check the figures one more time."
"I am not sure about this approach yet. Can we discuss it before I commit?"
"This timeline works for me, but I want to flag* one risk upfront."
None of these sentences require you to be a different person. They require you to say out loud what you were already thinking.
The goal is not to become more talkative. It is to become more readable.
If any of this felt familiar, the good news is that you do not have to figure it out on your own.
I work with engineers who are technically excellent and just need help translating that into the language the rest of the room speaks (English, but for engineers). Whether that is written communication, presentations, or the kind of small daily interactions that quietly determine how you are perceived at work.
If you want to find out whether we are a good fit, you can book a free 15-minute call here. No pressure, no hard sell. Just a conversation.
*Language Notes
Before we get to the frequently asked questions, a quick note on a few phrases used in this article. These are common in English but may not be immediately obvious if English is your second, third, or fourth language.
"To freeze up" — To suddenly stop functioning or responding, usually because of stress or anxiety. "Engineers freeze up when someone tells them they need soft skills" means they stop, they do not know what to do or say next.
"Push back on" — To resist or challenge something, without necessarily refusing it outright. "Push back on a deadline" means to question it, explain why it does not work, and propose something different. It is a normal and professional thing to do in international work contexts.
"To fill in the gaps" — To supply the missing information that was not stated. If you hand someone a report with no context, they will fill in the gaps themselves, meaning they will guess at whatever you left out.
"Roasted" — Informal. To be roasted means to be publicly mocked or criticised, usually in a pointed but not entirely serious way. In the article, it refers to a teacher using your mistake as a lesson for the whole class. You will also hear this in informal English when friends tease each other.
"Showing your cards" — This comes from card games. When you show your cards, you reveal what you are holding before the game is over. In professional English, it means sharing your thoughts, concerns, or plans openly, before someone asks. It is not a sign of weakness. In most international work contexts, it is a sign of professionalism.
"To flag something" — To draw attention to something important so it is not overlooked. "I want to flag a risk" means "I want to make sure you know about this risk before we continue." You will hear this in meetings, emails, and project updates.
Ready to work on this? Book a free 15-minute call here.
FAQ
Soft skills are the non-technical abilities that affect how you work with other people. For engineers, this usually means communication, giving and receiving feedback, presenting your work to non-technical stakeholders, and managing expectations across teams. The term is a bit misleading, because there is nothing soft about them. They are simply a different type of skill from the ones you were trained in at university.
No. Improving your communication skills is not about becoming warmer, chattier, or more extroverted. It is about translating the person you already are into a form other people can understand. A direct, precise engineer does not need to become someone else. They need to learn which code to use for which audience.
The ones that tend to cause the most friction are written communication (especially email), giving feedback across cultures, and knowing how much context to include when you speak or write. Engineers from direct communication cultures often under-explain, assuming the technical facts speak for themselves. On international teams, that gap in context is where misunderstandings start.
Start small and start with the situations that already cause you friction. If emails are the problem, work on emails. If presentations make you nervous, start with low-stakes internal ones. You do not need to master everything at once. As the Dutch say, you cannot expect a sheep to have five legs.
Not quite. Technical English usually refers to the specific vocabulary and writing conventions used in technical documents: manuals, reports, specifications. English for Engineers, which is what I'd prefer to call what I teach, goes further. It covers the communication skills engineers need in international professional settings: emails, meetings, negotiations, presentations, and the moments where your technical knowledge is not the issue but expressing it clearly is.
The most effective starting point is to focus on the situations where communication already costs you time or causes confusion. A delayed response because your email was misread. A meeting that went in the wrong direction because expectations were not clear upfront. Work backwards from the friction.
And if you are using Model-Based Systems Engineering (MBSE) to reduce the need for lengthy documentation and keep everyone aligned through the model, that is a smart approach. But you are still dealing with people. And meetings. And clients who want a phone call. MBSE does not replace the need to communicate clearly; it just changes the format of some of the conversations.
Concrete things that help: read your emails out loud before sending them. Notice where you assumed the reader already knows something they probably do not. Add one sentence of context where you would normally just state the conclusion.
**This is about one of my favorite buildings, the Botlek Bridge in Rotterdam. Cost overrun figure verified against NT.nl (June 2019). For the engineering itself, the Botlekbrug is genuinely worth a look; it is one of the largest lift bridges in Europe. It's so cool.
Original article published on 24 July 2025, last edited on 29 June 2026.
0 Comments